как Тестированию не задерживать Разработку: часть 2

Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.

Спасибо Максу Дорофееву за вдохновение.

Он писал про то, как сервисному отделу можно приблизить срок выпуска задачи. Мой рассказ получается про следующий уровень вложенности. Макс не говорит про тестирование отдельно, потому что у него тестирование внутри команды, и он работает на ускорение всего процесса.

В нашем случае на ускорение всего процесса работают другие люди, чаще всего это менеджер. Отдел тестирования вносит свою лепту тем, что оптимизирует свои процессы для того, чтобы сократить время жизни задачи на тестирование и минимизировать время ожидания задачи в очереди.

Есть известная картинка, которая показывает нам, что выгоднее заниматься задачами последовательно, нежели параллельно, так как в первом случае момент завершения первых двух задач наступает намного раньше.

Теперь представим, что каждая из задач не самодостаточна, и для того, чтобы она получила бизнес-ценность (её можно было продать, ей можно было пользоваться), нужна ещё одна активность других людей.

А теперь представим, что вторая активность не обязательно может быть начата после завершения первой задачи, а уже после выполнения небольшого её участка. Если это учитывать, то можно значительно сократить общее время жизни задачи и приблизить момент её завершения.

Теперь посмотрим на сервисный отдел тестирования. Ему поступают одновременно три задачи от разных заказчиков на тестирование.

Конечно же, в реальной жизни отдел тестирования умеет браться за несколько задач одновременно в силу распределенности умений сотрудников. Но мы же рассуждаем об абстрактном.

Задача на тестирование, как мы помним, не самодостаточна, и зависит от старшей задачи. Более того, есть несколько циклов тест-фикс-ретест.
Если отдел тестирования принимается за 3 задачи последовательно и доводит каждую из них до конца, то мы получаем вот такую картинку:

Красный, зеленый и синий – это задачи на тестирование, розовый, салатовый и голубой – это исправление багов по результатам тестирования. Последний ретест самый маленький и является финальным тестированием перед выпуском задачи.

Но здесь как раз тот случай, в котором исправление багов не обязательно может начаться после завершения всего тестирования задачи. Мы же помним, что тестировщики придерживаются правил 1-5, и первым делом бьют в самые приоритетные области.

Давайте посмотрим, что будет, если тестировщики будут давать фидбек после выполнения первоприоритетных тестов, и заказчики тут же будут приступать к фиксу:

Нам удалось приблизить момент выпуска задачи, нам удалось сократить время жизни задачи на тестирование, нам удалось сократить временные лаги на ожидание заказчиком результатов.

А если мы можем выпустить задачу ДО завершения финального цикла (с известными минорными багами), то посмотрите, насколько раньше это можно сделать!

Теперь вспомним, что перед тестированием была собственно реализация задачи заказчиком, и посмотрим на картинку:

Видим, что от времени жизни задачи на тестирование зависит время жизни всей задачи.

И в такой схеме легко находится Полезное-потом время.

То есть, максимально сокращая ожидание заказчиком результатов тестирования и сокращая срок жизни задачи на тестирование, мы таким образом приближаем момент выпуска задачи в релиз. Чем непосредственно влияем на бизнес-ценность этой задачи.


Если говорить терминами Lean, то тестирование, будучи сервисом, может работать на сокращение сроков выпуска продуктов путем уменьшения потери времени из-за ожидания.

И – что очень важно – такая система позволяет сотрудникам отдела принимать решения: какую задачу взять первой, на каком этапе пора давать фидбек заказчику, какие задачи брать из пула внутренних задач. Они составляют пул внутренних задач, потому что постоянно анализируют свою работу на эффективность. Они придумывают полезные штуки, потому что это интересно и полезно. Они развиваются и от этого тестирование становится более эффективным.

Такой подход уменьшает потери из-за нереализованного творческого потенциала сотрудников, что опять же увеличивает ценность конечного продукта.


Обязательные условия для того, чтобы это работало:

- опытные высококвалифицированные специалисты в отделе тестирования
--- новички не смогут сразу принимать решения, оценивать приоритеты и проводить исследовательское тестирование

- хорошие коммуникации с заказчиками (как рабочие, так и личные)
--- нужно вырабатывать общие подходы с каждым заказчиком, договариваться о способах постановки задачи, о способе репорта о багах, о том, как действовать, если задача сверхсрочная

- небольшое количество людей и небольшой поток задач (в единицах)
--- я не уверена, будет ли это работать на отделе в десятки человек и входящем потоке десятки задач в день

- небольшое количество итераций тест-ретест
--- если оно большое, то получаем дополнительные лаги на переключение, чем, скорее всего, затрём выигрыш по времени за счет раннего фидбека


Продолжение следует...

Читать далее...

как Тестированию не задерживать Разработку. часть 1

На конференции Agile Days рассказывала про то, как сервисному отделу не стать бутылочным горлышком на примере отдела тестирования.



Презентация вот:

Agile Days on Prezi

Видео будет чуть позже.

В дополнение пишу посты, поясняющие мой подход к организации работы отдела тестирования.

Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.

Постановка задачи и метод решения.

Начну с правды: Тестирование не самодостаточно.

Тестирование само по себе не несет для продукта никакой бизнес-ценности. (Я здесь не говорю про компании-аутсорсеры, которые этим зарабатывают, я имею ввиду тестирование в процессе разработки продукта).

Задача на тестирование – это всегда часть старшей задачи: задачи на разработку, задачи, на верстку, на архитектурное решение, на текст, на сценарий, на идею, в конце концов.

И бизнес-ценность для продукта имеет именно та, старшая задача.

Для простоты назовем команду, выполняющую старшую задачу, заказчиком тестирования.

Понятно, что методы и подходы к тестированию зависят от старшей задачи. И – что самое важное – процессы. Процессы тестирования зависят от процессов, по которым выполняется старшая задача.

Согласитесь, было бы странно, если бы команда разработки работала по скраму с итерацией в неделю, и, отдавая задачу на тестирование, слышала бы оценку на тестирование каждой фичи в 3 дня, в которую входит написание тест-плана, сценариев, отчетов, и т.д. Аналогично в потоковом производстве задач тестирование, которое планирует на месяц вперед, явно не приведет в восторг заказчика.

Если тестирование неотрывно от выполнения старшей задачи (как это происходит в большинстве скрам-команд), то проблемы здесь намного меньше: задача просто попадает в состояние ТЕСТИРОВАТЬ, возможно, тем же человеком, который делал старшую.
Но что, если тестирование – это сервисное подразделение в компании? Которое работает на несколько команд.

Очевидно, что сервис должен быть хорошим, иначе им просто не будут пользоваться.

Сервис должен стремиться выполнить задачи всех заказчиков соответственно их требованиям. Плюс у отдела есть общие по компании требования к выпускаемому продукту, и даже если заказчик говорит, что «да IE сейчас никто не пользуется», тестировать в нем все равно нужно.

У отдела тестирования много заказчиков, у каждого свои задачи, к которым нужны разные подходы, на их тестирование нужно разное время, у них разное первоначальное качество, у них разное качество исправления ошибок (следовательно, разное количество итераций тест-ретест). У каждого заказчика свои процессы и планы: одни выдают по 3 фичи в день на тестирование, другие – один дизайн в неделю, третьи фиксят по 10 багов в день. Всплески активности у них тоже разные, у одних зависят от маркетинговых акций, у других – от релизов, у третьих – от сроков запуска новых проектов.

Если мы говорим о задачах на тестирование длиной менее одного дня каждая, то планирование здесь практически невозможно. Я не верю в выполнение тремя заказчиками плана по постановке задачи на тестирование с точностью до часа. Если вы запланировали, что одна задача придет к вам в 11 часов, другая в 15 и третья в 17, то будьте уверены, что они все придут к вам в 17-30 =)

