вторник, 8 марта 2011 г.

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

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



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


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

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

Часть 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 отдел тестирования задачи у заказчиков не принимает, а занимается внутренними. Если этого правила придерживаться очень жестко, то все привыкнут и будут планировать свои задачи так, чтобы отдавать их на тестирование до пятничного утра.


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




9 комментариев:

Алексей Лупан комментирует...

Мощь и сила по внутреннему содержанию!

По оформлению тоже очень зачетно.

Julia Nechaeva комментирует...

Леш, это только первая часть =)

Алексей Лупан комментирует...

C нетерпением жду третью часть.

Понимаешь, "Кофе и сигареты" это само по себе неимоверно, а Рене Френч - так вообще...

COTOHA комментирует...

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

но тут места для старческого брюзжания не оставила.

молодец! очень молодец :)

p.s.: от prezi я давно фанатею, так что отдельное спасибо и за оформление :)

LeshaL комментирует...

Привет!
Классно сделано! Спасибо огромное за prezi - пойду-ка зарегаюсь, посмотрю что там можно делать.

И доклад интересный. Видео в тему будет, чтобы слушать, а не читать. Или звук на слайды наложеный.

Julia Nechaeva комментирует...

2CОТОНА: спасибо, очень ценю твое мнение! Тебе Леха Солнцев приветы передавал, кстати.

Julia Nechaeva комментирует...

2LeshaL: это кому как =) многие мой темп на слух не воспринимают. Да и в статье более полно все раскрыто, в трех частях. На доклад всего полчаса было. А потом мы ещё полчаса на флипчарте квадратики рисовали.

Будет и видео и слайдкасты, Стас Фомин занимается. Можно следить в твиттере по хештегу #agiledays например.

Natalya Rukol комментирует...

1. Всё очень точно и грамотно
2. Джоли глазами заказчика очень в тему =)
3. prezi - ням, все дружно пошли щупать :)

LeshaL комментирует...

Юля, меня твой темп не пугает ни сколечки :)
Статья - это круто, посидеть и поосмыслять (или поцитировать).
А презентация в живом исполнении и при таком оформлении - я уверен должен быть драйв!
Вообщем жду. Слежу за Стасовским вимео.