Нина Полторакова
Ведущий специалист по тестированию
Привет! Меня зовут Нина Полторакова, я ведущий специалист по тестированию в ГК «Юзтех».
На своём проекте я «нечто среднее» между сеньором и лидом: умею хорошо и в тестирование, и в процессы.
В этой статье я хочу поделиться с читателями своим видением и своим опытом внедрения «врат качества»: что это, какие «врата» мы используем у себя и как со всей этой красотой нам живётся. Эта статья будет полезна всем тем, кто как и я борется за качество, не только выпускаемых продуктов, но и процессов на проекте и компании вцелом.
Буквально два слова про проект — мы с командой занимаемся разработкой и поддержкой ИТ-решений по направлению Life — страхование жизни одной довольно большой страховой компании, у нас есть несколько продуктов, которые мы тестируем. В своей статье «Как не сойти с ума, тестируя я страховые продукты» я рассказала чуть подробнее про то, с чем и как мы работаем.
И работали, надо сказать, неплохо, всех все устраивало: процесс был не идеален, но понятен всем, от разработки и оценки задач до передачи в пользовательское.
Да, запросы на изменение (ЗНИ) приходят от пользователей не как бизнес-требования, а кратенькое описание в почте, но у нас есть аналитики, которые проводят глубинные интервью и собирают всю нужную для разработки задачи информацию. Ну и что, что наши ребята-разработчики могут переключиться с одной задачи на другую, более приоритетную, они ведь делают «хорошо» бизнес-пользователям. Да и тестируем мы от души, на скорую руку накидав чек-лист.. Комментариев в тасках ни разработчики нам, ни мы пользователям не оставляли, а при необходимости — просто созваниваемся, демонстрируем экран и отвечаем на вопросы.
И вроде все хорошо, все как у всех — ведь у всех же есть какие-то сложности и шероховатости в процессах, команды живут так годами и совершенно не задумываются о необходимости что-то менять.
Вот мы и не задумывались какое-то время, пока я не сходила на конференцию Подлодка (тут не реклама, тут от сердца), текущий сезон которой был посвящён Quality gates или «вратам качества», но обо всём по порядку.
Само понятие quality gates пришло к нам из автомобильной промышленности и очень тесно связано с концепцией бережливого производства и непрерывного улучшения (в конце статьи я оставлю несколько рекомендаций книг, где рассмотрены данные концепции, самая яркая, по крайней мере для меня, является книга «Дао Тойота»).
Автомобильные компании одними из первых поняли важность внедрения систематического контроля качества на всех этапах производства, что впоследствии стало основой для аналогичных подходов в других отраслях» (историческую справку любезно дал мне GigaChat).
Вернёмся к нашим «айтишным баранам» воротам. Применительно к IT гейты используются как некие контрольные точки и могут выглядеть прямо как чек-листы: прошлись по проверкам, отметили все контрольные пункты и поехали дальше.
Для того, чтобы начать что-то менять или внедрять, нужно сначала сделать снимок текущего состояния дел, дабы понять, что у нас есть сейчас: какие процессы, какие ресурсы, какая команда, и конечно же решить, а что мы хотим получить по итогу.
Итак, «снимок» нашего текущего состояния дел или AS IS:
недоработанный процесс работы с ЗНИ, отсутствует шаблон и правила постановки и передачи задач нам, исполнителям;
непрозрачный процесс разработки продукта (разработчик может заниматься не той задачей, которая лежит на доске, потому что его попросили бизнес-пользователи);
процесс тестирования тоже оставлял желать лучшего: ни кейсов приличных, ни регрессов как у людей, ни комментариев в тасках;
внятных описаний доработок, бизнес-требований и технических заданий у нас также не было.
Если подытожить, то первым большим шагом мы собрали все, как есть, и на общекомандной ретре приняли решение — пора тюнить процессы! Поэтому вторым шагом мы решили сделать верхнеуровневое описание процесса разработки — наше общее командное TO BE — от момента получения ЗНИ от бизнеса до момента передачи готовой функциональности на приёмку.
Строить качество должны не только тестировщики, надеюсь, мои уважаемые читатели это понимают, поэтому верхнеуровневое описание процесса TO BE было распределено по направлениям для бОльшей детализации и проработки: аналитика, разработка и тестирование писали свои TO BE, входы и выходы из этапов, контрольные точки, а потом, на общем собрании — обсуждали, прорабатывали и исправляли.
Поскольку я из тестирования, то больший упор сделаю на своём направлении, расскажу, на что мы стали обращать внимание на выходе из этапа тестирования требований, как мы проводим тестирование самой доработки и как передаем ее в руки наших пользователей.
Выход из этапа Аналитика
Чтобы задача покинула этап аналитики и двинулась дальше, должно быть проведено тестирование требований. Само по себе тестирование требований не является каким-то гейтом, нет, это лишь правильный процесс работы над ЗНИ или новыми фичами. Но вот на выходе из этого этапа — я про критерии приёмки — уже находятся гейты. Их-то мы и стали использовать, и нам очень понравилось, как это работает! Отмечаем, первый гейт на выходе задачи из аналитики — наличие внятных, однозначных и проверяемых критериев приемки.
В идеальном мире критерии приемки являются для тестировщиков готовыми ожидаемыми результатами будущих тест-кейсов (кстати, не кривя душой, пару раз мы достигли этого самого идеала). У нас на проекте, если критерии приемки отвечают требованиям непротиворечивости, проверяемости, необходимости, полноты, осуществимости и однозначности, значит, этот гейт пройден.
Следующий гейт на выходе задачи из аналитики — задача на тестирование ТЗ закрыта тестировщиком. Дорогой читатель обратит внимание на последнее слово, закрыта тестировщиком. Да, это очень важный момент, потому что однажды (и этого раза хватило всем с лихвой) мы столкнулись с неприятным обстоятельством: таску на тестирование ТЗ закрыл сам аналитик, а мы не обратили внимание, закрыта — да закрыта.
Аналитик, не исправив замечания и не проведя дополнительных мероприятий, таких как синхрон с бизнесом по вопросам от тестирования и парочки противоречивых моментов, передал задачу в разработку.
Задачу даже сделали, показали заказчику, но столько охов и вздохов я еще не слышала: пришлось переделывать, потом ещё раз и еще. Задолбались тогда и ТЗ править, и кейсы переписывать, и переругались все в пух и перья! Не понравилось всем, решили больше так не делать. Согласитесь, спешка до добра не доведёт и, более того, спешка — это совершенно не повод делать ерунду, в которой потом сам черт ногу сломит.
Что получилось: аналитик торопился, хотел поскорее отдать задачу в реализацию, но своими действиями удвоил или даже утроил стоимость задачи и ее time-to-market.
Теперь на этапе аналитики у нас в паре работают гейты: критерии приёмки плюс таска на тестирование закрыта тестировщиком.
Если что-то одно не готово, гейт считается непройденным, задача никуда дальше не пойдет.
Когда ТЗ прошло внутреннее тестирование и свои первые quality gates, оно передается в разработку.
Разработчик оценивает трудоемкость задачи, задает какие-то финальные вопросы аналитику и, потирая в нетерпении руки, начинает писать код.
Когда мы завершили пул работ с ТЗ и согласовали критерии приёмки, и пока разработчики пишут код, мы приступаем к написанию кейсов. Да, они могут немного поменяться, когда задача будет реализована, не беда, ведь кардинально ничего уже не изменится, и в худшем случае нам нужно будет уделить пару часов времени для полной актуализации. В лучшем — актуализировать ничего не придется. А всё потому, что принятые, согласованные и одинаково интерпретируемые всей командой критерии приёмки будут являться ожидаемыми результатами наших кейсов. И это прекрасно.
По понятному и предварительно оттестированному ТЗ очень хорошо проводятся проверки, создается впечатление, что ты уже давно знаком с функциональностью и каких-то новых вопросов в процессе проверки у тебя не возникает.
Выход из этапа Разработка
Чтобы задача спокойно перешла из разработки к нам, в тестирование, я предложила возможными гейтами здесь сделать следующие, на мой взгляд, основные вещи:
код написан и залит на тестовый стенд;
задача назначена на тестировщика (кстати говоря, после “Подлодки” сюда были добавлены еще пара гейтов, над внедрением которых мы, тестирование, сейчас активно работаем);
в задаче дано краткое описание по шаблону: что именно сделано, что было задето в процессе, и для QA: на что обратить особое внимание (надо сказать, что с внедрением этого гейта мы мучались, почему — никто не может сказать, просто разработчики или забывали отписываться в тасках, или просто не считали нужным это делать, прорабатывали эту проблему на нескольких «ретро» подряд, объясняли, договаривались, пока полет нормальный).
Выход из этапа Тестирование и передача в Пользовательское тестирование
Далее снова вступаем мы с коллегой, когда задача выходит из этапа тестирования: гейтами здесь мы решили поставить «зеленые галочки», сигнализирующие, что кейсы по задаче пройдены, таска на тестирование закрыта тестировщиком, в задаче дано краткое описание о проделанной нами работе, а сама задача передвинута вправо по доске, ожидая пользовательского тестирования и выливки на прод.
Кроме того, чтобы задача «двинулась» дальше, должны быть исправлены все блокирующие и критические дефекты, обнаруженные в процессе тестирования, а остальные дефекты локализованы и назначены на разработчика.
Когда разработчики все сделали по красоте, мы, тестирование, оставили свои заметки и подробнейшие тест-кейсы, задача переходит на этап пользовательского тестирования.
И вы не представляете, как круто и приятно, когда команда, работающая над доработкой, получает письмо от бизнес-пользователей с заветными словами «Согласовано в %ближайший% релиз, спасибо!» и кучу благодарностей в личку.
Здесь, наверное, стоит заканчивать свое повествование и переходить к итогам и рассуждениям.
Итоги и рассуждения
То, что quality gates работают, у меня никогда не было сомнений, но я даже и представить не могла, что эти совсем небольшие точечные изменения смогут сдвинуть в лучшую сторону целые процессы, которые годами казались несдвигаемыми с места монолитами.
В итоге, кроме счастья и сбереженных нервов всей команды, мы сократили время работы над задачей, активно разбираем бэклог, снизили количество коммуникаций в команде и с бизнес-пользователями (последние, кстати говоря, тоже счастливы) и повысили качество выпускаемых нами доработок!
Надеюсь, моя история поможет кому-то внедрить контрольные точки у себя на проектах и сделать работу качественнее, быстрее и прозрачнее. Поэтому, не бойтесь потратить время на объяснения, продумывание и внедрение «врат качества», оно того стоит!
Как и обещала в начале статьи, оставляю список горячо рекомендованной литературы по бережливому производству и непрерывному совершенствованию
