Да, действительно так (теперь только для про) – очень жаль. Сейчас у меня в доступе есть только подкаст с Нэнси, где она рассказывает про это же www.spreaker.com/user/softwaretestpro/nancy-kelln-spring-2020 – примерно с 17:05, когда интервьюер спрашивает про risk-based report.
Попробую найти все таки полноценное выступление, в подкасте вся базовая информция в сжатом виде, но Нэнси помимо всего прочего – отличный спикер и в выступлении у нее много полезных примеров.
Естественно в процессе договоренности никто не следит за таймингом :) С одной стороны, в нашей команде есть бэклог задач для QA, отсортированный по приоритету задач. Команда QA ответственна за поддержание количества задач бэклога на определенном уровне. С другой стороны, каждый участник команды имеет свои проекты, связанные с улучшением внутренних инструментов. Проект иницируется, ведется и продвигается самим QA – в этом плане полная самоорганизация.
Возникает, если можно так сказать, небольшой конфликт интересов между тем, что “надо” делать (бэклог), и тем, что “хочется” делать (проект). Небольшая ремарка – в бэклоге также интересные задачи – но вы выбираете между двумя вещами “работа на ковейере” — “ведение проекта/разработка”. Команда заинтересована в пустом бэклоге, вам хочется самовыражатся. Руководитель заинтересован в том, чтобы у сотрудника соблюдался баланс между “надо/хочу” — потому что совсем убрать “надо” — означает, что участник не вносит вклад в работу, совсем убрать “хочу” — означает выгорание и демотивацию сотрудника.
Процесс договоренности происходит следующим образом. На тет-а-тет получасовом митинге с руководителем (у нас он проходит ежемесячно), мы обсуждаем успехи и трудности и примерно закладываем скоуп работ на следующий месяц. Например, руководитель может сказать “у тебя очень хорошая производительность, так держать”, “или, ты немного просел по задачам, были ли какие-то трудности возможно требуется помощь с какими-то задачами” — это видно по тому как вы работаете над задачами из бэклога. Я в свою очередь могу сказать, что “с задачами я справляюсь, есть идея оптимизировать такой то процесс, поэтому я могу в следующем месяце немного просесть по задачам из бэклога, с учетом общего состояния команды примерно насколько я могу просесть по бэклогу и поработать над своими задачами?”. Руководитель организует команду таким образом (следит за соотношением активные девелоперы, активные qa, состав задач в бэклоге), что каждый может просесть по бэклогу примерно на 20% от показателей, как если бы он стоял беспрерывно на конвейре бэклога.
Ответ на ваш вопрос: эта договоренность осуществляется за счет такой организации команды руководителем, что 20% моего времени закладывается на мои собственные задачи.
Вторая часть про проекты, какие они? Все типы проектов описаны в статье в классификации тулов. Я люблю различные “нечестные” методы: моки, стабы, а также форматтеры. Из больших проектов — это генерация кастомных чеков для платежей Apple, девел стаб для нотификаций мобильных операторов. У других коллег есть проекты по диагностике девельного окружения, есть пет-проекты по ведению документации с помощью майнд-мэпов, есть проекты по написанию плагинов для автотестов.
Из больших проектов один был подробно описан здесь (https://habr.com/en/company/badoo/blog/460667/ ) – он получился очень масштабным, потому что были привлечены разработчики клиентской части и команда автоматизации. Точнее внутри каждого из отделов назревала необходимость этих изменений, но никто не закладывал это в основной скоуп работ, потому что бизнесу было не до этого, в итоге когда выяснилось, что всем это надо, все это втихую делают, и делают примерно одно и то же – случился эффект синергии и произошел прорыв в качестве работы без просадки по основным задачам. Аналогичная история произошла с диагностикой девельного окружения — проект родился в голове одного из участников команды, затем был и подключены разработчики платформы, отдельных компонент.
Случается и обратная ситуация, когда синергии не возникает, у меня такое было с девел стабами мобильных операторов, я сделал инструмент под себя, когда начали привлекать другую команду, они сказали, “мы за честные методы, хотим песочницы”. Поэтому 20% — это очень разумная цифра, этого времени достаточно, чтобы оставаться в фокусе работы над проектом, это время не позволяет просесть по основным задачам, это время позоляет покрыть риск, если не возникнет синергии. Если будет больше времени — вы можете просесть по основным задачам, если меньше – просто будете терять фокус при работе над задачей
ЭКСПЕРТИЗА (франц. expertise, от лат. expertus — опытный) — исследование специалистом (экспертом) каких-либо вопросов, решение которых требует специальных познаний в области науки, техники, искусства и т. д. (Большой энциклопедический словарь)
Экспертиза — Исследование Экспертами каких-либо вопросов, решение которых требует специальных познаний в области науки, техники, искусства и т. д. (Большая советская энциклопедия)
Экспертиза — [< лат.; см. эксперт] – исследование и разрешение при помощи сведущих людей какого-либо вопроса, требующего специальных знаний, например, врачебная экспертиза, бухгалтерская экспертиза (Большой словарь иностранных слов)
В сухом остатке — это исследование экспертом. «Необходимы знания и экспертиза» в данном контексте означает, что либо вы знаете все кейсы (например, потому что вы общаетесь с представителями провайдера, уверены, что версия та же, что описана в имеющейся документации). Либо вы проводите исследование, для которого вам нужны экспертные навыки и стартовые данные (например, критерии оценки или опорные точки, которые в статье и предложены). Поэтому здесь как мне кажется нет ни противоречия, ни тавтологии.
При переводе на английский будет использован только термин expertise, потому что, как вы совершенно верно заметили, в английском языке это слово уже включает и навыки исследования, и знания.
Рассматривая клиентское приложение или систему «приложение-сервер» (которые далее в коментарии я буду называть просто приложением), мы имеем дело с детерминированным конечным автоматом (ДКА), который обладает ограниченным (возможно очень большим, но ограниченным) числом состояний. Проблема подключения сторонних сервисов, которыми является, например, платежный провайдер, заключается в том, что на одну из точек входа начинают поступать сигналы на изменение состояний, которые a) нам известны, но плохо контролируются нами, б) нам неизвестны. Соотвтетственно, ответ на вопрос «ЧТО мы тестируем?» разбивается на две части: a) для известных сигналов черного ящика мы тестируем, что вся цепочка состояний нашего ДКА изменяется в соответствии с нашими ожиданиями, б) что мы не получаем сигналы, которые нам неизвестны.
Первая проблема заключается в том, что сигналы нами плохо контролиуруются (распределены во времени в реальном кейсе, требуют сложной настройки и прочее). Решается эта проблема идеально любым методом убирания внешних зависимостей, по сути о ней очень подробно написано в этой статье. Поэтому же в статью добавлен раздел о важности наличия знаний обо всех возможных состояниях до реализации взаимодействия. На этом этапе цель — перевести как можно больше сигналов из категории неизвестных в категорию узнаваемых приложением.
Вторая проблема — поступление на вход приложения неизвестного сигнала. Она очень серьезная, и решается она по-разному. В комментарии выше, например, коллега предлагает вести журнал и иметь в отделе менеджера, контролирующего изменения от внешней системы. У нас на текущий момент выполняется сбор всех приходящих нотификаций от внешних систем. Любые изменения сигналов мы рассматриваем как риск. Узнать о них (если нас не уведомляют провайдеры заранее) мы можем постфактум (и у нас были прецеденты), посмотреть в логах, что к нам стало приходить, увидеть изменения и отреагировать на них. Но это все равно не гарантирует нам своевременную реакцию на изменения. Если мы хотим получать информацию о неизвестных сигналах, как можно раньше, то в идеале мы должны валидировать приходящие к нам запросы (например, по xsd или json схемам), но здесь я немного хитрю, называя это риском. При рассмотрении риска мы должны учитывать вероятность его реализации, негативное влияние от его реализации и стоимость на его покрытие. В нашей ситуации решение с валидацией пока представляется достаточно дорогим, потому что это аналитическая или даже экспертная система, которая требует серьезных ресурсов на создание и поддержку. Да, изменения случаются, да они могут принести серьезный вред (и мы рассмотрим пример в следующей статье, которую готовит мой коллега по мотивам выступления на Гейзенбаге (ссылка в статье)). Но вероятность этого пока не настолько высока, чтобы потратить ресурсы на валидацю по схеме, поэтому мы ограничиваемся визуальным анализом статистики и логов, и немного уменьшаем неопределенность, покрывая интеграционными тестами с использованием реального платежа или песочницы.
PS Вообще, своим коментарием вы подняли проблему, которую лично я считаю одной из ключевых в коммуникации, когда объект исследования подменяется методологией и потом забывается, а о чем мы вообще тут говорили. Ответ на этот вопрос помог сместить акценты, как мне кажется в нужном направлении. Спасибо!
Спасибо за важное дополнение. Конечно, всего в одну статью не уместишь: у нас готовится следующая статья от моего коллеги, с которым мы вместе делали доклад на Гейзенбаге, там как раз будет про то, что в каждом конкретном случае требуется оценка рисков и их покрытие. Мы также расскажем, на основе чего эти риски выявлять. Про рунглиш — да, в Лондоне возникает такая профессиональная деформация, иногда забываешь, как слова пишутся.
Очень классное дополнение, спасибо! Надо попробовать в своей работе. Это позволит также формализовать свои знания и, в случае неоходимости, поделиться ими с коллегами. В нашем рабочем процессе закрепление человека за определенной областью не очень приветствуется, но ведение журнала подходит и в этом случае.
Попробую найти все таки полноценное выступление, в подкасте вся базовая информция в сжатом виде, но Нэнси помимо всего прочего – отличный спикер и в выступлении у нее много полезных примеров.
Возникает, если можно так сказать, небольшой конфликт интересов между тем, что “надо” делать (бэклог), и тем, что “хочется” делать (проект). Небольшая ремарка – в бэклоге также интересные задачи – но вы выбираете между двумя вещами “работа на ковейере” — “ведение проекта/разработка”. Команда заинтересована в пустом бэклоге, вам хочется самовыражатся. Руководитель заинтересован в том, чтобы у сотрудника соблюдался баланс между “надо/хочу” — потому что совсем убрать “надо” — означает, что участник не вносит вклад в работу, совсем убрать “хочу” — означает выгорание и демотивацию сотрудника.
Процесс договоренности происходит следующим образом. На тет-а-тет получасовом митинге с руководителем (у нас он проходит ежемесячно), мы обсуждаем успехи и трудности и примерно закладываем скоуп работ на следующий месяц. Например, руководитель может сказать “у тебя очень хорошая производительность, так держать”, “или, ты немного просел по задачам, были ли какие-то трудности возможно требуется помощь с какими-то задачами” — это видно по тому как вы работаете над задачами из бэклога. Я в свою очередь могу сказать, что “с задачами я справляюсь, есть идея оптимизировать такой то процесс, поэтому я могу в следующем месяце немного просесть по задачам из бэклога, с учетом общего состояния команды примерно насколько я могу просесть по бэклогу и поработать над своими задачами?”. Руководитель организует команду таким образом (следит за соотношением активные девелоперы, активные qa, состав задач в бэклоге), что каждый может просесть по бэклогу примерно на 20% от показателей, как если бы он стоял беспрерывно на конвейре бэклога.
Ответ на ваш вопрос: эта договоренность осуществляется за счет такой организации команды руководителем, что 20% моего времени закладывается на мои собственные задачи.
Вторая часть про проекты, какие они? Все типы проектов описаны в статье в классификации тулов. Я люблю различные “нечестные” методы: моки, стабы, а также форматтеры. Из больших проектов — это генерация кастомных чеков для платежей Apple, девел стаб для нотификаций мобильных операторов. У других коллег есть проекты по диагностике девельного окружения, есть пет-проекты по ведению документации с помощью майнд-мэпов, есть проекты по написанию плагинов для автотестов.
Из больших проектов один был подробно описан здесь (https://habr.com/en/company/badoo/blog/460667/ ) – он получился очень масштабным, потому что были привлечены разработчики клиентской части и команда автоматизации. Точнее внутри каждого из отделов назревала необходимость этих изменений, но никто не закладывал это в основной скоуп работ, потому что бизнесу было не до этого, в итоге когда выяснилось, что всем это надо, все это втихую делают, и делают примерно одно и то же – случился эффект синергии и произошел прорыв в качестве работы без просадки по основным задачам. Аналогичная история произошла с диагностикой девельного окружения — проект родился в голове одного из участников команды, затем был и подключены разработчики платформы, отдельных компонент.
Случается и обратная ситуация, когда синергии не возникает, у меня такое было с девел стабами мобильных операторов, я сделал инструмент под себя, когда начали привлекать другую команду, они сказали, “мы за честные методы, хотим песочницы”. Поэтому 20% — это очень разумная цифра, этого времени достаточно, чтобы оставаться в фокусе работы над проектом, это время не позволяет просесть по основным задачам, это время позоляет покрыть риск, если не возникнет синергии. Если будет больше времени — вы можете просесть по основным задачам, если меньше – просто будете терять фокус при работе над задачей
В сухом остатке — это исследование экспертом. «Необходимы знания и экспертиза» в данном контексте означает, что либо вы знаете все кейсы (например, потому что вы общаетесь с представителями провайдера, уверены, что версия та же, что описана в имеющейся документации). Либо вы проводите исследование, для которого вам нужны экспертные навыки и стартовые данные (например, критерии оценки или опорные точки, которые в статье и предложены). Поэтому здесь как мне кажется нет ни противоречия, ни тавтологии.
При переводе на английский будет использован только термин expertise, потому что, как вы совершенно верно заметили, в английском языке это слово уже включает и навыки исследования, и знания.
Первая проблема заключается в том, что сигналы нами плохо контролиуруются (распределены во времени в реальном кейсе, требуют сложной настройки и прочее). Решается эта проблема идеально любым методом убирания внешних зависимостей, по сути о ней очень подробно написано в этой статье. Поэтому же в статью добавлен раздел о важности наличия знаний обо всех возможных состояниях до реализации взаимодействия. На этом этапе цель — перевести как можно больше сигналов из категории неизвестных в категорию узнаваемых приложением.
Вторая проблема — поступление на вход приложения неизвестного сигнала. Она очень серьезная, и решается она по-разному. В комментарии выше, например, коллега предлагает вести журнал и иметь в отделе менеджера, контролирующего изменения от внешней системы. У нас на текущий момент выполняется сбор всех приходящих нотификаций от внешних систем. Любые изменения сигналов мы рассматриваем как риск. Узнать о них (если нас не уведомляют провайдеры заранее) мы можем постфактум (и у нас были прецеденты), посмотреть в логах, что к нам стало приходить, увидеть изменения и отреагировать на них. Но это все равно не гарантирует нам своевременную реакцию на изменения. Если мы хотим получать информацию о неизвестных сигналах, как можно раньше, то в идеале мы должны валидировать приходящие к нам запросы (например, по xsd или json схемам), но здесь я немного хитрю, называя это риском. При рассмотрении риска мы должны учитывать вероятность его реализации, негативное влияние от его реализации и стоимость на его покрытие. В нашей ситуации решение с валидацией пока представляется достаточно дорогим, потому что это аналитическая или даже экспертная система, которая требует серьезных ресурсов на создание и поддержку. Да, изменения случаются, да они могут принести серьезный вред (и мы рассмотрим пример в следующей статье, которую готовит мой коллега по мотивам выступления на Гейзенбаге (ссылка в статье)). Но вероятность этого пока не настолько высока, чтобы потратить ресурсы на валидацю по схеме, поэтому мы ограничиваемся визуальным анализом статистики и логов, и немного уменьшаем неопределенность, покрывая интеграционными тестами с использованием реального платежа или песочницы.
PS Вообще, своим коментарием вы подняли проблему, которую лично я считаю одной из ключевых в коммуникации, когда объект исследования подменяется методологией и потом забывается, а о чем мы вообще тут говорили. Ответ на этот вопрос помог сместить акценты, как мне кажется в нужном направлении. Спасибо!