«Сесть и плакать – не наш путь»: что делать, если на IT-проекте нет документации

Документация – “волшебная палочка” для специалиста, которая дает представление о работе программного обеспечения: содержит инструкции, примечания, диаграммы, включая материалы исходного кода и учебные материалы, информацию об архитектуре проекта, тестирование и т.д.

Но что делать, если приходишь в “новую динамичную развивающуюся компанию”, а там документации примерно ноль? Этот вопрос раскрыла опытная QA Engineer Ольга Маркова в своем LinkedIn.

«В теории на проектах, куда приходишь работать, есть бизнес аналитик, хорошо расписанная документация по проекту в Confluence, тестовая документация в TestRail, вам предоставляют доступ ко всему необходимому. Работай и радуйся. А вот на практике так бывает не всегда», – утверждает специалист.
По ее опыту, встречаются проекты, которым год-два или больше, и все это время они работали без QA. Так что здесь нет не только тестовой документации, а вообще никакой.

Что делать?

«Сесть и плакать – не наш путь», – говорит тестировщица и предлагает несколько вариантов выхода из ситуации:

1. Узнайте, что вообще есть. Все равно где-то могут «валяться» какие-то требования, схемы, документация к АРI или коллекции Postman… Расспросите коллег и просите вам дать это.
2. Изучите инструкции для пользователей. На многих проектах они все-таки есть, и это уже хорошая отправная точка – оттуда можно выбрать некоторые требования (например, размеры изображений) и в целом понять, как работает продукт, разобраться в основном функционале.
3. Поговорить с СТО, старшим разработчиком, кем-то из «старожилов» на проекте или клиентом – расспросить о продукте, какова его идея, как компания «делает деньги», почему этот функционал работает именно так, а не иначе.
4. Попросить доступ к GitHub и базе данных, если возможно. Можно посмотреть комиты и увидеть, что делалось на проекте в последнее время. Если умеешь читать код, вообще прекрасно.
5. Попросить доступ к Google Analytics. Здесь можно увидеть, под какие устройства, ОС и браузеры нужно тестировать, сколько пользователей есть, из каких стран, какого возраста, какие страницы самые популярные, из которых пользователи выходят, откуда идет трафик.
6. Провести исследовательское тестирование.
7. Не стесняться расспрашивать у коллег все, что непонятно или вызывает сомнения. Лучше переспросить, чем делать кучу никому не нужной работы.

«Параллельно с этим нужно начать создавать документацию самостоятельно! Хотя бы схематическую, хотя бы общую. Составлять чек-листы, строить диаграммы перехода состояний, таблицы связей, делать анализ влияния, – говорит Ольга. – То, что вы один тестировщик на проекте не означает, что можно забить на документацию (никому же кроме вас она типа не надо) и просто заводить багульки в Jira».

Она советует сделать все, что поможет вам тестировать быстрее и лучше, проводить регрессию или ввести автоматизацию:

• Написать чек-листы, если тест-кейсы кажутся избыточными или небольшими.
• Сделать документацию к API.
• Нарисовать таблицу с описанием зависимостей.