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

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

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

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

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

Що робити?

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

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

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

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

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