Як написати документацію з контролю якості, яка насправді буде працювати

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

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

Існує так багато видів тестування програмного забезпечення - автоматизованого та ручного, дослідницького та функціонального, сумісності, UI / UX, регресії, модульного, API та тестування продуктивності. Удачі, обернувши голову навколо них усіх!

Однак загальним для всіх цих типів є те, що кожен вимагає від вас ретельної документації з контролю якості. Якість тестових документів визначає, чи стане ваша робота корисною або піде даремно.

Я написав цю статтю, щоб полегшити вам життя. Отже, це ваш найвищий посібник із написання документації з контролю якості програмного забезпечення, яка буде працювати.

Складіть план тестування та звіт про хід тесту

План тестування - це керівний документ, який викладає загальну картину процесу контролю якості та включає список завдань, стратегію, ресурси та графік.

Перш ніж створювати документ плану якості, запитайте себе: "Яка мета програмного рішення?" та “Які функції потрібно протестувати?”. Не поспішайте тестувати кожну окрему частину програмного забезпечення. Вам потрібно вирішити, які методології, технології та інструменти ви будете використовувати.

План тесту допоможе зрозуміти наступне:

  • Які критерії прийнятності?
  • Які ресурси вам потрібні? Які операційні системи, скільки копій та з якою ліцензією? Вам потрібні технічні консультанти?
  • Чи добре визначені ваші ролі та обов'язки?
  • Що таке часові рамки тестування?

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

План випробування та звіт

Створіть тестові кейси

Після того, як ви роз’яснили набір функцій, які потрібно перевірити у вашому плані тестування, вам потрібно створити тестовий приклад для кожної частини вашого програмного забезпечення.

Тестові кейси досить прості - ця документація з контролю якості складається з 7 розділів: ідентифікатор, тестовий кейс, кроки тестування, очікуваний результат, статус, фактичний результат та коментарі.

  1. Ідентифікатор - це унікальний номер, призначений вашому тестовому випадку.
  2. У розділі « Тестовий випадок» ви вказуєте вимоги, які ви будете тестувати, та надаєте посилання на них у документі технічних характеристик.
  3. У розділі Кроки тестування ви перелічите всі дії, необхідні для завершення тесту.
  4. У розділі " Очікуваний результат " ви підсумовуєте результат конкретного тесту, якщо він успішний.
  5. У розділі Статус ви вказуєте, пройшов чи не пройшов тестування певний крок.
  6. У розділі Фактичний результат ви пояснюєте результат невдалого тесту.
  7. Розділ " Коментарі " не є обов'язковим, але ви можете додати його, щоб залишити деякі додаткові примітки.
Тестовий кейс

Напишіть звіт про дефекти

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

Звучить просто, так? Так, але лише до тих пір, поки ви не почнете документування. Тут ви можете побачити приклад типового звіту про дефект:

Звіт про дефекти

Звіт про дефект складається з наступних розділів: ідентифікатор, коротка інформація, опис, етапи відтворення, відтворюваність, важкість, пріоритет, середовище та вкладення.

  1. Кожному конкретному випуску програмного забезпечення присвоюється унікальний номер - ідентифікатор . Це оптимізує навігацію по документах з контролю якості та полегшує спілкування між розробниками, тестувальниками та прем'єр-міністрами.
  2. У підсумковому розділі ви даєте коротку відповідь на три простих запитання: що сталося, де та за яких обставин.
  3. В описі розділу , ви описуєте помилку в деталях. Ви повинні розповісти про фактичні та очікувані результати. Корисно надати посилання на ваші вимоги до програмного забезпечення.
  4. Потім ви пишете про кроки відтворення (STR) . Це показує розробникам, як саме відтворити проблему. Не пропустіть крок, інакше ваш звіт може повернутися до вас.
  5. У розділі відтворюваності ви уточнюєте, чи з’являється помилка кожного разу, коли ви дотримуєтеся STR. Вам слід використовувати цифри, щоб показати приблизні шанси, наприклад 7 разів із 10.
  6. У розділі серйозності ви пояснюєте, наскільки велика шкода може принести проекту. Іншими словами, це показує технологічний ступінь впливу дефекту на всю систему. Навіть невелика проблема може погано вплинути на всю програму.
  7. Пріоритет показує, наскільки важливим є конкретний звіт про дефект. Пріоритет можна позначити за допомогою букв - "А" для найбільш термінових і "Z" для найменш термінових, цифр - "1" для найбільш термінових і "9" для найменш термінових, або просто слів типу "високий ”,„ Середній ”або„ низький ”.
  8. У розділі навколишнього середовища слід визначити, на які операційні системи чи версії браузера це вплинуло.
  9. Нарешті, вкладення містять список відеозаписів, знімків екрана або файлів журналів консолі, доданих до звіту про дефекти.

Дотримуйтесь цих корисних порад щодо написання звітів про дефекти

  1. Напишіть достатнє та адекватне резюме. Неважливо, довгий він чи короткий. Важливо те, що це повинно бути чітко.
  2. Погляньте на резюме та опис. Чи виглядають вони приблизно однаково? Ви, мабуть, забули описати очікувані та фактичні результати в описі та додати посилання на вимоги.
  3. Фіксуйте проблему за допомогою скріншота. Це може заощадити вам і команді розробників багато часу. Іноді достатньо одного погляду на картинку, щоб зрозуміти ситуацію.
  4. Перш ніж повідомляти про проблему, спробуйте відтворити її принаймні 3 рази, щоб переконатися, що вона існує.
  5. Повідомте про проблему якомога швидше та повідомте свого менеджера проекту або власника продукту, якщо проблема важлива.
  6. Перевірте граматичні помилки у вашій документації з контролю якості, щоб граматична поліція вас не знищила.
  7. Як би комічно це не звучало, переконайтеся, що проблема не є особливістю - перегляньте документацію ще раз!
  8. Не пропустіть жодної важливої ​​інформації у своїх кроках для відтворення.

Подайте звіт про дефекти

Звіти про дефекти проходять життєвий цикл - від моменту повідомлення про проблему до моменту закриття проблеми.

Життєвий цикл звіту про дефекти

Першим кроком є ​​складання та подання звіту про дефект. На даний момент керівник проекту або технічний керівник вирішує, чи доручити його розробнику, чи відмовити йому на підставі недостатності або неадекватності.

Після того, як призначений розробник виправив помилку, вам як службі контролю доведеться ще раз перевірити та переконатися, що її виправлено. Якщо так, ви можете закрити звіт про дефект. Найкраща практика - закрити його через тиждень-два.

Якщо помилка не виправлена, ви знову відкриваєте звіт про дефект і надсилаєте його назад призначеному розробнику. Процес виправлення помилок може бути тривалим, але ви повинні зберігати стійкість, поки остаточно не закриються всі звіти про дефекти.

Завернути

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

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

Вам потрібно покращити якість вашого програмного забезпечення?

Моя компанія KeenEthics надає серйозні послуги з розробки та забезпечення якості. Якщо вам потрібна кошторис для подібного проекту, сміливо зв’язуйтесь .

Якщо вам сподобалася стаття, вам слід продовжити тему «Що таке прототипування та навіщо це нам потрібно» та «Мінімальний життєздатний продукт: між ідеєю та продуктом».

PS

Оригінальну статтю, розміщену в блозі KeenEthics, можна знайти тут: Як написати документацію з контролю якості, яка буде працювати?