1-й в Украине сертификационный курс по UX от UXQB — крупнейшего в мире комьюнити UX специалистов
×Закрыть

Что такое TestFest, или Как мы тестируем без отдельного QA

[Об авторе: Сергей Королев — управляющий директор в Railsware с более чем 15-летним опытом работы в ИТ: от стартапов до корпораций. Инженер, продакт-оунер, бизнес-лидер]

В прошлой статье мы описали подход к Quality Assurance, который практикуем в компании. Как и обещал, в этой статье расскажу о том, как мы тестируем продукты без выделенных мануальных тестировщиков. Речь пойдет о TestFest — одной из важных составляющих процесса Quality Assurance в компании.

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

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

Что такое TestFest

Мы стараемся, чтобы покрытие unit- и интеграционными тестами кода стремилось к 100%. Более того, функциональность каждой новой фичи проверяется повторно на TestFest.

TestFest — это сессия мануального тестирования фич до перехода в продакшн. Участники команды тестируют соседние фичи (те, которые не разрабатывали сами), тем самым получая доступ к более широкой картине функциональности продукта. Частота проведения сессии зависит от стадии разработки. В активной фазе TestFest-ом заканчивается каждая итерация (раз в 2 недели). На стадии более комплексных итераций или рефакторинга TestFest проводится реже.

Планирование

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

Scrum Master, Product Manager или Lead Engineer (в зависимости от структуры команды) отвечает за формирование списка чоров и фич для тестирования.

Составляя указанный список, ведущий утверждает с командой среду для тестирования:

  • Девайсы для тестирования — десктоп, лэптоп, планшеты, смартфоны с разным разрешением экрана.
  • Операционные системы — Macintosh, Windows, Linux, iOS, Android и т. п.
  • Браузеры — Safari, Chrome, FireFox, Internet Explorer, Edge и т. п.

Ведущий процесса должен убедиться, что каждый участник TestFest получил свой уникальный набор «девайс-ОС-браузер».

Если у команды нет доступа ко всем девайсам или операционным системам, можно использовать эмуляторы. Например, мы часто пользуемся BrowserStack.com — инструмент разработан специально для тестирования, и может имитировать множество устройств и операционных систем.

Сессия

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

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

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

Почему это работает

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

Но, при комплексном подходе, альтернативы внедрения функции ручного QA существуют. Одну из них наша команда испробовала при переходе к модели software consultancy. Наши способы тестирования продуктов были трансформированы на ряду с остальными подходами. Как результат, мы смогли оптимизировать функцию QA, что привело к сокращению потребности в отдельном тестировщике. Сегодня Quality Assurance обеспечивается unit- и integration-тестами, парным программированием, кросс ревью кода, а также результатами TestFest сессий (больше деталей в предыдущей статье).

Среди основных преимуществ трансформации QA и применения TestFest-ов выделю следующие:

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

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

LinkedIn

33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Участники команды тестируют соседние фичи (те, которые не разрабатывали сами

В примере Alex, Mark, Max тестируют новые фичи. Я правильно понимаю, был четвёртый «Аноним» который разработал данный функционал?
Если действительно был четвёртый «Аноним», не напряжно ли создавать такие таблицы, чтобы миновать людей, которые разработали функционал?
Вообще, интересная задумка. Но, я себе трудно представляю как обычные менеджеры могут выполнять задачи QA, даже если их 3 — а QA мог быть 1.
Был бы QA, то и время на создание таблиц не было бы. Всё доставалось бы ему, и проверки и по голове (в случае пропущенных бед)..

У меня другой вопрос, кто пишет тест-кейсы (чек-листы, не важно)
Обычно пишет скрам-мастер

Пора писать книгу «Скрам в действии» )

Зашел написать комент о том, как странно товарищи сэкономили на одной из самых нишевых и низкорейтовых должностей в Айти, а тут уже.

но ведь в статье не идеть речь об экономии :)

