Меню

Контрольні списки тестування програмного забезпечення QA (зразки контрольних списків включені)

qa software testing checklists

Спробуйте Наш Інструмент Для Усунення Проблем

Перевірка контролю якості програмного забезпечення

Сьогодні ми пропонуємо вам ще один якісний інструмент, який так часто використовується недостатньо, що ми думали, що будемо переробляти деталі про нього в надії, що він поверне свою втрачену славу. Це «контрольний список».

Визначення: Контрольний список - це каталог предметів / завдань, які записуються для відстеження. Цей список може бути упорядкований у послідовності або може бути випадковим.

Контрольні списки є невід’ємною частиною нашого повсякденного життя. Ми використовуємо їх у різних ситуаціях - від продовольчих магазинів до складання списку справ для денних заходів.

Контрольні списки тестування програмного забезпечення якості

Що ви дізнаєтесь:

Огляд контрольних списків тестування програмного забезпечення якості

Як тільки ми потрапляємо в офіс, ми завжди складаємо список речей, які потрібно зробити на цей день / тиждень, як показано нижче:

Коли і коли елемент у списку закінчено, ви викреслюєте його, вилучаєте зі списку або ставите галочку біля пункту, щоб позначити його завершення. Чи не все це нам занадто звично?

Однак чи все це для чого можна використовувати?

найкращий сайт для перегляду аніме

Чи можемо ми офіційно використовувати контрольні списки в наших ІТ-проектах (зокрема, QA), і якщо так, то коли і як? Це те, що буде висвітлено нижче.

Я особисто виступаю за використання контрольних списків з таких причин:

  • Він універсальний - може використовуватися на що завгодно
  • Легко створювати / використовувати / підтримувати
  • Аналіз результатів (виконання завдання / стан виконання) надзвичайно простий
  • Дуже гнучкий - ви можете додавати або видаляти елементи за потреби

Як і загальна практика, ми поговоримо про аспекти 'Чому' та 'Як'.

  • Навіщо нам потрібні контрольні списки? : Для відстеження та оцінки завершеності (або невиконання). Записувати завдання, щоб нічого не пропустити.
  • Як ми створюємо контрольні списки? : Ну, це не може бути простіше. Просто запишіть все пункт за пунктом.

Приклад контрольних списків для процесів контролю якості:

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

  • Огляд готовності до тесту
  • Коли припиняти тестування або контрольний список критеріїв виходу

# 1) Огляд готовності до тесту

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

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

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

Додаткова інформація: Огляд готовності до тестування, як правило, створюється, а огляд проводиться представником команди з контролю якості. Результати передаються прем'єр-міністрам та іншим членам команди, щоб вказати, чи готова група тестування чи не перейти до фази виконання тесту.

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

Критерії перевірки готовності до тесту (TRR)

Статус

Усі вимоги доопрацьовано та проаналізовано Готово
План випробувань створений та переглянутий Готово
Підготовка тестових кейсів зроблено
Перегляд тестового кейсу та підписання
Дані тесту доступність
Тестування диму
Чи проведено перевірку розумності?
Команда усвідомлює ролі та обов'язки
Команда обізнана про очікувані результати
Команда, яка знає про Протокол зв'язку
Доступ команди до програми, інструментів контролю версій, Тестовий менеджмент
Команда навчена
Технічні аспекти - Server1 оновлено чи ні?
Визначено стандарти звітності про дефекти

Тепер усе, що вам потрібно зробити з цим списком, - це позначити як виконане чи не виконане.

# 2) Контрольний список критеріїв виходу

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

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

Критерії виходу

Статус

Виконано 100% тестових сценаріїв Готово
95% прохідності тестових сценаріїв
Немає відкритих критичних та високих вад
95% дефектів середньої тяжкості були закриті
Усі дефекти, що залишились, або скасовуються, або документуються як Запити на зміну для майбутнього випуску
Усі очікувані та фактичні результати фіксуються та документуються за допомогою сценарію тесту Готово
Усі показники тесту збираються на основі звітів від HP ALM
Усі дефекти реєструються в HP ALM Готово
Пам’ятка про закриття тесту заповнена та підписана

Контрольний список тестування

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

