Home

Автор: Панна Черукури (Panna Cherukuri)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=27

Перевод: Ольга Алифанова

Я работаю в Atlassian в качестве QA. Мы называем себя инженерами по обеспечению качества. Как QA, мы тесно сотрудничаем с нашей командой разработки, преследуя общую цель – «хорошее качество продукта». QA похожи на тренеров по качеству – мы фокусируемся на обучении и поддержке. Это значит, что обычно мы не тестируем самостоятельно – мы помогаем команде разработки определить, что должны тестировать они. Наша команда также занимается качеством процесса разработки. Хороший процесс должен быть эффективным, надежным, и простым в использовании. Команда QA разработала процессные метрики, которые помогают нам следить за качеством процессов. Мы боремся за постоянное развитие наших процессов, потому что этого требует наша организация. Мы работаем в Agile-окружении, и наша первостепенная задача – предотвратить появление багов. В процесс разработки мы встроили шаги, позволяющие предотвратить появление багов и намного раньше снизить риски.

Данные, а не интуиция

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

Эксперименты открывают двери инновационным идеям, которые, возможно, со временем станут конкретными процессами.

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

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

Заметили, что тестирование повторяется дважды?

Давайте предположим, что команда состоит из QA (Мэри) и разработчиков (Бренды, Дэвида и Мэтта). Теперь давайте разберемся, что сделала команда на каждом шаге вышеуказанной диаграммы.

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

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

Отметив это, команда начала идентификацию, какой именно шаг тестирования нуждается в устранении.

Мы обдумали нашу QA-цель – научить разработчиков быть хорошими тестировщиками. В итоге мы решили, что тестирование после код-ревью надо устранить. Но что, если оно добавляло ценность? Знаем ли мы об этом? QA-команда разработала метрики, которые помогли бы это определить. Мы измерили количество юзер-стори, которые были переправлены из тестирования в разработку. Числа утверждали, что второй раунд тестирования приносит ценность.

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

У эксперимента должны быть:

• Цель или гипотеза
• План
• Длительность
• Выявленные риски и проблемы
• Результаты

Мой эксперимент

Гипотеза

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

План

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

Длительность

Месяц. Длительность оценивалась, исходя из плана.

Риски и проблемы

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

Результаты

После анализа полученных данных мы валидировали их согласно гипотезе.

Вот как выполнялся план:

Шаг 1: я проанализировала, почему баги не были найдены в первом раунде тестирования, и выяснила, что на то есть две причины:

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

Шаг 2: чтобы исправить это, я внедрила следующие решения:

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

Шаг 3: Как только эти меры были приняты, мы начали замерять количество багов, найденных на втором раунде тестирования.

Анализ данных

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

Как можно догадаться, гипотеза оказалась верной. Я поделилась данными, подтверждающими мою гипотезу, с командой, и мы изменили процесс. Теперь он стал выглядеть так:

Угадайте, за какую задачу я принялась потом? Да-да, за дальнейшие улучшения процесса путем экспериментов с ним.

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

Заключение

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

Итак, можете ли вы придумать эксперимент, нацеленный на улучшение качества там, где вы работаете?

Обсудить в форуме