Меню

Посібник з документації для тестування програмного забезпечення (чому це важливо)

software testing documentation guide

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

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

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

Посібник з документації для тестування програмного забезпечення (Чому це

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

Мій досвід

Просто хочу поділитися з вами своїм досвідом:

Ми передали проект (із невідомою проблемою) одному з наших клієнтів (сердитий клієнт). І вони виявили проблему на стороні Клієнта, що було для нас дуже поганою ситуацією, і, як завжди, вся вина була в QA.

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

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

“Чорнило краще найкращої пам’яті” - китайське прислів’я

як надрукувати вміст масиву

Тестова документація: що це?

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

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

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

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

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

Це мій досвід, ми маємо один продукт, який має дещо заплутану функціональність.

Коли я почав працювати над цим, я попросив менеджера отримати деякі довідкові документи, і я отримав відповідь 'Ні, у нас немає жодних документів'. Потім я зробив це, тому що, як QA я знав, ніхто не може зрозуміти, як використовувати виріб без документів та навчання. І якщо користувач не задоволений, як ми збираємося заробляти на цьому продукті?

“Відсутність документації стає проблемою для прийняття” - Wietse Venema

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

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

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

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

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

- Уточнити цілі та методи якості
- Забезпечте чіткість завдань та послідовність виконання
- Забезпечити внутрішню координацію в роботі з клієнтом
- Надайте зворотний зв’язок щодо профілактичних дій
- Надайте зворотний зв’язок щодо вашого циклу планування
- Створіть об’єктивні докази роботи вашої системи управління якістю

10 порад, які допоможуть вам досягти цілі тестової документації

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

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

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

Це просто для дотримання деяких стандартів (CMMI, ISO тощо), але коли справа доходить до фактичного впровадження, скільки з цих документів ми насправді використовуємо? Нам просто потрібно синхронізувати наш процес якості зі стандартами документації та іншим процесом в організації.

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

різниця між планом випробування та стратегією випробування

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

Ось 10 найкращих порад, які допоможуть вам досягти мети документації до тесту:

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

# два) Процес, визначений QA, повинен слідувати технічним працівникам, це допомагає усунути більшість дефектів на початковому етапі.

# 3) Тільки створення та підтримка Шаблони тестування програмного забезпечення недостатньо, змусьте людей ними користуватися.

# 4) Не лише створюйте та залишайте документ, а й оновлюйте за необхідності.

# 5) Вимога до змін є важливим етапом проекту. Не забудьте додати їх до списку.

# 6) Використовуйте контроль версій для всього. Це допоможе вам легко керувати документами та відстежувати їх.

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

# 8) Спробуйте задокументувати те, що потрібно для розуміння вашої роботи, і що вам потрібно буде зробити для зацікавлених сторін, коли це потрібно.

# 9) Використовуйте стандартний шаблон для документації. Як і будь-який шаблон аркуша Excel або шаблон файлу документа, і дотримуйтесь його для всіх своїх потреб у документі.

# 10) Діліться усіма документами, пов’язаними з проектами, в одному місці, доступному кожному члену команди для ознайомлення, а також для оновлення, коли це потрібно.

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

Адже “документація потребує документації”. Чи не так?

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

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

Тут я перелічую кілька важливих документів для тестування програмного забезпечення, якими ми повинні регулярно користуватися / підтримувати:

1) План випробувань
2) Дизайн тесту та Специфікація тестового кейсу
3) Тестова стратегія
4) Підсумкові звіти про тести
5) Щотижневий звіт про стан
6) Документи користувача / Посібники
7) Звіт про прийняття користувача
8) Оцінка ризику
9) Журнал випробувань
10) Звіти про помилки
одинадцять) Дані тесту
12) Тестовий аналіз

Крім того, тестерам програмного забезпечення регулярно потрібно посилатися на такі документи:
1) Технічні вимоги до програмного забезпечення
2) Функціональні документи

Висновок

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

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

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

Про автора: Ця стаття написана членом команди STH Техасвіні. Вона працює менеджером з контролю якості в організації.

Які ще документи ви зберігаєте під час щоденного тестування?

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

^