Время, которое старшая задача проводит в тестировании, можно условно разделить на три вида:

Полезное-сейчас время – это время, когда задачу непосредственно тестируют: выполняют тестовые сценарии, гоняют тесты. Сюда же отнесем время на оформление баг-репортов, потому что этот продукт потребляет наш заказчик.

Полезное-потом время – это время на подготовку тестирования: настройка тестовой среды, тест-планы, написание тестов, сбор и анализ метрик, анализ результатов тестирования, составление отчетов, актуализация тестов. Это то, что помогает тестированию оптимизировать работу, делать её более эффективной, и давать более полную оценку качеству продукта.

Бесполезное время – это время, когда задача в тестирование передана, но в тестировании не находится. Она ждет в очереди. Либо сейчас тестировщики заняты другой задачей, либо они не успели подготовить все к началу выполнения.
Понятно, что одно и то же время может быть одновременно Бесполезным для заказчика и Полезным-потом для тестирования.

И в целях уменьшения времени на выполнение старшей задачи, очень важно оптимизировать время на тестирование. Ключевой момент – старшая задача должно КАК МОЖНО МЕНЬШЕ ждать, пока задача вернется с тестирования. При этом экономия времени не должна влиять на качество работы тестирования.

Задача тестирования - максимально эффективно тратить Полезное-сейчас время, максимально сокращать для заказчика Бесполезное время и сделать невидимым Полезное-потом время.

Хороший сервис тестирования должен работать по трем основным принципам:

- как можно быстрее приступать к задаче (минимизировать Бесполезное время)
- как можно быстрее давать первый фидбек (оптимизировать Полезное время)
- как можно быстрее давать оценку качеству (помогать заказчику спланировать и скорректировать время на багфиксы)

Чтобы этого добиться, есть несколько инструментов:


1) максимально мелкие задачи на тестирование


Нужно приучать заказчика к постановке промежуточных задач на тестирование, и найти баланс между тестированием каждого тега, и тестирование целых модулей. Это помогает практически в любой момент времени быть готовыми взяться за новую задачу.


2) правильно расставлять приоритеты в тестировании


-- «Первым бей, где больно»: по тяжести возможных найденных ошибок.

У тестировщиков есть опыт работы в проекте, они знают, какие места наиболее уязвимы, они знают, какой разработчик чище пишет код. Они, используя практики тест-дизайна, могут составить тесты таким образом, чтобы наиболее критичные ошибки с большой вероятностью были найдены первыми

-- «Первым выталкивай, что долго»: по длине цикла исправления возможных найденных ошибок.

Тестировщики знакомы с процессами заказчиков тестирования. И знают, что, например, ошибка сценарного характера исправляется дольше, так как возможно требует обсуждений, а то и исследований. А вот ошибка в коде исправляется в течении часа, или дня. Или, например, знают, что верстальщик послезавтра уходит в отпуск, и поэтому нужно все его баги найти и оформить сегодня, а завтра провести ещё один цикл тестирования.


3) практики тест-дизайна


Для того, чтобы разбивать задачу тестирования на подзадачи и выполнять их в соответствии с приоритетами, можно использовать такие практики тест-дизайна, как составление и группировка тестов:

-- по глубине тестирования (например: смоук, акцептенс, функциональные)

-- по объектам тестирования (например: дизайн – верстка – функциональность фронт-энда – функциональность бек-энда)

-- по сценариям тестирования (позитивные-негативные)

-- по эмулируемым пользователям ( наиболее распространенное поведение, более редкое, практически невозможное)

И выполнять их нужно, разумеется, соответственно выбранным приоритетам.

3) разумно подбирать момент оформления багов


-- Сразу же после каждого найденного бага (оправдано, если тесты маленькие, не требуют подготовки к каждому из них и легко прерываемы, плюс время на оформление бага тоже мало).

