Всем привет, меня зовут Максим, я QA-специалист в компании SimbirSoft. Более двух лет я занимаюсь обеспечением качества, за это время мне часто попадались проекты с отсутствующей или устаревшей документацией. Как быть в подобной ситуации и при этом сохранить нервные клетки, я расскажу в этой статье.
Бывают ситуации, когда тестировать приходится вопреки. Вопреки срокам, здравому смыслу или отсутствию требований. Именно последний кейс мы и разберем с вами сегодня :)
Как так получилось?
Существует множество причин, по которым в тестирование попадает сервис или функциональность без исчерпывающе описанной документации и требований. Давайте рассмотрим три основные.
Сделали по аналогии
Это самая частая причина :) Ситуация: нужен новый сервис. Команда посмотрела на соседей и сказала – «Такой сервис уже есть в соседней команде, поэтому мы просто скопируем. Отдельную документацию можно не делать».
Как бы привлекательно ни звучали эти речи, в большинстве случаев на этапе тестирования данная схема вдруг становится не такой очевидной. Подходя к этапу тестирования, что же остается нам? Тестировать по документации из того места, где собственно и взяли наш сервис. Это сопряжено с рядом рисков, например:
Что, если документация не актуальна? Наш аналитик в сервис не вникал, а аналитик из соседней команды вполне может уйти в отпуск или заболеть. Что же делать? Кто-то должен разобраться в сервисе. В таком случае есть два варианта – либо взвалить это на плечи собственного аналитика, либо пытаться разобраться самостоятельно, по возможности, вместе с разработчиком из соседней команды.
На этапе интеграции поняли, что чего-то не хватает, но не понимаете, чего именно. Очень распространенный сценарий. Для начала нужно сходить в логи и локализовать на доступ — определить, к какому ресурсу система выдаёт ошибку: это может быть база данных, пользователь в RabbitMQ и т.д. Если проблему локализовать не удалось, переходим к проверке конфигурационных файлов сервисов (при наличии доступа) — как своего сервиса, так и того, из которого копировали настройки, и сравниваем секцию с подключениями. Если прокидывали своих пользователей, то проверяем, совпадают ли их права доступа с правами пользователей сервиса-донора.
Ничейный сервис — это сервис, разработанный достаточно давно, о котором нет информации в корпоративной базе знаний. Это наихудший вариант: устареть могло всё, включая документацию. В таком случае стоит поискать людей, которые его релизили или хотя бы с ним работали. Вероятность того, что они вспомнят и расскажут всё в деталях, невелика, но общее, верхнеуровневое представление о работе сервиса получить всё же можно. Не будет лишним также привлечь разработчика и аналитика — так называемый формат 3 amigos, когда представители разных ролей вместе анализируют задачу и ищут решения.
Ищите любые обрывки документации и всех людей, которые так или иначе были причастны к работе с сервисом. Важно донести до лидов, что для этого сервиса необходима отдельная, полноценная документация. Это сейчас сервис идентичен по функциональности, но вполне вероятно, что его придется расширять, вводить новый функционал и, банально, поддерживать. В такой ситуации самым ценным кладом можно считать бизнес-требования сервиса-донора — по ним вполне можно построить тестовые сценарии и хотя бы частично восстановить логику работы. Возникает вопрос: почему этим вообще должен заниматься QA-специалист? Бывают случаи, когда в команде нет тимлида, и эту роль на проекте выполняет QA. Или по какой-то причине тимлид отсутствует на проекте в текущий момент, например, находится в отпуске или на больничном.
Хтоническое чудовище
Представьте: вы на большом проекте в одной из многих продуктовых команд, но вот несчастье – кто-то наверху вспомнил про Legacy-сервис, который в последний раз трогали довольно давно, а все люди, причастные к этому, уже покинули компанию.
Но со всем нужно разбираться постепенно. Поэтому привожу краткий чек-лист, что делать в подобном случае:
Прошерстить корпоративную базу знаний. Ищем по названию сервиса, в приоритете бизнес-требования (BR) -> функциональные требования (FR) -> архитектурная схема (самого сервиса) -> архитектурная схема (общая, но на которой отображен наш сервис) -> задачи на доработку сервиса -> различные баги, отчеты о тестировании, задачи на мониторинг, результаты нагрузки, словом все, где может фигурировать кейс с описанием того, что делает сервис, а в идеале – найти что-то похожее на модель сообщения и выявить, куда оно идет/от кого приходит.
Если ничего не нашли, идем ко всем причастным, кто еще остался. В случае, если не знаем к кому идти, направляемся к лидам, с их помощью получаем контакты – любая крупица информации важна.
Никого не осталось? Придется разбираться самостоятельно. Необходимо понять, жив ли вообще сервис. Если жив, значит можно с ним взаимодействовать. Прикидываем сообщения, смотрим логи, модель сообщения можно взять в тех же логах, смотрим к кому сервис передает данные, от кого получает, идем к командам ответственным за эти сервисы и узнаем, для чего они его используют.
Документации и людей, которые делали сервис, нет, а сам сервис скорее мертв, чем жив. Нужно понимать, что в таком случае «быстрого» решения не будет. Единственный человек, который может что-то понять – это разработчик. Отправляем его читать код и разбираться что к чему. Результаты обсуждаем в 3 amigos (подход в методологии Agile, где организуется встреча с QA, бизнес-аналитиком и разработчиком для преодоления пробелов в понимании бизнес-требований и ожиданий клиентов) и пытаемся на основе полученной информации составить функциональные требования, от которых и будем отталкиваться при написании тестовой документации.
Не делали
Бывают и такие кейсы, когда вы заходите на проект и выясняется, что команда по какой-то причине не вела документацию по сервису и не понимает, зачем это нужно, объясняя это примерно так: «У нас раньше не было QA, и никто не жаловался». Грустная, но часто встречающаяся ситуация.
Первым делом нужно аргументировать необходимость создания и ведения документации. Важно подсветить, что её отсутствие может привести к дополнительным расходам для клиента, как из-за роста количества дефектов, так и банально из-за сложности поддержки сервиса без документации. В таком случае либо выделят дополнительного аналитика, либо поручат составление документации вам. Если поручили вам — воспринимайте это как возможность: вы и прокачаете свои профессиональные навыки, и облегчите себе дальнейшую работу, и получите более глубокое понимание сервиса.
Внедрять документацию, конечно, хорошо, но это задача на будущее, а тестировать сервис нужно уже сегодня. Если сервис разработан, значит, кто-то ставил задачу разработчику и объяснял, как этот сервис должен работать. Именно к этому человеку и следует обратиться в первую очередь. Нужно понимать, что разработчики чаще всего воспринимают сервис как набор функций, а нам для полноценного тестирования нужны сценарии. Поэтому идем к владельцу продукта или заказчику — напрямую либо через PM, в зависимости от вашего флоу. Бояться заказчика не стоит: именно он больше всех заинтересован в том, чтобы система удовлетворяла всем необходимым бизнес-требованиям.
Как быть, если аналитика нет и не планируется?
Независимо от того, какой именно кейс нам попался, одно остается неизменным: документации нет. Но документация обязательно должна быть! Но кто будет воплощать этот лозунг в жизнь — вопрос открытый.
Рассмотрим сначала более оптимистичный сценарий: у нас в команде есть аналитик. В таком случае вопрос решается просто — кандидат уже есть. Однако, возможно, потребуется обосновать необходимость документирования сервиса. Воспользуемся этой возможностью, приведем аргументы, подсветим риски, а в случае нехватки ресурсов попросим хотя бы описать бизнес-требования (BR).
Что делать, если аналитика в команде нет? Здесь два пути: либо попросить выделить аналитика из другой команды (при возможности), либо взять эту задачу в свои руки.
Тестирование по user story и как описать их со слов заказчика
Бизнес-требования со слов заказчика
Ситуация: бизнес-требований нет, но заказчик описал свои пожелания по переписке, и теперь мы хотим их реализовать.
На проекте имеется аналитик? Отправляйте его на «разведку» и попросите преобразовать пожелания заказчика в полноценное ТЗ. В ином случае займитесь этим сами или привлеките продуктового владельца (Product Owner, PO) — в зависимости от вашего флоу.
Не уверены в своих силах? Пообщайтесь с командой, составьте примерные требования и обсудите это на совместном созвоне, выявив, чего не хватает. Также можно обратиться в соседние команды: возможно, они уже решали похожие задачи, и их опыт пригодится. После подготовки требований обязательно вернитесь к заказчику, чтобы подтвердить и согласовать окончательную версию.
- Как понять полноту покрытия?
Уже закончили? :)
Как понять без документации, что мы закончили с тестированием? Какие у нас критерии остановки? Как оценить полноту покрытия?
Что касается полноты тестирования, то при недостатке документации следует поставить себя на место пользователя, определить скоуп основных пользовательских сценариев и в исследовательском режиме покрыть их тестами.
Закончились сценарии и осталось время? В этом случае есть два пути: либо мы занимаемся восстановлением или написанием документации, либо, если этим уже занят аналитик, приступаем к ad-hoc-тестированию и проверяем все подряд в надежде обнаружить баг.
Критериями остановки тестирования можно считать, когда:
- Выделен и протестирован основной скоуп пользовательских сценариев.
- Бизнес-требования покрыты тестами и протестированы (при наличии).
- Интеграции сервиса протестированы.
- Если в задаче есть фронт (выделить курсивом). Проверено влияние текущей задачи на все связанные фронт-элементы, выявлено, что верстка не поехала, и затрагиваемые элементы не претерпели внеплановых изменений.
- Как отсутствие документации скажется на поддержке?
А ведь кому-то это всё поддерживать :)
Что может быть сложнее разработки без полноценной документации? Поддержка проекта без документации.
Зачастую, если на проекте недостаточно ресурсов аналитики или слишком высокая скорость разработки, бизнес-требования и spec-документация могут начать отставать и становиться неактуальными. Однако даже устаревшая документация все же лучше, чем ее полное отсутствие: в крайнем случае всегда можно взять старые материалы, свежую задачу на доработку и разобраться, что к чему. Как я уже говорил, важно продвигать этот вопрос: вам предстоит работать с этим сервисом, актуализировать свои тестовые сценарии, проводить регрессию и ретесты. Если заниматься документацией некому, делайте ее самостоятельно. Не бойтесь, что вас раскритикуют за неточности — это изначально не ваша зона ответственности. Выполняя эту работу, вы не только облегчите себе жизнь, но и круто прокачаете свои скилы.
Заключение
Безвыходных ситуаций не бывает — бывают ситуации, когда приходится брать на себя чужую работу, которая выходит за рамки ваших прямых обязанностей:
Не бойтесь браться за задачи, которые находятся вне вашей зоны ответственности.
Не стесняйтесь задавать вопросы и активно искать информацию у коллег. В конце концов, не вы ответственны за то, что разработка велась без надлежащей аналитики.
Подсвечивайте риски такой ситуации и настаивайте на постановке задач по аналитике.
Если кажется, что тестирование неполное, поставьте себя на место пользователя: проверьте все кнопки, попробуйте «сломать» систему, применяя ad-hoc-подход.
Не забудьте проверить интеграции.
Не бойтесь экспериментировать и всегда смотрите на задачи через призму собственного опыта и специфику вашего проекта.
Спасибо за уделенное время! Надеюсь, моя статья будет полезной и, возможно, поможет вам найти подход к решению возникших проблем :)
Возможно, тебе будут интересны и другие наши статьи по QA:
ИИ в тестировании ПО: возможности, ограничения, эксперименты и практический опыт
QAOps: новый этап эффективности тестирования ПО
Рецензия на книгу «Идеальный тестировщик» Кристин Джеквони
5 стадий принятия: как протестировать плагин на разных версиях браузера
Авторские материалы для QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.