Контрольний список тестування:

  1. Створити системні та приймальні тести ()
  2. Почати створення приймальних випробувань ()
  3. Визначте команду випробувачів ()
  4. Створити робочий план ()
  5. Створити тестовий підхід ()
  6. Пов’язати критерії прийнятності та вимоги, щоб лягти в основу перевірки прийнятності ()
  7. Використовуйте підмножину системних тестових випадків, щоб сформувати частину вимоги до приймальної перевірки ()
  8. Створити сценарії для використання замовником, щоб продемонструвати, що система відповідає вимогам ()
  9. Створіть графік тестування. Включіть людей та всі інші ресурси. ()
  10. Провести перевірку прийнятності ()
  11. Почати створення системного тесту ()
  12. Визначте учасників тестової групи ()
  13. Створити робочий план ()
  14. Визначити вимоги до ресурсів ()
  15. Визначити інструменти підвищення продуктивності для тестування ()
  16. Визначити вимоги до даних ()
  17. Домовитися з Центром обробки даних ()
  18. Створити тестовий підхід ()
  19. Визначте всі необхідні зручності ()
  20. Отримати та переглянути існуючий тестовий матеріал ()
  21. Створити опис тестових завдань ()
  22. Визначити стани, умови, процеси та процедури проектування ()
  23. Визначте необхідність тестування на основі коду (білий ящик). Визначте умови. ()
  24. Визначте всі функціональні вимоги ()
  25. Завершити створення інвентаризації ()
  26. Почати створення тестового кейсу ()
  27. Створюйте тестові кейси на основі опису тестових завдань ()
  28. Визначити логічні групи бізнес-функцій для нової системи ()
  29. Розділіть тестові кейси на функціональні групи, які простежуються для тестування інвентарю ()
  30. Розробити набори даних, що відповідають тестовим кейсам ()
  31. Кінець створення тестового кейсу ()
  32. Перегляньте з користувачами бізнес-функції, тестові кейси та набори даних ()
  33. Отримати підписку на проект тесту від керівника проекту та контролю якості ()
  34. Кінцевий дизайн тесту ()
  35. Почати підготовку до тесту ()
  36. Отримати ресурси підтримки тестування ()
  37. Окресліть очікувані результати для кожного тесту ()
  38. Отримати дані тесту. Перевірка та відстеження для тестування випадків ()
  39. Підготуйте докладні сценарії тестів для кожного тесту ()
  40. Підготуйте та документуйте процедури налаштування навколишнього середовища. Включити резервне копіювання та плани відновлення ()
  41. Завершення фази підготовки до випробувань ()
  42. Тест системи проведення ()
  43. Виконання тестових сценаріїв ()
  44. Порівняйте фактичний результат із очікуваним ()
  45. Документи розбіжностей і створити звіт про проблему ()
  46. Підготувати введення фази обслуговування ()
  47. Повторно виконати тестову групу після усунення несправностей ()
  48. Створіть остаточний звіт про тестування, включіть список відомих помилок ()
  49. Отримати офіційний підпис ()

Контрольний список автоматизації

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

Q # 1) Чи можна визначити тестову послідовність дій?

безкоштовне програмне забезпечення для малого бізнесу

Відповідь: Чи корисно багато разів повторювати послідовність дій? Прикладами цього можуть бути прийомні тести, тести сумісності, тести продуктивності та регресійні тести.

Q # 2) Чи можна автоматизувати послідовність дій?

Відповідь: Це може визначити, що автоматизація не підходить для такої послідовності дій.

Запитання №3) Чи можна «напівавтоматизувати» тест?

Відповідь: Автоматизація частин тесту може пришвидшити час виконання тесту.

Q # 4) Чи поведінка програмного забезпечення, що тестується, однакова з автоматизацією, як і без?

Відповідь: Це є важливою проблемою для тестування продуктивності.

Q # 5) Ви тестуєте аспекти програми, що не стосуються інтерфейсу користувача? Відповідь: Майже всі функції, що не стосуються інтерфейсу, можуть і повинні бути автоматизованими тестами.

Q # 6) Чи потрібно запускати однакові тести на декількох конфігураціях обладнання?

Відповідь: Запустіть спеціальні тести (Примітка: В ідеалі кожна помилка повинна мати відповідний тестовий випадок. Спеціальні тести найкраще проводити вручну. Спробуйте уявити себе в реальних ситуаціях та використовувати своє програмне забезпечення так, як це робить ваш клієнт. Як виявляються помилки під час спеціального тестування слід створювати нові тестові кейси, щоб їх можна було легко відтворити, і щоб можна було проводити регресійні тести, коли ви перейдете до фази створення нульових помилок.)

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

Примітки:

  • Два вищезазначені приклади демонструють використання контрольних списків Процеси контролю якості , але використання не обмежується цими двома областями.
  • Елементи в кожному списку також є показниками, що дають уявлення читачам про те, який тип елементів можна включити та відстежувати - однак, список можна розширити та / або ущільнити за необхідності.

Ми справді сподіваємось, що наведені вище приклади успішно передали потенціал контрольних списків до процесів контролю якості та ІТ.

Отже, наступного разу, коли вам буде потрібен простий інструмент, який є напівформальним, простим та ефективним, ми сподіваємось, ми зорієнтували вас на надання шансів контрольним спискам. Іноді найкраще рішення є найпростішим.

Рекомендована література

^