Ну, facebook теж, наскільки я чув, не має manual qa’їв в компанії. Теж не економить виходить. Так що, це питання дискусійне.

Facebook does not employ any dedicated testers at all. Instead, the social media giant relies on its developers to test their own (as well as one another’s) work.

techbeacon.com/...​ware-theres-no-one-way-qa

В этой компании рейты свыше 50 баксов в час, вот потому и загруженность этакая

Ярослава,

Если быть точным $75/час

этакая

Это какая :) ?

каждый должен быть «и швец и жнец и на дуде игрец» в одном флаконе, иначе рейты упадут

Концепция «T Shape» о качестве. Рейты это производная.

> we increased new releases to once a day
> wow, how’d you do that?
> fired the QA team :D

Браво! как сэконмить на QA и нагрузить разработииков и менеджеров за ту же зп! Вот это подход

Браво! Прочитать статью и не понять основной сути!

Браво! Увидеть камент и не понять ДОУ-сарказм!

Facebook does not employ any dedicated testers at all. Instead, the social media giant relies on its developers to test their own (as well as one another’s) work.

techbeacon.com/...​ware-theres-no-one-way-qa

wrong ) lol проверили бы сначала ... www.linkedin.com/...​=NzITGEMKTLy1Wp9pbOUapg==

цитата из Вашего линка :
Facebook recognizes that there are significant flaws in its testing process, but rather than going to great lengths to improve, it simply accepts the flaws, since, as it says, „social media is nonessential.”

Any questions? )))

Еще больше мне понравился подход Амазон :
To Amazon, the ratio of testers to developers is an output variable, not an input variable. In other words, as soon as it notices that revenue is decreasing or customers are moving away due to anomalies on the website, Amazon increases its testing efforts.

Nice!

Молодці ви. Те, що платите девелоперську зарплату програмістам за мануальне тестування — щедро, а те, що менеджерів теж примушуєте тестувати, щоб хоч трохи попрацювали інколи — взагалі розумно.
Єдиний мінус я бачу, якщо все ж щось не працює після релізу, на кого скинути відповідальність, що це qa погано протестували ?

Нужно нанять QA хотя бы для того чтобы было кого пинать за баги.

Слав, у нас менеджеры очень плотно работают и без ручного тестирования. И у нас нет «Project Managers» у нас есть «Product Managers» (railsware.com/careers/product-manager) вот тут можно посмотреть требования.

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

В активной фазе TestFest-ом заканчивается каждая итерация (раз в 2 недели)

якщо відкинути зайві навзи, то testfest звичайне регресивне тестування в кінці спринта яке покриває end-to-end сценарії більше. можливо чуть інакше побудоване.

Участники команды тестируют соседние фичи (те, которые не разрабатывали сами)

давайте переведемо в цифри. Спринт 2 тижні, тобто 10 робочих днів, ваш тестфест триває день. команда скільки людей? ну хай 5-7. тобто це приблизно 7 людино/днів, з середньою зп більшою ніж в тестерів. З грубша ви на ці ж кошти могли найняти одного мідл тестера, який б працював цілий спритн.
Пятниця вечір, є результати тестфесту... баги, які впринципі можна було знайти протягом спринту і пофіксати їх.

а оце капці

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

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

а як увас з перевіркою дефектів?

і як завжди, гарного дня ;)

давайте переведемо в цифри. Спринт 2 тижні, тобто 10 робочих днів, ваш тестфест триває день. команда скільки людей? ну хай 5-7. тобто це приблизно 7 людино/днів, з середньою зп більшою ніж в тестерів. З грубша ви на ці ж кошти могли найняти одного мідл тестера, який б працював цілий спритн.

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

Эта функция перешла на команду продакт-менеджеров и инженеров, тем самым усилив их экспертизу и повысив уровень ответственности за создаваемые продукты.

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

Кстати, Сергей, а Вы как-то мониторили напрямую метрики по багам до и после внедрения такого подхода?

Ви праві, але знову ж таки. з 3 переваг описаних в

Среди основных преимуществ трансформации QA и применения TestFest-ов выделю следующие:

1. Девелопери і так мали б знати не тільки свою функціональність. В даному випаду цей тестфест просто помагає вивчити інші...
2.

они изначально более ответственно относятся к написанию кода

це смішно читати. толку з девів які не відповідально відносяться...
3.

TestFest помогает быстрее выявлять проблемы в продукте

як? якщо він проводиться в кінці ітерації... це явно значно пізніше ніж можна було б.

1. Девелопери і так мали б знати не тільки свою функціональність. В даному випаду цей тестфест просто помагає вивчити інші...

«И так» — и как? Он не будет этого знать, потому что ничего подобного нет в его активностях, что помогало бы ему знать. Либо же он очень проактивен, но таких будет подавляющее меньшинство. Это проблема с вполне объективными причинами (в виде человеческой инертности), и здесь предлагается объективное же её решение.

це смішно читати. толку з девів які не відповідально відносяться...

Сорри, но это тоже

смішно читати

Потому что memepedia.ru/...​y-men_10074996_orig_.jpeg :) Все такие продакт-ориентированные, а откроешь темы на ДОУ, так сразу «мне не платят за дополнительную ответственность» :) Ну я как бы не первый день работаю, и не в бункере живу — в большинстве случаев вся продакт-ориентированность ограничивается закрытым тикетом.

кожному своя радість.
теж не перший рік працюю, надивився достатньо на різних тестерів, девелоперів і менеджерів та інших. Що тільки не придумаєш, щоб люди нормально працювали

Що тільки не придумаєш, щоб люди нормально працювали

Отож).

як? якщо він проводиться в кінці ітерації... це явно значно пізніше ніж можна було б.

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

Максим, я очень рад, что получилось донести важность идеи «обмена фичами»!

Кстати, Сергей, а Вы как-то мониторили напрямую метрики по багам до и после внедрения такого подхода?

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

Денис, спасибо за комментарии.
Часть из них не совсем корректны, но это скорее проблема глубины описания с моей стороны.

звичайне регресивне тестування

Да действительно под капотом концепция регрессионного тестирования и Test Fest это не новая концепция тестирование это процесс вокруг тестирования. Так что противоречия нет

ваш тестфест триває день

Непосредственная фаза тестирования длиться часа 2-3, остальная же часть дня — это работа со скоупом и устранение наиболее важных проблем, очевидно что тестировщики не могут выполнять часть этих функций. Давайте так же не игнорировать один из ключевых моментов — обмен фичами. Как инженер я знаю, что занимаясь своим набором фич ты просто теряешь из виду что происходит в соседних бранчах. И это в целом влияет на то насколько крутые будут твои идеи для решения поставленых перед тобой задач. И еще немаловажный факт это дисциплина, которая значительно повышается в рядах инженеров — нет ощущения что сделаю как-нибудь, если будут проблемы — их найдут тестировщики.

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

Хорошо, если у вас эта практика работает и приносит пользу.
Но остается вопрос скорости фидбека. Очевидно что команда не может позволить себе проводить блиц-тестирование (то, что вы называете test fest) достаточно часто чтобы быстро реагировать на появление дефектов. Все они сваливаются в один короткий промежуток времени.
С этим как-то боретесь или просто миритесь?

Судя по всему, самое критичное фиксится на месте, менее критичное откладывается на «когда-нибудь пофиксим». У меня другой вопрос, кто пишет тест-кейсы (чек-листы, не важно) и идет ли тестирование только по ним? Если да, то там сбоку от сценариев может быть порядком багов. Которые, скорей всего, в последующем придут от кастомера

Обычно пишет скрам-мастер и команда дополняет расширяет в процессе. И эту статью все-таки стоит читать после этой dou.ua/...​manual-testing-railsware, в ней чуть больше деталей по QA как процессу в целом.

Подписаться на комментарии