«Сесть и плакать – не наш путь»: что делать, если на IT-проекте нет документации
Документация – “волшебная палочка” для специалиста, которая дает представление о работе программного обеспечения: содержит инструкции, примечания, диаграммы, включая материалы исходного кода и учебные материалы, информацию об архитектуре проекта, тестирование и т.д.
Но что делать, если приходишь в “новую динамичную развивающуюся компанию”, а там документации примерно ноль? Этот вопрос раскрыла опытная QA Engineer Ольга Маркова в своем LinkedIn.
«В теории на проектах, куда приходишь работать, есть бизнес аналитик, хорошо расписанная документация по проекту в Confluence, тестовая документация в TestRail, вам предоставляют доступ ко всему необходимому. Работай и радуйся. А вот на практике так бывает не всегда», – утверждает специалист.
По ее опыту, встречаются проекты, которым год-два или больше, и все это время они работали без QA. Так что здесь нет не только тестовой документации, а вообще никакой.
Что делать?
«Сесть и плакать – не наш путь», – говорит тестировщица и предлагает несколько вариантов выхода из ситуации:
- Узнайте, что вообще есть. Все равно где-то могут «валяться» какие-то требования, схемы, документация к АРI или коллекции Postman… Расспросите коллег и просите вам дать это.
- Изучите инструкции для пользователей. На многих проектах они все-таки есть, и это уже хорошая отправная точка – оттуда можно выбрать некоторые требования (например, размеры изображений) и в целом понять, как работает продукт, разобраться в основном функционале.
- Поговорить с СТО, старшим разработчиком, кем-то из «старожилов» на проекте или клиентом – расспросить о продукте, какова его идея, как компания «делает деньги», почему этот функционал работает именно так, а не иначе.
- Попросить доступ к GitHub и базе данных, если возможно. Можно посмотреть комиты и увидеть, что делалось на проекте в последнее время. Если умеешь читать код, вообще прекрасно.
- Попросить доступ к Google Analytics. Здесь можно увидеть, под какие устройства, ОС и браузеры нужно тестировать, сколько пользователей есть, из каких стран, какого возраста, какие страницы самые популярные, из которых пользователи выходят, откуда идет трафик.
- Провести исследовательское тестирование.
- Не стесняться расспрашивать у коллег все, что непонятно или вызывает сомнения. Лучше переспросить, чем делать кучу никому не нужной работы.
«Параллельно с этим нужно начать создавать документацию самостоятельно! Хотя бы схематическую, хотя бы общую. Составлять чек-листы, строить диаграммы перехода состояний, таблицы связей, делать анализ влияния, – говорит Ольга. – То, что вы один тестировщик на проекте не означает, что можно забить на документацию (никому же кроме вас она типа не надо) и просто заводить багульки в Jira».
Она советует сделать все, что поможет вам тестировать быстрее и лучше, проводить регрессию или ввести автоматизацию:
- Написать чек-листы, если тест-кейсы кажутся избыточными или небольшими.
- Сделать документацию к API.
- Нарисовать таблицу с описанием зависимостей.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: