Існують різні види документів, які використовують тестувальники при тестуванні. Кожен із яких відіграє свою важливу роль при створенні успішного продукту. А використовують тестувальники у роботі не лише свою тестову документацію.

Найпоширеніші SoftWare Testing документи:

    Вимоги (Software requirements specification) — це документ основа основ, того що буде реалізовано. У загальному вимоги описують перелік побажань замовника, і того що повинен продукт робити. Частково служить ще для отримання зворотнього зв’язку від стекхолдерів. Обіцяємо, що у майбутньому ми «копнемо» цієї теми глибше.

   Технічне завдання (ТЗ) — дозволяє донести суть того що слід створити команді. Допомагає зрозуміти, яким саме функціоналом повинен володіти продукт, іноді із зазначенням використовуваних технологій і методами його реалізації. Технічне Завдання допомагає зрозуміти програму краще. У свою чергу нерозуміння призводить до помилок у реалізації продукту чи помилковій публічній інтерпретації програмного продукту аудиторії. 

    Технічне Завдання повинно бути в загальному доступі, щоби усі співробітники, змогли його подивитися. У цьому плані Технічне Завдання вигідне, оскільки нових співробітників легко буде ввести в курс діла. Наприклад, якщо тестувальник виявить які баги чи проблеми — він одразу зможе про це повідомити. Новачки тестери не будуть мати спокуси перевіряти усе, що треба і не треба. Бо в першу чергу, перевірці піддасться те, що обов’язково повинно працювати по ТЗ. Плюс Технічне Завдання дає можливість приблизно оцінити витрати ресурсів на розробку і тестування ще до початку робіт.

    Технічна документація  — зазвичай містить повний опис логіки конкретної частини продукту, що розробляється і варіанти, сценарії використання предмета розробки користувачами. Документація цього виду теж як і ТЗ добре джерело знань, коли допомагає новим співробітникам розібратися в великих і масштабних проектах. Бувають системи де потрібні тижні на вивчення. Маючи під рукою технічну документацію, співробітник з легкістю зможе знайти в ньому необхідну інформацію, відразу приступивши до тестування. Технічна Документація є частиною вихідного коду. Хочеш дізнатися про це більше? Читай ТУТ. А якщо бажаєш дізнатися про ін. SoftWare Documentationтоді гайда до Вікіпедії.

Проектна документація, яку готують тестувальники:

    Логічно Тестова документація повинна документувати все, що повинно бути зроблено ДО або ПІД ЧАС самого процесу тестування програмного забезпечення. Документація для тестування програмного забезпечення допомагає оцінити потребу тестування, проконтролювати тестове покриття.

Таку собі… творчість по опису тестових випадків найчастіше систематизують:

  • Test Plan
  • Check List
  • Test Scenario
  • Test Case
  • Traceability Matrix
  • Bug Report

    Тестовий План — це документ, який описує увесь об’єм робіт пов’язаних із  тестуванням. Описує стратегію, котра буде застовуватися для тестування програми, ресурсів, що будуть використовуватися, тестове середовище, в якому буде проводитися тестування, а також обмежень тестування та графіку тестування. Тест-план є важливою складовою будь-якого грамотно-організованого процесу тестування, так як містить у собі всю необхідну інформацію процесу тестування. Як правило, за написання Тест-плану, розробку Тест-дизайну відповідальний керівник групи з питань Забезпечення Якості або досвідчений Senior qa engineer.

    План Тестування повинен включати в себе наступне: вступ, обгрунтування необхідності тестування, Check List, перелік функціоналу, який тестуватиметься, зазначення підходу, який використовуватиметься під час тестування ПЗ, перелік результатів, які необхідно перевірити, включення ризиків пов’язаних із тестуванням, графік виконання завдань та етапів.

    Check List — це частина Test Plan, конкретний список того, що потрібно перевірити. Від допомагає планувати терміни закінчення робіт у майбутньому й сьогоденні. У ньому можна відмічати скільки часу необхідно для перевірки і скільки було витрачено. Відображає ступінь готовності продукту. Check List із результатами наочно показує у будь-якого співробітника компанії поточний стан продукту, що розробляється. Зберігає історію раніше проведених тестів. Не дає забути, які тести необхідно виконати в першу чергу, які в другу, які в третю і т. д. Це породжує впевненість, що за певний запланований час найважливіші тести будуть проведені, а результати по ним — отримані. Також можна буде легко звірити, які саме тести проходили з помилками, і перепровірити їх ще раз, лише їх наприклад. Чек-лісти варіан записати у Google Sheets, але як по мені значно наглядніше і зручніше у вигляді інтелектуальної карти. Відмінний інструмент XMind

