Види тестової документації

Тестове постачання (test deliverable): Будь-який тестовий (робочий) продукт, який має бути доставлений комусь іншому, крім автора тестового (робочого) продукту. (ISTQB)

Тестове забезпечення (testware): Артефакти, що створюються під час процесу тестування та потрібні для планування, розробки та виконання тестів. Наприклад: документація, сценарії, входи, очікувані результати, процедури встановлення та видалення, файли, бази даних, оточення та будь-яке інше додаткове програмне забезпечення або інструменти, що використовуються у тестуванні. (Fewster and Graham)

Артефакт (artifact) - це один із багатьох видів матеріальних побічних продуктів, що виникають у процесі STLC. Це не лише документація, а в принципі все, що створюється для того, щоб бути задіяним у тестуванні.

Результати тестування (Test Deliverables) – це артефакти, що передаються зацікавленим сторонам проекту програмного забезпечення протягом життєвого циклу розробки програмного забезпечення. На кожному етапі життєвого циклу розробки програмного забезпечення є різні результати тестування. Деякі результати тестування надаються до етапу тестування, деякі – на етапі тестування, а деякі – після завершення циклів тестування.

Наявність або відсутність документації, її актуальність, як і види, що використовуються, варіюються від компанії до компанії і навіть від проекту до проекту. Створення та ведення документації вимагає вагомої кількості часу (і компетенцій), а тому важливо знати основні документи та їх роль у процесах, враховувати вимоги всіх зацікавлених осіб, нормативну та законодавчу базу, політику та стандарти компанії та особливості проекту, щоб розуміти, які з них необхідні (і обґрунтовані для бізнесу) у кожному випадку. Існує безліч варіантів документів, частина з яких ви можете ніколи і не зустріти в реальній роботі.

За Куликова документацію можна розділити на два великі види залежно від часу та місця її використання:

Продуктна документація (product documentation, development documentation) використовується проектною командою під час розробки та підтримки продукту. Вона включає:
- План проекту (project management plan) і навіть тестовий план (test plan);
- Вимоги до програмного продукту (product requirements document, PRD) та функціональні специфікації (functional specifications document, FSD; software requirements specification, SRS);
- Архітектуру та дизайн (architecture and design);
- Тест-кейси та набори тест-кейсів (test cases, test suites);
- Технічні специфікації (technical specifications), такі як схеми баз даних, описи алгоритмів, інтерфейсів тощо;
Проектна документація (project documentation) включає як продуктну документацію, і деякі додаткові види документації і використовується як на стадії розробки, а й більш ранніх і пізніх стадіях (наприклад, на стадії впровадження й експлуатації). Вона включає:
- Користувальницьку та супровідну документацію (user and accompanying documentation), таку як вбудована допомога, посібник зі встановлення та використання, ліцензійні угоди тощо;
- Маркетингову документацію (market requirements document, MRD), яку представники розробника чи замовника використовують як у початкових етапах (для уточнення суті та концепції проекту), і на фінальних етапах розвитку проекту (для просування продукту над ринком).

Можна й інші класифікації.

Внутрішня документація докладно описує процес розробки продукту, наприклад стандарти, проектну документацію, нотатки про ділове листування тощо. буд.
До зовнішньої документації можна віднести Test policy, Test strategy, різні звіти, Defect Report, Зауваження, Запит на зміну (покращення), до внутрішньої все від чекліста до плану тестування, тестові дані тощо. Документація користувача (User documentation) - це вся документація, яка буде передана кінцевому користувачеві в комплекті з ПЗ.

Види документації :

