Ни для кого не секрет, что QA — это процесс обеспечения качества. Но как можно обеспечить качество продукта, если качество самого процесса тестирования под большим вопросом?
Конечно, когда дело касается микро-стартапов, в команде которых всего пара человек: разработчик, он же и аналитик по совместительству, да и тестировщик, то сильно задумываться над построением процессов не имеет смысла. Но вот в крупном продукте, где команда тестирования состоит из трех и более человек, чтобы эффективно выполнять задачи, приходится налаживать процессы. Когда вокруг царит процессный хаос, сложно сосредоточиться на обеспечении качества, и высока вероятность что-то упустить из виду: где-то - сделать двойную работу, где-то, наоборот, что-то забыть. Вот от этого хаоса постараемся сегодня избавиться, разложив процесс тестирования по полочкам следуя советам Никиты Ткаченко, инженера по тестированию iiii Tech (“Форайз”).
Вспоминаем жизненный цикл ПО
Чтобы четко формализовать процесс, необходимо понимать что и когда необходимо делать тестированию. Для этого давайте вспомним чуть упрощенный жизненный цикл ПО: работа с требованиями -> разработка -> тестирование -> внедрение и эксплуатация. И если мы работаем по гибкой методологии, то включаться в процесс разработки ПО мы - команда тестирования - должны как можно раньше. Рассмотрим, что можно сделать на каждом из этих этапов.
Работа с требованиями
Кроме самого очевидного - тестирования самих требований - на ранних этапах стоит подумать что и как будем проверять. В этом нам помогут декомпозиция, тест-план и оценки:
1. Декомпозиция: как гласит народная мудрость, "слона нужно есть по кусочкам", и в нашем случае удобнее всего это сделать в виде майнд-карты - так мы структурируем требования по логическим модулям и создадим себе шпаргалку для будущих проверок.
2. Тест-план: говоря о тест-планах, многие вспоминают нечитабельные "талмуды", изобилующие практически никогда не используемой информацией. Но тест-план должен быть удобен прежде всего для участников процесса и формат его выбираете вы. А потому, возможно, и не стоит расписывать кто заказчик продукта, какова его ценность, критерии начала и окончания тестирования, какие виды тестирования планируете применять и так далее. А вот заранее подсветить возможные риски, оценить зависимости от других продуктов и команд, определить возможное регрессионное влияние - всегда полезно.
3. Оценки трудозатрат: прогнозы — это хорошо, а сбывшиеся прогнозы - вдвойне хорошо! Думаю, нет смысла лишний раз говорить насколько важно планирование трудозатрат и сроков для разработки продукта в целом.
На первый взгляд кажется, что все вышеописанное — это просто лишняя работа. Но, во-первых, их необходимость для себя команда тестировщиков определяет самостоятельно, а во-вторых, много времени они не занимают, а вот сэкономить при этом могут очень много - проверено не раз. Пожалуй, самым показательным случаем на моей практике оказалась одна небольшая задача: ее релиз был привязан к определенной дате, но работы по ней было буквально на неделю и потому никто особо не переживал за сроки. Однако, все забыли, что получить тестовые данные, необходимые чуть ли не на последнем этапе работы над задачей, нам потребуется от третьей стороны, согласования с которой могут занять длительное время. К счастью, этот риск мною был учтен заранее и этап согласования начался параллельно с работой непосредственно над задачей. И в итоге он занял практически ту же неделю, что и помогло закончить работу прямо к дедлайну. Упусти мы этот момент на этапе планирования, и та самая неделя согласований добавилась бы сверху.
Разработка
Бытует мнение, что на этапе разработки, как следует из названия, эстафета передается разработчикам, а тестированию здесь делать нечего. Но нет, это самый подходящий момент начать тест-дизайн, подготовку тестовых данных и окружений, насколько это возможно. Как и при приеме гостей, стол следует накрыть заблаговременно и при приходе гостей останется лишь подать горячее, так и к моменту начала тестирования все к нему должно быть готово. Иначе могут возникнуть неприятности как, например, необходимость заказа "железа" или девайсов, которые за один день не решаются, или сложность подготовки тестовых данных, если для этого требуются дополнительные коммуникации или согласования. Все это на пользу релизу явно не пойдет.
Тестирование
Этап выполнения проверок непосредственно. Все делается легко и непринужденно, так как о большинстве вопросов мы позаботились заранее. Кроме того, работы на этом этапе можно делегировать даже пока еще не самым опытным сотрудникам - все необходимое есть, остается только следовать инструкциям и проходить кейсы. По окончанию тестирования стоит также оформить некий паспорт качества релиза, где можно будет оценить качество релиза в целом, отметить известные, но пока еще не решенные проблемы, сравнить оценки с реальными трудозатратами и прочее, что поможет позже оценить свою работу.
Внедрение и эксплуатация
С окончанием тестирования работа QA-инженеров не заканчивается: после внедрения рано или поздно прозвучит нежеланное "баг с прода!". Как бы команда тестирования ни старалась, все досконально проверить невозможно. И здесь просто исправить и забыть нельзя. Баг — это следствие, а команде прежде всего нужно понять причину и "починить" уже ее, чтобы в дальнейшем такое не происходило.
Работа внутри команды
Взаимодействие внутри команды также крайне важно наладить и для этого есть несколько подходов:
* Прозрачность: участники команды должны всегда понимать кто чем занимается. Но не контроля ради, а для рационального распределения задач - чтобы не выполнять одну работу вдвоем, а другую полностью оставлять без внимания. Для этого можно использовать как регулярные синки или специальные инструменты, так и просто мессенджеры - удобный способ для себя определяете вы сами.
* Нивелирование бас-фактора: сосредоточение знаний в “одной голове” - плохая идея. Уйди сотрудник в отпуск, на больничный или вообще из проекта, и целый пласт знаний в определенной функциональности уйдет вместе с ним. Решить эту проблему заранее поможет постоянный шаринг знаний (в виде встреч или инструкций - как удобно) или распределение компетенций в виде привлечения к задачам нескольких тестировщиков. Как это сделать в условиях ограниченных ресурсов? Очень просто: вместо подхода "один человек на одну задачу" применять "два человека на две задачи". Казалось бы, одно и то же, но во втором случае оба будут в курсе обеих задач, а степень погружения можно варьировать. Но главное, что всегда есть дублирующий.
Единый стиль
Разработчики в своей работе зачастую придерживаются определенного code style - набора правил и подходов при написании кода. Так и в тестировании следует применять подобный подход: определите требования к написанию тест-кейсов, созданию баг-репортов и прочих других артефактов. Условьтесь в их степени детализации, оформлении и придите к некой шаблонизации - так будет обеспечен единый стиль. Паттерны воспринимаются быстрее и проще, чем каждый раз уникальный авторский подход, зависящий от сотрудника.
Долой бюрократию
Документация и артефакты тестирования должны решать проблемы, а не создавать их! На моей практике был случай, когда один из артефактов, потребителем которого была другая команда, создавался вручную в виде docx-файла с оформлением таблиц и копированием туда множества ссылок. Занимало это зачастую не один час, не говоря уж о рутинности такой работы. На мое возражение о нелогичности такой документации коллеги мне ответили что так исторически сложилось и такие требования потребителя. Конечно, так просто я не сдался и пошел выяснять почему так. На мое удивление, потребитель ответил что им по большому счету все равно в каком виде, главное получить нужную информацию. Час работы над новым форматом в confluence, немного автоматизации средствами плагинов и теперь артефакт создается за... 30 секунд. Без документации, конечно, нельзя. Но решите что из нее не используется и может быть упразднено, а что - упрощено и автоматизировано.
Качественные процессы не существуют без коммуникаций
Как бы команды ни были хороши по отдельности, задача у них общая. Взаимодействие с другими командами - аналитиками, архитекторами, разработчиками, дизайнерами - очень важно. Требования могут вдруг поменяться, может возникнуть понимание что текущая реализация неудобна, или возникнут разночтения. Один уточняющий вопрос может сэкономить очень много времени, а вовремя подсвеченная проблема - положительно повлиять на сроки вывода релиза. Общайтесь и желательно не в личных сообщениях, а в тематических каналах вашего корпоративного мессенджера - так все заинтересованные участники смогут вступить в обсуждение и помочь, или просто быть в курсе. Не забывайте фиксировать договоренности где-то за пределами мессенджеров - переписки имеют свойство теряться.
Эволюционируй и строй СВОЙ процесс
Идеальных процессов и универсальных подходов к ним не бывает. Неудачный опыт применения чужих "историй успеха" не говорит о проблемах явно - просто в конкретном случае этот подход мог не подойти. Построить все сразу хорошо вряд ли получится и начинать нужно постепенно, при этом периодически посматривая на свои процессы со стороны и оценивая результаты. А далее - постоянный процесс эволюционных изменений до тех пор, пока не придет осознание что "вот, это то, что мы и хотели! Теперь все работает как надо!"
