Види документації у роботі тестувальника (QA)

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

Вимоги (Software requirements specification) – це документ основа основ, того що буде реалізовано. У загальному вимоги описують перелік побажань замовника, і те що повинен робити продукт.

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

Технічна документація – зазвичай містить повний опис логіки конкретної частини продукту, що розробляється і варіанти, сценарії використання предмета розробки користувачами.

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

  • 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 повідомляє автоматично про результати всіх, кому важливо про них знати. Наприклад, для співробітників відділу підтримки повідомляється про вихід нової версії програми, що розробляється, а розробників про найкритичніші проблеми тощо.

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

Курси та події

Публікації

Відео