Меню

Як виконати огляди тестової документації за 6 простих кроків - процес контролю якості

how perform test documentation reviews 6 simple steps qa process

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

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

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

Перевірка теж є формою тестування - частина перевірки V&V, яка також називається статичним тестуванням.

Виконайте огляди тестової документації

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

Типи відгуків

  • Перегляд власної роботи - Самоперевірка
  • Експертна оцінка
  • Наглядова

Якщо перевірка становить половину практики тестування, тоді перевірка - це інша, але часто вказівки є неясними - тож давайте змінимо це ЗАРАЗ. Це загальна практика зі статтями в STH, ми почнемо з питань, що? Чому? Як?

безкоштовна програма резервного копіювання для Windows 7 -

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

Що ми переглядаємо?

Все створене необхідно переглянути. Нижче наведено деякі загальні оглядові артефакти:

  • План випробувань
  • Тестові сценарії
  • Тестові шаблони
  • Тестові кейси
  • Дані тесту
  • Звіти… тощо

Відгуки про тестовий документ

Чому огляд?

З точно тієї ж причини ми тестуємо програмне забезпечення, Наприклад,

  • Виявити помилки
  • Для перевірки повноти
  • Щоб переконатись, що норми та рекомендації дотримуються чи ні ... тощо.

Як переглянути?

Нижче наведено перелік задіяних заходів:

  • Визначте критерії - Є контрольний список, на що слід звернути увагу?
  • Виконайте перевірку
  • Запишіть свої результати
  • Діліться, обговорюйте та впроваджуйте необхідні зміни
  • Контроль версій залучених документів
  • Підпишіться та використовуйте документ за призначенням.

Процес перевірки тестових документів

Тепер ми обговоримо кожен крок у розділі «Як» - іншими словами, процес його виконання.

(Більшості з нас, тестувальників, не подобається текстовий процесор, чи не так? Для нас це або означає набагато більше роботи, або якесь управлінське завдання високого рівня, яке нам доводиться робити, навіть якщо ми цього не хочемо - заради певної відповідності, про яку ми не маємо уявлення. Але, повірте мені, коли ви придумаєте процес, який працює і досить просто, щоб ми зрозуміли, навіщо нам це робити, це може бути цікаво! Просто зіграйте зі мною.)

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

Крок 1: Визначте критерії

# 1) Що ви очікуєте знайти? Ви можете шукати такі речі, як:

  • Орфографічні помилки (Звучить занадто безглуздо? Я не думаю, що одного разу в одній зі своїх статей я написав “Веб-об’єкт” замість “Веб-об’єкт” - повністю змінює значення. Майже робить це занадто безглуздо, щоб сприймати його серйозно.)
  • Відповідність формату / шаблону
  • Покриття функціональності та коректність
  • Простота розуміння
  • Дотримувались стандартів - конвенції про іменування, послідовну нумерацію ... тощо.

# два) Складіть контрольний список - Контрольні списки дуже універсальні. Це може бути настільки складно, як контрольний список для перегляду, або настільки простим, як список продуктів. Все це займає деякий час, щоб зробити це, і як тільки ви це зробите, це так само просто, як перевірити УВІМКНЕНО або ВИМКНЕНО.

# 3) Як повідомити результати? - Вибирайте все, що є зручним, бажано метод, який можна записати та відстежити.

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

Крок 2: Виконайте перевірку

# 1) За допомогою контрольного списку, який ви склали раніше, підтвердьте документ та надайте свої відгуки.

Крок 3: Запишіть свої результати

# 1) Знову ж, використовуючи метод, визначений на кроці 1, запишіть і повідомте свої результати.

# два) Повідомляючи про свої зауваження чи пропозиції щодо змін, поводьтеся з ним не інакше, як із повідомленням про дефект. Нічого не пропускайте. Будьте детальні.

Крок 4: Діліться, обговорюйте та впроваджуйте необхідні зміни

# 1) Ніхто не любить, коли йому кажуть, що їх робота неправильна або неповна. Тому майте на увазі наступні вказівки, коли ви надаєте негативні відгуки.

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

# два) Отримати підпис.

# 3) Нехай внесені зміни

Крок 5: Контроль версій залучених документів

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

Як налаштувати eclipse для C ++ - -

Крок 6: Підпишіться та використовуйте документ за призначенням

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

# два) Ще одне питання, яке виникає, - це чи ми перевіряємо перевірку після внесення змін? Скільки разів триватиме цей процес - робота - перегляд - виправлення - а потім перегляд ще раз? Допоки?

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

Ось, ви закінчили. Чи не простий цей процес?

Окуляри, які слід пам’ятати

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

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

Зразок документа для перевірки тестових кейсів: (натисніть, щоб збільшити зображення)

Зразок документа для перевірки тестового кейсу

До вас

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

Про автора: Це допис Сваті Сіели - експерт з ручного та автоматичного тестування з більш ніж 9-річним досвідом роботи в галузі . Вона також викладач нашого навчального курсу з тестування програмного забезпечення.

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

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

^