Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.
Спасибо Максу Дорофееву за вдохновение.
Он писал про то, как сервисному отделу можно приблизить срок выпуска задачи. Мой рассказ получается про следующий уровень вложенности. Макс не говорит про тестирование отдельно, потому что у него тестирование внутри команды, и он работает на ускорение всего процесса.
В нашем случае на ускорение всего процесса работают другие люди, чаще всего это менеджер. Отдел тестирования вносит свою лепту тем, что оптимизирует свои процессы для того, чтобы сократить время жизни задачи на тестирование и минимизировать время ожидания задачи в очереди.
Есть известная картинка, которая показывает нам, что выгоднее заниматься задачами последовательно, нежели параллельно, так как в первом случае момент завершения первых двух задач наступает намного раньше.
Теперь представим, что каждая из задач не самодостаточна, и для того, чтобы она получила бизнес-ценность (её можно было продать, ей можно было пользоваться), нужна ещё одна активность других людей.
А теперь представим, что вторая активность не обязательно может быть начата после завершения первой задачи, а уже после выполнения небольшого её участка. Если это учитывать, то можно значительно сократить общее время жизни задачи и приблизить момент её завершения.
Теперь посмотрим на сервисный отдел тестирования. Ему поступают одновременно три задачи от разных заказчиков на тестирование.
Конечно же, в реальной жизни отдел тестирования умеет браться за несколько задач одновременно в силу распределенности умений сотрудников. Но мы же рассуждаем об абстрактном.
Задача на тестирование, как мы помним, не самодостаточна, и зависит от старшей задачи. Более того, есть несколько циклов тест-фикс-ретест.
Если отдел тестирования принимается за 3 задачи последовательно и доводит каждую из них до конца, то мы получаем вот такую картинку:
Красный, зеленый и синий – это задачи на тестирование, розовый, салатовый и голубой – это исправление багов по результатам тестирования. Последний ретест самый маленький и является финальным тестированием перед выпуском задачи.
Но здесь как раз тот случай, в котором исправление багов не обязательно может начаться после завершения всего тестирования задачи. Мы же помним, что тестировщики придерживаются правил 1-5, и первым делом бьют в самые приоритетные области.
Давайте посмотрим, что будет, если тестировщики будут давать фидбек после выполнения первоприоритетных тестов, и заказчики тут же будут приступать к фиксу:
Нам удалось приблизить момент выпуска задачи, нам удалось сократить время жизни задачи на тестирование, нам удалось сократить временные лаги на ожидание заказчиком результатов.
А если мы можем выпустить задачу ДО завершения финального цикла (с известными минорными багами), то посмотрите, насколько раньше это можно сделать!
Теперь вспомним, что перед тестированием была собственно реализация задачи заказчиком, и посмотрим на картинку:
Видим, что от времени жизни задачи на тестирование зависит время жизни всей задачи.
И в такой схеме легко находится Полезное-потом время.
То есть, максимально сокращая ожидание заказчиком результатов тестирования и сокращая срок жизни задачи на тестирование, мы таким образом приближаем момент выпуска задачи в релиз. Чем непосредственно влияем на бизнес-ценность этой задачи.
Если говорить терминами Lean, то тестирование, будучи сервисом, может работать на сокращение сроков выпуска продуктов путем уменьшения потери времени из-за ожидания.
И – что очень важно – такая система позволяет сотрудникам отдела принимать решения: какую задачу взять первой, на каком этапе пора давать фидбек заказчику, какие задачи брать из пула внутренних задач. Они составляют пул внутренних задач, потому что постоянно анализируют свою работу на эффективность. Они придумывают полезные штуки, потому что это интересно и полезно. Они развиваются и от этого тестирование становится более эффективным.
Такой подход уменьшает потери из-за нереализованного творческого потенциала сотрудников, что опять же увеличивает ценность конечного продукта.
Обязательные условия для того, чтобы это работало:
- опытные высококвалифицированные специалисты в отделе тестирования
--- новички не смогут сразу принимать решения, оценивать приоритеты и проводить исследовательское тестирование
- хорошие коммуникации с заказчиками (как рабочие, так и личные)
--- нужно вырабатывать общие подходы с каждым заказчиком, договариваться о способах постановки задачи, о способе репорта о багах, о том, как действовать, если задача сверхсрочная
- небольшое количество людей и небольшой поток задач (в единицах)
--- я не уверена, будет ли это работать на отделе в десятки человек и входящем потоке десятки задач в день
- небольшое количество итераций тест-ретест
--- если оно большое, то получаем дополнительные лаги на переключение, чем, скорее всего, затрём выигрыш по времени за счет раннего фидбека
Продолжение следует...
Сообщения
8 комментариев:
По поводу кол-ва людей в команде: надо выравнивать поток задач, тогда эту практику можно распространить и на большие команды.
А можно базовые тесты прогонять сразу с разработчиком, чтобы он без отрыва, если необходимо внес исправления?
1 - Выравнивать поток входящих задач могут только те, кто эти задачи генерит. Опять же, я не ставила себе задачей найти общее решение, я решила свою конкретную задачу, руководствуясь определенными принципами.
2 - И это можно. И можно отдать разработчикам доступ к тестам, чтоб они сами их прогоняли перед тем, как отдать задачу на тестирование. И можно вместе с менеджером сесть посмотреть, что получилось на уровне интерфейсов, чтоб он срочно убежал к проектировщикам менять кнопки местами =)
Все по ситуации.
Тут пойнт в том, чтобы максимально подстраиваться под процессы, которые существуют в командах-заказчиках. чтоб на них влиять, но чтобы они не ломались о тестирование.
спасибо, интересный доклад и подход к оценке времени.
Но:
1) откуда такая классификация времени.
2) почему параллелизация процессов быстрее последовательных?
3) если все делается для заказчика, то где то должен быть этап приемочного тестирования, только пока не очень понял где
2CaMypau:
1) это моя классификация, я её ввожу в первой части статьи
2) Не быстрее. Я как раз всю статью и рассказываю, в каком случае можно пожертвовать последовательностью. И ограничения подхода привожу.
3) Опять же в первой части я определяю заказчика, как постановщика задачи. Это команда разработки, чаще всего. А не сторонний заказчик. Этап приемочного тестирования может быть в первом квадратике времени на тестирование. А может проводиться разработчиками. Зависит от процессов.
Было бы интересно узнать, как ваша система сочетается со specification by example. Мне кажется следующим логическим шагом привлекать тестировщиков на ещё более раннем этапе и тем самым, во-первых, получить более чёткое определение "готово" (definition of done) и, во-вторых, число циклов "тест-фикс-ретест" минимизировать или вообще занулить.
Но такое раннее подключение тестировщиков подразумевает их подключение к задаче, которая пошла в разработку, и сотрудничество с разработчиками (и бизнес-аналитиками) по этой конкретной задаче, а не свободу "выбирать задачи из пула". Как бы вы разрешили это противоречие?
Создаётся также впечатление, что отдел тестирования, который вы описываете, расположился "вниз по течению", и что вы боретесь там с проблемами, которые создаются отделом "в верхем течении", вместо того, чтобы ТАМ их устранять - например, вы пишете, что тестировщики могут принимать рещения на основании того "какой разработчик чище пишет код". Это как раз то, что проповедники Lean склонны ругать, называя это локальной оптимизацией. Как бы вы на это ответили?
2Alexei Zheglov
Вы мне вообще не противоречите =) Ничего не мешает в такой схеме тестировщикам подключаться к обсуждению фичей на уровне идеи, и на уровне реализации.
Здесь речь о том, когда команда тестирования работает на НЕСКОЛЬКО команд разработки.
Что же касается "впечатления, что отдел тестирования расположился "вниз по течению" - то про это просто ни слова не было сказано ни в статье, ни в докладе. Описана конкретная проблема: работа с несколькими командами по разным процессам. КАК сделать так, чтоб все были довольны. Вот вам методы.
Что до проповедников Lean - то не они со мной работают, а конкретные люди, которым нам нужно сделать удобный сервис, а не слепо следовать методологиям.
1. А все таки когда наступает конец одного квадратика и начало другого ? Конечно запрос на тестирование должен приходить несколько раньше чем девелопер коммитит последние изменения и закрывает таск - тут я согласен. некоторые процессы (как тест-дизайн) можно постараться сделать паралельно с девелопментом и даже - чем черт не шутит - анализом. Но вот когда задача закончена и переходит в тестирование - какой критерий чтобы сказать "все - первый красный квадрат закончился - перехожу к зеленому"?
2. По-моему это все можно упросить сказав тестерам -> "начинайте репортить баги как только нашли" девелоперам ->"фиксите баг как только он попал в багтрекер" CI инженеру -> "настрой среду на билд после каждого коммита и деплой раз в день" Это на мой взгляд вполне стандартный и работающий подход и если иметь ответ на вопрос 1 то можно считать оптимальный путь найден --- или тут речь немного о другом ? (и значит я не понял идеи статьи:)) )
3. Юля - кажется упоминали о работе с несколькими девелопмент командами и в тоже время задачами которые не имеют бизнес вэлью одна без другой - как это так получилось? Мне кажется каждая дев команда должна работать над вполне себе самодостаточной и полноценной задачей - иначе ничего не выйдет
Где можно научится профессии мануального тестировщика?
Отправить комментарий