Кожен тестувальник регулярно використовує тестову документацію, завдяки ній тестувальник спілкується з розробниками, завдяки ній тестувальник знає що і коли робити.
Тестова документація є важливим аспектом процесу тестування програмного забезпечення, оскільки вона допомагає забезпечити якість і надійність програмного продукту. Тестову документацію можна розділити на два основні рівні:
Високорівнева документація - яка описує сам процес тестування
Низькорівнева документація - описує процеси тестування на більш локальному рівні
Високорівнева документація
Тестова документація високого рівня містить огляд підходу до тестування, обсягу та цілей. Він призначений для зацікавлених сторін, керівників проєктів та інших нетехнічних членів команди, яким потрібне широке розуміння процесу тестування. Деякі звичайні тестові документи високого рівня включають:
Тестова стратегія
Тест план
Звіт про тестування
Тестові показники та KPI
Почнемо розглядати кожен з цих пунктів окремо:
Тестова стратегія
Стратегія тестування — це документ високого рівня, який описує загальний підхід і цілі тестування програмного продукту чи системи. Він служить дорожньою картою для команди тестування, надаючи чіткі вказівки щодо того, як тестування проводитиметься протягом життєвого циклу проекту. Стратегія тестування зазвичай створюється на ранніх стадіях проєкту та може бути переглянута або оновлена в ході проєкту. Структура тестової стратегії може відрізнятися проєкт від проєкту, надалі зазначена структура, від якої всі відштовхуються:
Вступ:
Стратегія тестування починається зі вступу, який містить огляд мети документа та програмного продукту, що тестується. Він також може містити інформацію про зацікавлених сторін, команду тестування та інші відповідні деталі проекту.
Сфера застосування та цілі:
У цьому розділі визначено масштаби тестування, указуючи, що буде перевірятися, а що – ні. Він повинен чітко окреслювати межі процесу тестування. Крім того, вказуються цілі тестування, такі як забезпечення відповідності програмного забезпечення заданим вимогам, виявлення дефектів і перевірка функціональності системи.
Підхід до тестування:
Підхід до тестування описує загальну стратегію та методології, які будуть використовуватися під час тестування. Він може містити деталі про різні типи тестування, які необхідно виконати, наприклад, функціональне тестування, інтеграційне тестування, тестування продуктивності, тестування безпеки тощо. Документ має пояснювати обґрунтування вибраних методів тестування.
Результати тесту:
У цьому розділі перераховано різні результати тестування, які будуть створені під час процесу тестування. Приклади результатів тестування включають плани тестування, тестові випадки, тестові дані, тестові журнали, звіти про дефекти та підсумковий звіт про тестування.
Тестове середовище:
Стратегія тестування визначає необхідні тестові середовища, включаючи обладнання, програмне забезпечення, мережеві конфігурації та будь-які інші залежності, необхідні для тестування. Тут визначаються, які тестові середовища будуть налаштовані та підтримувані протягом усього проєкту.
Аналіз ризиків:
Аналіз ризиків визначає потенційні ризики, які можуть вплинути на процес тестування та проєкт у цілому. У ньому описано, як ці ризики будуть пом’якшені або керовані, щоб мінімізувати їхній вплив на успіх проєкту.
Ролі та обов'язки:
У цьому розділі роз’яснюються ролі та обов’язки членів команди, які беруть участь у тестуванні, зокрема тестувальників, лідів, менеджерів та інших зацікавлених сторін. Це гарантує, що кожен розуміє свої обов’язки та вносить ефективний внесок у тестування.
Інструменти тестування та інфраструктура:
У Стратегії тестування можуть бути перераховані інструменти та технології тестування, які використовуватимуться для підтримки процесу тестування, наприклад інструменти керування тестуванням, інфраструктури автоматизації та інструменти тестування продуктивності.
Тест план
Тест план — це комплексний документ, у якому детально описано підхід, обсяг, ресурси та графік тестування програмного продукту чи системи. Добре підготовлений план тестування гарантує, що тестування є систематичним, ретельним і відповідає цілям проекту. Ось основні компоненти, які зазвичай входять до плану тестування:
Вступ:
План тестування починається зі вступу, який містить огляд мети документа, програмного продукту, що тестується, і цілей тестування. Він також може містити посилання на інші пов’язані документи та зацікавлені сторони, залучені до тестування.
Обсяг тесту:
У цьому розділі визначається обсяг тестування, вказується, які функції та функції програмного забезпечення перевірятимуться, а які – ні. У ньому також описано різні типи тестування (наприклад, функціональне тестування, тестування продуктивності, тестування безпеки), які будуть проводитися.
Цілі тесту:
Цілі тестування — це конкретні, вимірювані цілі, на досягнення яких спрямоване тестування. Вони узгоджуються із загальними цілями проекту та можуть включати такі аспекти, як пошук дефектів, забезпечення відповідності вимогам, покращення якості програмного забезпечення та перевірка взаємодії з користувачем.
Тестовий підхід і методологія:
План тестування описує загальний підхід і методологію, які будуть використовуватися для проведення тестування. У ньому пояснюються вибрані методи тестування, інструменти та фреймворки, а також будь-які галузеві стандарти чи найкращі практики, яких слід дотримуватися.
Результати тесту:
У цьому розділі перераховано різні результати тестування, які будуть створені під час процесу тестування. Він містить тестові приклади, тестові сценарії (для автоматизованого тестування), тестові дані, журнали тестування, звіти про дефекти та підсумковий звіт про тестування.
Тестове середовище:
План тестування визначає необхідні тестові середовища, включаючи апаратне забезпечення, програмне забезпечення, мережеві конфігурації та інші залежності, необхідні для тестування. У ньому має бути описано, як тестові середовища будуть налаштовані та підтримувані протягом усього проекту.
Розклад і графік тестування:
План тестування містить детальний графік проведення тестування із зазначенням часу початку тестування, основних етапів і орієнтовної дати завершення. Це допомагає в управлінні зусиллями з тестування та координації з іншими видами діяльності проекту.
Критерії входу та виходу:
Критерії входу та виходу – це умови, які повинні бути виконані перед тим, як тестування може розпочатися (вхід) або перед тим, як тестування можна вважати завершеним (вихід). Наприклад, критерії входу можуть включати завершення певних фаз розробки, тоді як критерії виходу можуть вимагати певного рівня охоплення тестами та усунення дефектів.
Тестові ресурси:
У цьому розділі визначено ресурси, необхідні для тестування, зокрема членів команди тестування, їхні ролі та обов’язки, а також будь-які необхідні зовнішні ресурси чи інструменти.
Ризики тестування та пом'якшення:
Аналіз ризиків визначає потенційні ризики, які можуть вплинути на процес тестування та проект у цілому. План випробувань повинен окреслити, як ці ризики будуть пом’якшені або керовані, щоб мінімізувати їхній вплив на успіх проекту.
Тестові показники та звітність:
План тестування визначає показники та ключові показники ефективності (KPI), які використовуватимуться для вимірювання прогресу тестування, якості та ефективності тестування. У ньому також описано механізми звітування та частоту оновлення статусу.
Тест Sign-off:
План тестування має визначати критерії та процес отримання підпису на тестування, яке є офіційним схваленням, яке вказує на те, що тестування завершено та програмне забезпечення готове до випуску.
Різниця між Тест планом і Тест Стратегією
Переглянувши перший раз вміст цих двох документів, я не міг зрозуміти чому вони різні, якщо мають багато чого спільного, насправді як виявилося я не один так думав, тому на багатьох проєктах можна зустріти тест стратегію яку запхали в тест план, ото ж яка різниця в цих документах?
Критерій | Тест план | Тестова стратегія |
|---|---|---|
Призначення | План тестування — це детальний документ, який містить вичерпну та структуровану схему того, як тестування проводитиметься протягом життєвого циклу проекту. У ньому вказуються завдання, ресурси та графік проведення тестування. | Стратегія тестування — це документ високого рівня, який містить огляд загального підходу та цілей тестування програмного продукту чи системи. Він описує широкий підхід до тестування та закладає основу для тестування. |
Область застосування | План тестування детально описує обсяг тестування, визначений у Стратегії тестування, надаючи більш конкретні відомості про те, які функції та функціональні можливості перевірятимуться, а також які не тестуватимуться. | Стратегія тестування визначає обсяг тестування, який включає типи тестування, які необхідно виконати, наприклад функціональне тестування, тестування продуктивності, тестування безпеки тощо. |
Аудиторія | План тестування в основному призначений для тестувальників, лідів і членів технічної команди, яким потрібне детальне розуміння завдань і заходів тестування. | Стратегія тестування в першу чергу призначена для зацікавлених сторін, керівників проєктів та інших нетехнічних членів команди, яким потрібне загальне розуміння процесу тестування. |
Зміст | План тестування містить інформацію про цілі тестування, розклад тестування, критерії входу та виходу, результати тестування, тестове середовище, тестові дані, тестові показники, звітність і критерії завершення тестування. | Стратегія тестування містить інформацію про підхід до тестування, методології тестування, аналіз ризиків, тестове середовище, інструменти тестування, а також ролі та обов’язки команди тестування. |
Час | План тестування зазвичай створюється після того, як стратегія тестування була створена та затверджена. Це живий документ, який постійно оновлюється протягом усього проєкту в міру проходження тестування. | Стратегія тестування зазвичай створюється на ранніх стадіях проекту та може бути переглянута або оновлена в ході проекту. |
Отож порівнявши цих два документи одразу стає очевидна між ними різниця. Багато хто нехтує створенням тест стратегій.
Звіт про тестування
Підсумковий звіт про тестування — це вичерпний документ, який містить огляд діяльності з тестування, результатів і основних результатів тестування програмного забезпечення. Він служить остаточним записом процесу тестування та генерується в кінці фази тестування або проекту. Підсумковий звіт про тестування є важливим інструментом комунікації, який допомагає зацікавленим сторонам, керівникам проектів та іншим членам команди зрозуміти результати тестування та прийняти обґрунтовані рішення щодо готовності програмного забезпечення до випуску.
Зазвичай в дійсності це більш формальний документ, який показує наступне: що було покрито тестами, де були знайдені дефекти, що стало з дефектами, і зазвичай оформлюють таке в ексель таблицях, проте правильно написаний звіт це теж досить великий документ і має наступні ключові компоненти, які зазвичай включають у підсумковий звіт про тестування:
Вступ:
Підсумковий звіт про тестування починається зі вступу, який містить огляд мети документа, цілей тестування та масштабів тестування. Він також може містити посилання на інші пов’язані документи та членів команди, які брали участь у тестуванні.
Тестування діяльності:
У цьому розділі описано різні дії з тестування, які виконуються на етапі тестування. Він може містити відомості про функціональне тестування, тестування інтеграції, тестування продуктивності, тестування безпеки та будь-які інші специфічні типи тестування.
Тестове покриття:
Підсумковий звіт про тестування надає короткий виклад охоплення тестуванням, досягнутого під час процесу тестування. У ньому пояснюється, які функції, функціональні можливості чи області програмного забезпечення було протестовано, а які не тестувалося, а також аргументація будь-яких упущень.
Результати тесту:
У цьому розділі представлено результати тестування, включаючи кількість виконаних, пройдених, невдалих і відкладених тестів. Він також надає докладні відомості про будь-які невирішені дефекти та рівні серйозності та пріоритетності виявлених проблем.
Короткий опис дефектів:
Підсумковий звіт про випробування включає зведення про дефекти, яке містить огляд типів і кількості дефектів, виявлених під час тестування. Він може класифікувати дефекти на основі їх серйозності (наприклад, критичні, серйозні, незначні) і включати статистичні дані про щільність дефектів або рівень виявлення дефектів.
Показники тесту:
Цей розділ містить ключові показники ефективності (KPI) і показники, які використовуються для вимірювання ефективності процесу тестування. Загальні показники тесту можуть включати швидкість проходження тесту, покриття тесту, щільність дефектів і тривалість виконання тесту.
Тестові виклики та пом'якшення:
У підсумковому звіті про тестування висвітлюються будь-які труднощі чи перешкоди, які виникли під час тестування, і пояснюється, як їх було усунено чи пом’якшено. У цьому розділі міститься уявлення про процес тестування та заходи, вжиті для подолання труднощів.
Рекомендації:
На основі результатів тестування та спостережень підсумковий звіт про тестування може містити рекомендації щодо майбутніх зусиль тестування або вдосконалення процесу розробки. Ці рекомендації можуть допомогти підвищити якість програмного забезпечення в майбутніх випусках.
Висновок і підписання:
Висновок підсумовує загальний опис процесу тестування та результатів. Він також може включати офіційний розділ підписання, де команда тестування вказує на своє схвалення або готовність до випуску програмного забезпечення.
Додатки:
Підсумковий звіт про випробування може включати допоміжну інформацію, таку як докладні звіти про дефекти, журнали випробувань, дані випробувань та іншу відповідну документацію.
Тестові показники так KPI
Показники тестування та ключові показники ефективності (KPI) — це кількісні показники, які використовуються для оцінки прогресу, якості та ефективності процесу тестування програмного забезпечення. Вони надають цінну інформацію про тестування та допомагають визначити області, які потребують покращення. Нижче наведено коротке пояснення тестових показників і KPI:
Показники тесту:
Показники тестування — це кількісні вимірювання, які використовуються для відстеження різних аспектів процесу тестування та якості тестованого програмного забезпечення. Ці показники зазвичай збираються та аналізуються протягом життєвого циклу тестування. Приклади тестових показників включають:
Тестове покриття: відсоток програмного коду або вимог, охоплених тестовими прикладами.
Щільність дефектів: кількість дефектів, виявлених на одиницю коду або вимог.
Зусилля виконання тесту: загальні зусилля, витрачені на виконання всіх тестів.
Показник проходження тесту: відсоток успішно пройдених тестів.
Покриття автоматизації тестування: відсоток автоматизованих тестів порівняно із загальною кількістю тестів.
Час циклу тестування: час, витрачений на завершення циклу тестування від початку до кінця.
Ключові показники ефективності (KPI):
Ключові показники ефективності (KPI) — це конкретні показники, які особливо важливі для оцінки успішності та ефективності процесу тестування. Ці показники допомагають зацікавленим сторонам швидко оцінити загальний стан і ефективність тестування. Приклади тестування KPI включають:
Показник відхилення дефектів: відсоток повідомлених дефектів, відхилених після оцінки.
Час обробки дефектів: час, витрачений на усунення дефектів з моменту повідомлення про них до моменту їх усунення та повторного тестування.
Ефективність тестових випадків: здатність тестових випадків виявляти дефекти або адекватно перевіряти функціональність.
Продуктивність тестування: кількість тестів, виконаних одним тестувальником або командою тестувальників за певний період.
Дефекти, які не вдалося перевірити: кількість дефектів, виявлених кінцевими користувачами або клієнтами після випуску програмного забезпечення.
Ефективність тестування: відношення пройдених тестів до загальної кількості виконаних тестів.
Низькорівнева документація
Тестова документація низького рівня заглиблюється в специфіку тестових випадків, процедур тестування та фактичного процесу тестування. Вона призначена для тестувальників і членів технічної команди, яким потрібні детальні інструкції щодо виконання тестів.
До низькорівневої документації можна віднести:
Тестові випадки
Тестові набори
Тестові дані
Баг репорти
Тестові логи
Тестові випадки (test case)
Тестові випадки є фундаментальним компонентом тестування програмного забезпечення. Це детальні описи конкретних сценаріїв або умов, які необхідно виконати, щоб перевірити, чи програмне забезпечення поводиться так, як очікувалося. Тестові приклади служать набором інструкцій для тестувальників під час процесу тестування та допомагають забезпечити повне охоплення функціональних можливостей програмного забезпечення.
Тестові випадки призначені для перевірки різних аспектів програмного забезпечення, наприклад, чи відповідає воно заданим вимогам, чи правильно працює, чи правильно обробляє помилки та чи працює ефективно. Основна мета тестових прикладів — виявити дефекти або відхилення від очікуваної поведінки.
Типовий тестовий випадок включає наступні компоненти:
Ідентифікатор тесту: унікальний ідентифікатор для кожного тестового випадку, що полегшує посилання та відстеження.
Назва/опис тестового випадку: чітка та лаконічна назва або опис, який пояснює, що тест має перевірити.
Попередні умови: будь-які необхідні умови або налаштування, необхідні перед виконанням тесту, наприклад певні дані або стани системи.
Етапи тестування: серія покрокових інструкцій для виконання тестового сценарію. Кожен крок має бути однозначним і легким для виконання.
Очікувані результати: очікуваний результат або поведінка, які слід спостерігати після виконання кожного кроку тестування. Ці результати базуються на очікуваній реакції системи.
Фактичні результати: фактичний результат, який спостерігається під час виконання тесту. Тестувальники документують результати під час виконання тест (Цей пункт використовується ВИКЛЮЧНО при проходженні тесту, при створені тестового випадку цей пункт ігнорується).
Статус «Пройшов/Не пройшов»: вказує на те, чи тест пройдено (фактичні результати збігаються з очікуваними) чи не пройдено (фактичні результати відрізняються від очікуваних) (Той ж коментар що і до попереднього пункту).
Управління тестовими випадками:
Тестовими випадками зазвичай керують за допомогою інструментів керування тестуванням або електронних таблиць (xRay, zephyr, Test Rail, Excel). Ці інструменти дозволяють тестувальникам ефективно організовувати, відстежувати та визначати пріоритети тестових випадків. Управління тестовими випадками гарантує, що всі необхідні тестові випадки ідентифікуються, виконуються та записуються під час процесу тестування.
Боже прости за ексель… (не треба його використовувати, будь ласка)
Ітеративний характер:
Тестові приклади можуть проходити ітерації та оновлення протягом життєвого циклу розробки. У міру розвитку програмного забезпечення тестові приклади може знадобитися модифікувати або розширити для охоплення нових функцій або змін у вимогах.
Створення комплексних і добре структурованих тестових прикладів має вирішальне значення для ефективного тестування програмного забезпечення. Вони забезпечують системний підхід до перевірки поведінки програмного забезпечення та допомагають забезпечити доставку високоякісного та надійного продукту кінцевим користувачам.
Тестові набори
Тестові набори - це збірка тестових випадків, які посортовані відповідно за певними критеріями, наприклад за функціональністю.
Зазвичай тестові набори мають наступні атрибути:
Ідентифікатор набору
Назва/опис тестового набору
Попередні умови для тестових випадків в тестовому наборі
Тобто по факту це просто збірка тестів.
Не раз зустрічав ситуацію, коли тестовий набір називали “Тест Планом”. В перший час я не міг зрозуміти, що конкретно від мене хочуть, бо тест план має зовсім інше ж значення… І здається я знаю тепер чому один з перших клієнтів від мене пішов, коли я представив загальний вигляд тест плану…
Тестові дані
Документ із тестовими даними — це вичерпний запис, який містить усю необхідну інформацію про тестові дані, які можуть бути використані під час тестування програмного забезпечення. Документ служить довідником для тестувальників та інших зацікавлених сторін, залучених до процесу тестування. Документ із тестовими даними зазвичай містить такі деталі, як типи тестових даних, джерела даних, формати, зв’язки та будь-які відповідні міркування безпеки. Ця документація гарантує, що тестувальники мають доступ до потрібних тестових даних для конкретних сценаріїв тестування, що призводить до більш ефективних і точних результатів тестування.
Баг репорти
Один з найбільш розповсюджених видів тестової документації (бо багів буває багатенько). Звіт про помилку, також відомий як звіт про дефект або звіт про проблему — це документ, який містить детальний опис дефекту програмного забезпечення або проблеми, виявленої під час тестування або використання. Звіти про помилки мають важливе значення для ефективного відстеження помилок, спілкування та вирішення проблем у групі розробки чи тестування програмного забезпечення. Коли тестувальники стикаються з аномаліями або неочікуваною поведінкою під час тестування, вони документують проблеми у звіті про помилки, щоб повідомити розробників та інших зацікавлених сторін про проблему. Ось основні компоненти звіту про помилку:
Заголовок/Резюме: стислий і описовий заголовок, який підсумовує проблему.
Опис: докладний опис проблеми.
Кроки до відтворення: чіткі кроки які призвели до помилки.
Очікувана поведінка: чіткий опис про очікувану поведінку програмного забезпечення.
Фактична поведінка: опис того, що насправді сталося, коли виникла проблема.
Серйозність/пріоритет: вплив і терміновість помилки, зазвичай класифіковані як низька, середня, висока або критична, а також її пріоритет для виправлення.
Відтворюваність: інформація про те, наскільки послідовно можна відтворити проблему, наприклад «завжди», «з перервами» або «один раз».
Середовище: відомості про тестове середовище, включаючи операційну систему, браузер, апаратне забезпечення та версії програмного забезпечення, які використовувалися під час тестування.
Додатки: знімки екрана, файли журналів або будь-які інші допоміжні документи, які можуть допомогти зрозуміти або відтворити проблему.
Повідомив: ім’я або ідентифікатор особи, яка повідомила про помилку.
Дата/час: дата й час повідомлення про помилку.
Кому призначено: розробник або особа, відповідальна за дослідження та усунення помилки.
Звіти про помилки зазвичай створюються в системах відстеження помилок або відстеження проблем, які допомагають упорядковувати та визначати пріоритети для розробників. Звіт про помилку є важливим інструментом спілкування між тестувальниками та розробниками, який сприяє співпраці, необхідній для вирішення проблем і покращення якості програмного забезпечення до його випуску для кінцевих користувачів.
Є в цьому документі досить багато нюансів, які варто слідувати щоб тебе точно зрозуміли, до прикладу Заголовок баг репорту потрібно описувати по наступній структурі: що сталося? де сталося? коли сталося? Наприклад: Кнопка “Пуск” не відображається (що?) в головному меню (де?) після натискання на кнопку “Назад”.
Можливо про це буде окрема стаття…
Тест Логи
Тест Логи — це записи, які фіксують детальну інформацію про виконання тестів під час тестування програмного забезпечення. Вони надають хронологічний звіт про тестування, включаючи етапи тестування, результати, позначки часу, статус «пройшов/не пройшов» і деталі середовища. Журнали тестування допомагають відстежувати хід тестування, виявляти проблеми та полегшувати налагодження та звітування. Вони є цінними для відстеження, співпраці та прийняття рішень, забезпечуючи всебічне та ефективне тестування. Журнали тестування зберігаються в інструментах керування тестуванням або базах даних для легкого доступу та пошуку за потреби.
Висновок
Отож узагальнивши можна прийти до висновку що кожен вид документації потрібен в тому чи іншому варіанті, до прикладу тестові дані можуть бути поміщені в середині тестового випадку, тестова стратегія в середині тест плану, але все ж ця вся документація потрібна і саме правильне ведення документації показує інженерів тестування як тих що добре знаються на своїй справі.