Чек-ліст у інтелектуальній карті

    Тестовий Сценарій повідомляє про те, яку ділянку і у якому порядку в програмі буде перевірено. Тестові сценарії використовуються щоби ефективно протестувати все передбачене покриттям. Залежно від величини та складності програми тестових сценаріїв може бути від одного до кількох сотень сценаріїв. Терміни “тестовий сценарій” та “тестові випадки” використовуються інколи взаємозамінно, проте тестовий сценарій має кілька етапів, тоді як тестовий випадок має один крок. З цієї точки зору, тестові сценарії є тестовими випадками, але вони містять кілька тестів і послідовність їх виконання. Окрім цього, кожен тест залежить від результатів попереднього тесту.

Схема Тестового Сценарію

   Тестові Випадки — включають набір кроків, передумов та вхідних умов, які можуть бути використані під час виконання тестових тасків. Головною умовою є забезпечення працездатності програми з точки зору її функціональності та інших аспектів. Існує багато типів тестових випадків, таких як функціональні, негативні, баги, логічні тестові випадки, логічні помилки, випадки від фізичних тестів на навантаження чи проникнення до системи, випадки тестування UX/UI інтерфейсу користувача тощо. Крім того, існують тестові випадки для відстеження тестового покриття програмного забезпечення. Як правило, немає офіційних шаблонів, котрі можуть бути використані під час написання тестового випадку.

Проте наступні компоненти радимо завжди включати у перевірку кожного тестового випадку:

  • ідентифікатор тестового випадку аби потім не потонути у морі невизначених випадків; 
  • модуль продукту;
  • версія продукту;
  • історія редакції;
  • що викликало припущення перевірити саме цей тестовий випадок;
  • передумови перевірки; 
  • виконання кроку; 
  • очікуваний результат;  
  • фактичний результат;  
  • пост-умови.

    Багато тестів може бути розроблено з одного сценарію тестування. Крім того, іноді існує декілька різних тестів для перевірки одного й того самого моменту програмного забезпечення, які спільно називаються Тестовими Об’єктами.

      Тест-кейси зручно відображати у вигляді таблиці. Популярні спеціалізовані інструменти для ведення тест-кейсів: Zephyr, Jira (з інтегрованими інструментами), Redmine, Meliora, TestRail, Confluence, TFS та багато інших Test management system tools.

     Матриця відповідності вимог, також відома як Matrix Traceability Maturity (RTM) — це таблиця, яка використовується для відстеження вимог під час життєвого циклу розробки програмного забезпечення. Вона може використовуватися для прямого відстеження (тобто від вимог до дизайну або кодування) або навпаки (тобто від кодування до вимог). Існує багато користувацьких шаблонів для RTM.

MatrixЗображення Traceability Maturity (RTM)

    Кожна вимога в документі RTM пов’язана з відповідним Тестовим Випадком, тому виконання тестування відповідає до зазначених вимог. Окрім того, ідентифікатор помилки також включений і пов’язаний з відповідною вимогою та Тестовим Сценарієм та випадком. Основні цілі створення цієї матриці є: переконатися, що програма розроблена відповідно до зазначених вимог; допомогти знайти причину будь-якої помилки, як то кажуть звідки ноги ростуть? гарний помічник який підказує які документи слід відстежувати на різних етапах циклу розробки програмного забезпечення.

    Звіт про результати тестування — це письмовий або медійний звіт про виконану роботу і її результати. Історично фіксує інформацію. До неї завжди можна буде повернутися і побачити, що саме було виконано і що саме отримали у результаті. Якщо це не окремий документ, то ним виступає Bug Report.

    Для формування Bug Report можна використовувати ті самі Jira, Redmine, Mantis, що застосовували для тест-кейсів. Вони зручні.

       Bug Tracking System повідомляє автоматично про результати всіх, кому важливо про них знати. Наприклад, для співробітників відділу підтримки повідомляється про вихід нової версії програми, що розробляється, а розробників про найкритичніші проблеми тощо. 

       Звіт про тестування допомагає приймати важливі рішення про подальші дії (Наприклад, чи варто випускати версію програми в поточному стані?).

Mantis Bug Treker
Ось так виглядає Мантіс Баг Трекер

Підсумок:

    Якщо у Вашій голові зробилася КАША від значного переліку  нічого страшного, мета даної статті лише дати загальне уявлення про те що існує у світі тестової документації, а якщо Вас зацікавив конкретний вид документу чи яка деталь, думаю із Googlе Ви справитеся 🙂

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.