«Сісти і плакати – не наш шлях»: що робити, якщо на IT-проєкті немає документації

Документація — “чарівна паличка” для фахівця, яка дає уявлення про роботу програмного забезпечення: містить інструкції, примітки, діаграми, включаючи матеріали вихідного коду та навчальні матеріали, інформацію про архітектуру проєкту, тестування тощо.

Та що робити, якщо приходиш в “нову динамічну розвиваючуся компанію”, а там документації приблизно нуль? Це питання розкрила досвідчена QA Engineer Ольга Маркова у своєму LinkedIn.

«У теорії на проєктах, куди приходиш працювати, є бізнесаналітик, гарно розписана документація по проєкту у Confluence, тестова документація у TestRail, вам надають доступи до усього необхідного. Працюй і радій. А ось на практиці так буває не завжди», – стверджує фахівчиня.

З її досвіду, трапляються проєкт, яким рік-два чи більше, і весь цей час вони працювали без QA. Тож тут немає не те що тестової документації, а взагалі жодної.

Що робити?

«Сісти і плакати – не наш шлях», – каже тестувальниця та пропонує кілька варіантів виходу з ситуації:

1. Дізнатися, що взагалі є. Все одно десь можуть «валятися» якісь вимоги, схеми, документація до АРІ чи колекції Postman… Розпитайте колег, що є, і просіть вам дати це.
2. Вивчити інструкції для користувачів. На багатьох проєктах вони все-таки є, і це вже хороша відправна точка – звідти можна вибрати деякі вимоги (наприклад, до розмірів зображень) і загалом зрозуміти, як працює продукт, розібратися в основному функціоналі.
3. Поговорити з СТО, старшим розробником, кимось зі «старожилів» на проєкті чи клієнтом – розпитати про продукт, яка його ідея, як компанія «робить гроші», чому ось цей функціонал працює саме так, а не інакше.
4. Попросити доступи до GitHub та бази даних, якщо можливо. Можна подивитись коміти і побачити, що робилося на проєкті останнім часом. Якщо вмієш читати код, то взагалі прекрасно.
5. Попросити доступи до Google Analytics. Тут можна побачити, під які пристрої, ОС та браузери треба тестувати, скільки користувачів є, з яких країн, якого вони віку, які сторінки найпопулярніші, з яких користувачі виходять, звідки йде трафік.
6. Провести дослідницьке тестування.
7. Не соромитись розпитувати у колег все, що не зрозуміло або викликає сумніви. Краще перепитати, ніж робити купу нікому не потрібної роботи.

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

Вона радить зробити все, що допоможе вам потім тестувати швидше та краще, проводити регресію чи запровадити автоматизацію:

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