Комментарии 6
Вы изобрели QA аналитика?
Привет!
Давай поподробнее расскажу про обязанности системного QA:
Тестирование документации (бизнес и технической)
Написание QAP
Валидация фичи поэтапно (после того, как любая из команд заканчивает с разработкой и тестированием части своей фичи, они призывают системного QA для валидации куска фичи)
Подготовка тестового окружения с данными для приемки фича овнером (у нас очень много интеграций команд друг с другом и этот процесс достаточно нетривиальный)
Ведение общего QA пространства, где к каждой фиче аттачатся все необходимые артефакты (BRS, SRS, QAP, кейсы команд, тестовые ключи/аккаунты, которые можно переиспользовать)
Помимо этого сейчас прорабатываем вариант развития команды системных QA с точки зрения:
Автоматизации QAP на интеграционном стенде (чтобы фича была покрыта e2e тестами)
Изучением того, как у наших конкурентов реализована эта фича (с точки зрения бизнес логики, UI/UX, будем совместно работать с продактами)
Отличия от QA аналитика будут в пунктах:
3 (тут будет зависеть от того, какая зона ответственности у QA аналитика)
4 (обычно этим занимается фича овнер)
5
6/7 зависит от компании, но как правило QA аналитики этим не занимаются
Правильно ли я понимаю, что в классических терминах: Feature owner = business analyst, feature architect = system analyst, QAP = acceptance criteria (критерии приёмки функциональности), System QA = test analyst+test designer?
Я так понимаю, что ценой ускорения релизного флоу на 15-20% стало увеличение штата (+ к ПШЕ) на X%? Судя по наличию онбординга для System QA, это дело поставлено на поток, а значит таких системных QA у вас >1. При том, что вряд ли с FO снята полностью нагрузка по QAP, ведь вряд ди SQA может почерпнуть всю необходимую информацию по созданию QAP только из SBS, и скорее всего отвлекает FO, задавая ему уточняющие вопросы и получая ответы.
Привет!
Да, если переходить к классическим терминам, то они совпадают, но на всякий случай опишу, чем занимаются эти роли у нас:
Feature owner занимается тем, что изучает конкурентов, какие решения сейчас есть на рынке, удобно/неудобно ими пользоваться, как это ложится на нашу систему, насколько быстро нужно реализовать фичу. Пишет BRS (бизнес-требования), общается с командами, которые участвуют в разработке фичи, отвечает на их вопросы. Помимо этого, занимается валидацией этой фичи после разработки/тестирования. После релиза собирает метрики (которые он заранее продумывает на фичу) и делится результатами с компанией.
Feature architect продумывает архитектуру на нескольких уровнях, начиная с высокоуровневых – как и какие сервисы должны общаться друг с другом, заканчивая низкоуровневыми требованиями – какие АПИ должны быть разработаны (включая различные параметры, коды ответов, время ответов и так далее). Помимо требований к самой разработке, он должен описать процесс документирования (техническая/эксплуатационная) сервисов, добавить девопс блок, в котором будет описано, как разворачивать сервисы. То есть на выходе мы получаем готовый документ по реализации и выкатыванию фичи в прод с метриками и алертами
QAP (Quality Assurance Plan) – набор кейсов, по которым Feature owner принимает фичу (выступает хорошей подсказкой для QA команд, которые участвуют в тестировании фичи). В нашем флоу набор этих кейсов описывает системный QA, затем отдает на ревью Feature owner, и в случае успеха QAP утверждается. Команды могут его использовать как подсказку в виде кейсов. После того как команда заканчивает с частью своей фичи, SQA валидирует со своей стороны и фича дальше двигается по флоу.
Можешь ли ты сказать, что бизнес и системные аналитики у вас и FO, FA у нас пересекаются по обязанностям?
Если пересекаются, тогда эквивалент, если нет, то интересно, чем у вас они занимаются.
System QA = test analyst+test designer. Вот тут не совсем, на мой взгляд. Системный QA немного другая роль, отличия в том, что помимо пересекающихся обязанностей, он занимается:-
Валидацией фичи поэтапно (после каждой команды идет ревью по кейсам системным QA)
Подготовкой тестового окружения с данными для приемки Feature owner
Ведением общего QA пространства, где к каждой фиче прикладываются артефакты (BRS, SRS, QAP, кейсы команд, тестовые ключи/аккаунты, которые можно переиспользовать)
Автоматизацией QAP на интеграционном стенде (чтобы фича была покрыта e2e тестами)
Изучением того, как у наших конкурентов реализована эта фича (с точки зрения бизнес логики, UI/UX, будем совместно работать с продактами)
2. Уточню на всякий случай по терминологии: ПШЕ - производственно-штатная единица?
Системный QA у нас пока один, собираемся нанимать еще несколько человек. По процессу поняли, что только узнав как работает каждая из команд, системный QA сможет понимать как работает система целиком, именно поэтому был разработан такой план онбординга. Как писал выше, FO валидирует кейсы, которые были написаны системным QA. Информацию же SQA берет из BRS и SRS. Безусловно, у нас есть процесс общения и уточнения вопросов у FO. Но, как правило, мы стараемся уточнить все моменты по бизнес требованиям до того, как мы пишем технические требования. Поэтому у нас назначается несколько сессий с FO по всем вопросам со стороны бизнес-логики, и всегда есть возможность оставить комментарии в документе (BRS), а не дергать FO в моменте.
По ролям понял, спасибо большое.
Получается, что серьёзный процент ускорения вы получили за добавление всего 1-3 человек в штат ИТ (предполагаю, ~70-90 человек).
В целом, по содержанию в этой и предыдущей статье организация процессов у вас выглядит "вкусно" и привлекательно. Очень редкое явление, завидую. Думаю что людям у вас приятно работать, а менеджеры довольны отлаженным механизмом.
P.S. Нравится, что у вас в статьях текст обильно дополняется поясняющими схемами.
Как ускорить релизный флоу с помощью одного системного QA