Управление документацией QA: чек-лист эксперта
Изображение: NONGASIMO/shutterstock.com
Стандарты для процесса QA
Когда речь идет о процессе обеспечения качества, стандарты играют ключевую роль. Мне и моей команде они помогли сделать рабочий процесс более упорядоченным, прозрачным и, что самое главное, эффективным. Давайте разберёмся, что такое стандарты в QA и почему они так важны.
Сперва нужно определить цикл разработки у вашего продукта. В основные этапы цикла разработки входят: аналитика, разработка и релиз. QA должен участвовать на всех стадиях. Получается, после аналитики должна собраться команда из аналитика, разработчика, тестировщика и сделать ревью. То есть проверить ее, задать все вопросы и синхронизировать контекст. Кстати, QA уже «тестирует» аналитику и может выявить баги и ошибки до разработки.
После этого начинается тестирование, которое желательно делать сразу и не откладывать. Это поможет решить многие проблемы сразу и сократить «пинг-понг» — так как разработчик еще помнит код, ему просто понять, где проблема, а не вспоминать, что он делал два месяца назад. В идеале использовать автоматизированное тестирование.
Автотесты помогают проверять не только текущие изменения, но и весь продукт в целом (или его части). Это позволяет убедиться, что все работает корректно и соседние компоненты не сломаны. Но автотесты — это не только про регрессионное тестирование. Они имеют гораздо больше плюсов.
Благодаря опыту работы я выяснил следующие их преимущества:
- Автотесты ускоряют тестирование, так как выполняются быстрее ручных проверок.
- Их можно запускать в любое время, даже ночью или перед каждым коммитом.
- Мгновенная обратная связь о стабильности продукта.
- Экономия времени и сил по сравнению с ручным тестированием.
- Исключают человеческий фактор: автотесты не устают и не делают ошибок из-за невнимательности.
- Особенно полезны для проверки больших объемов данных и повторяющихся действий.
- Позволяют запускать тысячи проверок, включая сложные сценарии, которые сложно тестировать вручную.
Автоматизация особенно полезна в условиях коротких циклов релиза, когда на регрессионное тестирование остаётся мало времени. К тому же, автотесты можно запускать на разных устройствах и операционных системах. Это помогает находить баги, которые могут проявляться только в специфических условиях.
Еще важно помнить, что в больших компаниях мы не единственная команда, и наш продукт взаимодействует с другими сервисами. Тут необходимо проводить интеграционное тестирование, чтобы убедиться, что мы не сломали интеграцию с соседними сервисами. В противном случае после релиза у нас может отвалиться большой сегмент всей системы.
И, конечно же, тестирование на продакшене. С его помощью мы проверяем что релиз прошел хорошо. Это можно делать через метрики или тесты. Тестирование на продакшене — ответственная часть. Если есть возможность, лучше сделать легкие тесты, которые проверяют базовые сценарии и работоспособность продукта. Но обычно это проверяется руками. В этом случае рекомендую сделать чек листы или инструкции, чтобы каждый знал что стоит посмотреть и как правильно проверить все ли ок.
Как поддерживать актуальность документации
Важно, чтобы документация не превратилась в бесполезную стопку бумаг или записи в confluence. Но как это сделать?
Все зависит от типа документации. Если она внутренняя, для вашей команды, рекомендую применять подход «doc as code». То есть храним документацию внутри проекта или продукта в виде markdown файлов. Тем самым мы сокращаем количество инструментов, так как документ лежит возле кода, и с ним можно работать из IDE (среды интегрированной разработки) не выходя в браузер.
Для документации внешних потребителей или отделов мы в команде придумали систему чек-листов в задачах. Чек-лист автоматом создается для каждой цели. Там мы прописываем, где и что нужно обновить и кого предупредить, чтобы они поменяли документацию. Тем самым, когда мы открываем задачу, вспоминаем, что нужно сделать. Это упрощает работу и ввод новых сотрудников. Они, видя чек-лист, один раз, спросят, что делать, и дальше отправятся в свободное плаванье.
В команде мы регулярно проводим ревью документации на предмет ее актуальности. Проведение такого аудита раз в полгода или год позволяет убедиться, что все соответствует текущим потребностям и процессам. Если какие-то документы устарели или дублируют информацию, их необходимо либо обновить, либо удалить.
Например, однажды в нашей команде мы заметили, что документация тестировщиков почти полностью дублирует документы, созданные аналитиками. Мы приняли решение объединить их, удалив дублирующую документацию тестировщиков и добавив недостающую информацию в документацию аналитиков.
Как QA-инженер, я считаю, что использование чек-листов — это очень полезная практика. Как тимлид, я заметил, что они не только упростили общение между командами, но и улучшили качество продукта. Особенно полезны они были на этапах, где легко допустить ошибку из-за человеческого фактора. Например, при ручном тестировании или регрессионных проверках, когда можно забыть о мелочах в условиях нехватки времени.
Стоит поговорить и о процессах, которые замедляют работу с документацией. Речь идет про большое количество инструментов и источников информации. Когда у вас код в одном месте, а документация в другом и лежит еще в разных форматах, постарайтесь уменьшить количество источников. А если это сделать нельзя, напишите инструкцию, что, где и в каких ситуациях нужно обновить. Так это будет меньше забываться.
Роль команды в управлении документацией
У каждого в команде есть общая цель — создать успешный и качественный проект. Если хотя бы один не будет применять новые стандарты, эта инициатива потерпит крах. Документация — не просто формальности. Она помогает хранить и передавать знания. Поэтому, когда появляются новые стандарты важно, чтобы все были в курсе и могли ими пользоваться.
Как же это делать? Вот несколько простых шагов:
- Во-первых, соберите команду и объясните какая проблема появилась. Расскажите о новом стандарте и его преимуществах. Тут важно добиться понимание команды и ее одобрения, так как без этого новые подходы выполняться не будут. Возможно вы услышите критику и обоснованную аргументацию. Нужно все учесть и совместно разработать новый подход.
- Поймите, что эти подходы не выполнятся сразу. Нужно выработать привычку. Тут важно не наказывать коллег если они забыли что-то сделать, а вежливо напоминать о договоренности (о ней вы договорились на первом шаге).
- Создайте собственные чек листы. Со временем становиться очень много правил и договоренностей, их можно забыть в пылу работы. Но если у вас на каждом этапе есть «напоминалки» перед переходом на следующий, это облегчает работу.
Самое главное — диалог с командой. Лучше, если не вы спустите директиву, а обозначите проблему и совместно выработаете решение и подход. Так сотрудники почувствуют, что это их инициатива, и будут выполнять ее гораздо активней, чем простой приказ.
Итак, подводя итог нашему разговору об управлении документацией QA, можно выделить несколько ключевых моментов. Документация — это не просто бумажки или записи в confluence, а важный инструмент, который помогает организовать процесс тестирования, сделать его более структурированным и эффективным.
Создание чек-листов по вашему собственному опыту упростит жизнь всем сотрудникам. Но не стоит забывать про мнение каждого в команде. Работа сообща выведет ваши процессы на новый уровень.
Опубликовано 08.10.2024