-- Сразу же после завершения тестирования подзадачи (логически завершенный участок работы тестировщика).

Иногда, если баг очевиден, нужно сказать вслух, и пока разработчик его правит – оформить.

4) давать предварительную оценку качеству


Работая не первый день над проектом, тестировщик всегда может оценить в сравнении качество реализации текущей задачи заказчиком от других. Это можно делать на основании метрик, например, «количество багов, найденных в результате прогона тестов приоритета 1» , или «количество багов на единицу системы (сценарий, страница, таблица)».

В большей степени это касается ситуаций, когда качество резко хуже обычного, тогда ранний фидбек даст заказчику возможность скорректировать свои планы и выделить больше времени на исправление, возможно, отложив реализацию новых фич.

5) кроссфункциональность сотрудников


В идеале, все сотрудники отдела тестирования должны уметь выполнять все задачи с одинаково высокой эффективностью. Но так не бывает. У разных людей разные таланты, разные способности, они наиболее эффективны в разных областях.

Но, если каждую задачу на тестирование могут выполнить несколько человек, и если люди не закреплены за направлениями, то это дает большую гибкость и позволяет выдерживать всплески активностей по определенному типу задач.

Например, не все ребята должны постоянно заниматься ручным тестированием интерфейсов. Но если все это делать умеют, то отдел легко выдержит предновогоднюю активность по промо-сайтам и страницам, и не подведет маркетологов.


6) исследовательское тестирование


Гениальный подход, философия тестирования, позволяющая опытным тестировщикам максимально быстро приступать к тестированию и максимально быстро давать первый фидбек. Для этого нужно всего-то ничего: опытный высококвалифицированный специалист, грамотный тест-дизайнер и тестировщик в одном лице.

Умение без специальной подготовки сесть и выполнить задачу на тестирование, использую подходы 1, 2, 3 и 4 – вот, что значит исследовательское тестирование.

Ну и плюс некоторые практики:

- сессионность
-- сессия 1: тестирование + оформление багов
-- сессия 2: запись выполненных тестов
-- сессия 3: анализ выполненных тестов, расширение, приоритизация
-- сессия 4: выполнение расширенного набора тестов

- парное тестирование:
-- пилот выполняет тесты
-- штурман подсказывает и записывает


7) Полезное-потом время должно быть обязательно!


Его нужно тратить на Полезные-потом вещи. Это те внутренние задачи отдела тестирования, которые позволяют тестировщикам тестировать эффективно. Это составление планов тестирования, это составление сценариев тестирования, их анализ и приоретизация, это поддержание тестовой среды в актуальном состоянии, это анализ и постоянный апдейт тестов, это разработка и постоянная актуализация фреймворка для тестирования, это изучение новых подходов и методик, это поиск лучших путей для решения задач, это чтение книг и шаринг знаний с коллегами, это ведение базы знаний, это сбор метрик и их анализ...

Если в отделе тестирования этого не делается, значит тестирование работает как загнанная лошадь, на постоянном потоке, без остановки. И обязательно придет момент, когда отдел не справится с задачей вовремя, а то и вовсе не справится, потому что не готов. Потому что нет подходов, нет инструментов. Потому что уже нет мотивации разбираться. Загнали.

Так как задачи из серии Полезное-потом не несут непосредственной ценности для заказчика тестирования, но правильно будет сделать так, чтобы они его не задерживали. Для этого можно пойти двумя путями:

-- Проанализировать загрузку задачами по времени и найти интервалы, когда она меньше всего. Например, первую неделю каждого месяца, когда итерации по проектам только стартуют. В это время нужно планировать выполнение внутренних задач.

-- Жестко запланировать время, например: каждую пятницу с 15-00 отдел тестирования задачи у заказчиков не принимает, а занимается внутренними. Если этого правила придерживаться очень жестко, то все привыкнут и будут планировать свои задачи так, чтобы отдавать их на тестирование до пятничного утра.


продолжение следует...

Читать далее...