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

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

Але не варто забувати про стратегію незалежних сервісів тестування програмного забезпечення. Давайте поговоримо про це.

Причини використання стратегії тестування

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

Що має бути описано в такій стратегії

• Які види тестування необхідно використовувати?
• Чи буде виконуватися UI-тестування, тестування працездатності компонентів системи, робота з конфігурування тощо;
• Чи буде команда QA виконувати статичні типи тестів, наприклад, перегляд визначених вимог;
• Чи будете ви проводити дослідницьке тестування і в якій пропорції.

Дуже корисно описати всі тестові дії, які так чи інакше будуть виконуватися у вашому плані.

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

Ви можете запитати: навіщо це робити? - Щоб пам’ятати все під час роботи над планом тестування.

Що буде основою для майбутніх тестів? Звідки ви будете брати значення для перевірки визначених тестів?

Наприклад, це можуть бути спеціальні вимоги, тестові скрипти, типові класифікації та стандарти.

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

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

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

Концепція плану тестування

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

Рекомендації щодо розробки планів випробувань

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

• TestPlanTemplate RUP;
• TestPlanTemplate IEEE 829.

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

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

• Що саме має бути протестовано (об’єкт тестування, використовуване веб-середовище, додаткові додатки, яке обладнання використовується для цього);
• Що буде протестовано (повний перелік функцій системи, які необхідно протестувати для перевірки її максимальної функціональності);
• Як саме ви будете тестувати (так звана стратегія тестування - типи тестування, а також те, як вони застосовуються до об’єкта тестування);
• Коли саме ви будете тестувати (логічно описана структура тестування: підготовчі роботи, процес тестування, аналіз отриманої інформації з урахуванням запланованих етапів веб-розробки проекту).

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

Потім, щоб зробити документ завершеним, ви повинні додати до нього наступні пункти:

• Перевірено фактичне оточення системи;
• Обладнання та віртуальні системи, використані для тестування;
• Можливі ризики та шляхи їх вирішення.

Типи тестових планів

Зазвичай можна зустріти такі типи:

• Генеральний план випробувань;
• Тестовий план (детальний план тестування).

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

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

Розгляд та затвердження плану

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

Наприклад, до складу такої проектної команди можуть входити:

• Основний працівник відділу QA;
• Тест-менеджер (головний QA-менеджер);
• Керівник відділу розвитку;
• Керівник проекту.

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

План тестування на 1 сторінці - 100% успіху!

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

Думаю, другий варіант йому сподобається більше!

План тестування

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

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

Не варто включати дрібні деталі, які не будуть цікавими для інших.

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

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

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

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

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

Наприклад, перелінковка може бути виконана для наступних об’єктів і компонентів:

• Інструменти, використані для тестування;
• Спеціальні тестові чартери;
• Перелік можливих ризиків;
• Посилання на використані прототипи та проведені тести;
• Документи про веб-структуру;
• Проектний документ на весь проект.

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

Кілька ідей для оригінальної презентації вашого плану тестування

Якщо у вас не так багато місця, будьте креативні!

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

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

Погляньте на такі варіанти:

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

  Панель інструментів Тип плану тестування

• Excel або інша таблиця. Ви можете легко показати в таблиці будь-які списки тестів або тестових скриптів, які ви будете використовувати для цього проекту.
• Дошка Trello. Хороший веб-інструмент, який дозволяє працювати з віртуальною дошкою, на якій можна писати всі необхідні завдання, а також стежити за статусом їх виконання. Такий стиль роботи з тестовими планами в деякій мірі нагадує роботу з agile-проектами.

Trello Board

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

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