Політика якості (Quality policy): відображає бачення компанії щодо виробництва та постачання якісного продукту;
Політика тестування (Test policy): документ високого рівня, в якому описані принципи, методи та всі важливі цілі тестування в організації;
Стратегія тестування (Test strategy): статичний документ документ високого рівня (high-level), який зазвичай розробляє менеджер проекту (project manager). Це документ, який відображає підхід до тестування продукту та досягнення цілей. Зазвичай він виводиться зі Специфікації бізнес-вимог (BRS – Business Requirement Specification). За підсумками стратегії тестування готується План тестування;
План тестування (Test plan): документ, що містить план усіх дій з тестування, які необхідно виконати для отримання якісного продукту. План тестування є похідним від опису продукту (Product Description), SRS (Software requirements specification) або сценаріїв використання (Use Case) для всіх майбутніх дій проекту. Зазвичай його готує керівник тестування або менеджер із тестування (Test Lead or Test Manager);
Звіт про оцінку зусиль (Effort Estimation Report): у цьому звіті групи тестування оцінюють зусилля для завершення процесу тестування;
Сценарій тестування (Test Scenario): елемент або подія програмної системи, яка може бути перевірена одним або декількома тестовими випадками;
Тестовий набір/комплект (Test Suite): "Комплект тестових наборів для досліджуваного компонента або системи, в якому постумова одного тесту зазвичай використовується як передумова для наступного." (ISTQB) . Деякий набір формалізованих Test case, об'єднаних між собою за загальною логічною ознакою;
Тестовий випадок/приклад (Test case): набір позитивних та негативних виконуваних кроків тестового сценарію, який має набір попередніх умов, тестових даних, очікуваного результату, постумов і фактичних результатів;
Тест сурвей (Test Survey) : у рунеті лише про нього, але є згадки в історії чатів ком'юніті. Test Survey по деталізації займає місце посередині між чек-листом і тест-кейсом, а саме містить у собі тільки summary та expected result. Тобто. докладніше чек-листів, де тільки заголовки, але з очікуваним результатом і без кроків та іншого як у тест-кейсах;
Чек-лист (Check List): перелік формалізованих Test case у спрощеному вигляді зручному для проведення перевірок, часто лише список із заголовків кейсів;
Матриця простежуваності вимог (Requirements Traceability Matrix): документ, який співвідносить вимоги до тестових прикладів;
Тестові дані (Test Data): “_дані, які існують (наприклад, у базі даних) на початок _
виконання тесту і впливають на роботу, або ж зазнають впливу з боку системи або компонента, що тестується.” (ISTQB). "Створені або відібрані дані, що задовольняють вхідним вимогам для виконання одного або більше контрольних прикладів, які можуть бути визначені у плані тестування, контрольному прикладі або процедурі тестування." (ГОСТ 56920)
Звіт про дефекти (Defect Report): мета документа полягає в тому, щоб зафіксувати факт помилки та передати розробникам докладну інформацію про неї;
Звіт про виконання тесту (Test Execution Report): містить результати тестування та зведення дій щодо виконання тестів;
Зведений звіт про тестування (Test summary report): є документом високого рівня, в якому резюмуються проведені дії з тестування, а також результати тестування;
Графіки та метрики (Graphs and Metrics): призначені для моніторингу та управління процесом та продуктом. Це допомагає без відхилень вести проект до намічених цілей. Метрики відповідають різні питання. Важливо вирішити, які питання ви хочете отримати відповіді;
Звіт про тестові інциденти (Test incident report): містить усі інциденти, дозволені або невирішені, виявлені під час тестування;
Звіт про завершення тестування (Test closure report): містить докладний аналіз виявлених помилок, віддалених помилок та невідповідностей, виявлених у програмному забезпеченні;
Звіт про статус тестування (Test status report): призначений для відстеження статусу тестування. Його готують періодично чи щотижня. У ньому зазначені роботи, виконані до теперішнього часу, та роботи, які ще не завершені;
Щотижневий звіт про статус (менеджер проекту для клієнта): Weekly status report подібний до звіту про статус тестування, але генерується щотижня;
Звіт про покращення (?Enhancement report): опис неявних/некритичних непрямих вимог, які були враховані під час планування/реалізації продукту, але недотримання, яких може викликати неприйняття в кінцевого споживача;
Запит на модифікацію (Modification Request): запит клієнта зміну існуючої функціональності;
Примітки до випуску : Примітки до випуску будуть надіслані клієнту, замовнику або заінтересованим сторонам разом із збіркою. Він містить перелік нових випусків, виправлення помилок;
Посібник зі встановлення / налаштування (Installation/configuration guide): цей посібник допомагає встановити або налаштувати компоненти, з яких складається система, та її апаратні та програмні вимоги;
Посібник користувача (User guide): цей посібник допомагає кінцевому користувачеві зрозуміти, як користуватися продуктом;
Різні документи вимог .

Джерело:

Дод. матеріал:

PreviousТестова документація та артефакти (Test Deliverables/test artifacts)NextПолітика якості та політика тестування (Quality policy and Test policy)

Last updated 2 years ago