Тест-кейс – це професійна документація тестувальника, послідовність дій, спрямована на перевірку будь-якого функціоналу, що описує як прийти до очікуваного результату.
Під тест-кейсом також може матися на увазі відповідний документ, який являє собою формальний запис тест-кейса.
Також виділяють:
– високорівневий тест-кейс (high level test case) – тест-кейс без конкретних вхідних даних та очікуваних результатів.
Як правило, такий тест-кейс обмежується загальними ідеями та операціями, схожий за своєю суттю з докладно описаними пунктами чекліста. Досить часто зустрічається в інтеграційному і системному тестуванні, а також на рівні димового тестування. Може служити відправною точкою для проведення дослідного тестування або для створення низькорівневих тест-кейсів.
– низькорівневий тест-кейс (low level test case) – тест-кейс з конкретними вхідними даними та очікуваними результатами.
Являє собою «повністю готовий до виконання» тест-кейс і є найбільш класичним видом тест-кейсів. Початківців тестувальників найчастіше вчать писати саме такі кейси, тому що прописати всі дані докладно набагато простіше, ніж зрозуміти, якою інформацією можна знехтувати, при цьому не знизивши цінність тест-кейса.
У тестуванні слово «кейс» слід перекладати як «ситуація» просто тому, що тест-кейс – це ситуація, яку потрібно створити для перевірки роботи однієї окремо взятої функціональності. Всі кроки, перераховані в кейсі, дають можливість перевірити лише одну тестову ситуацію, лише один сценарій використання ПЗ.
Тема кейса – описова назва тесту, яка спрощує його пошук та розуміння його змісту.
У темі тест-кейса не повинно бути:
1.Залежностей від інших тест-кейсів. Пов'язаний тест-кейс завжди може бути видалений через непотрібність або він може бути змінений, в цьому випадку стане незрозуміло, як виконати тест-кейс, в якому є посилання. Також, через залежність тест-кейсів, може виникнути відчуття, що тестований продукт вже приведений до потрібного стану завдяки виконанню пов'язаних тест-кейсів.
2.Нечітких формулювань. Якщо опис теми буде нечітким, то це, як мінімум, ускладнить проходження тест-кейса і сприйняття тест-сьюта в цілому.
При створенні теми тест-кейса потрібно пам'ятати:
- те, що очевидно для вас зараз, може стати абсолютно незрозумілим через декілька місяців.
Так, скорочення з нерозшифрованими абревіатурами, зрозумілими вам зараз, можуть згодом стати китайською грамотою для вас самих, тому простіше буде написати тест-кейс заново, ніж пробиратися через нетрі необачно зроблених скорочень, як в темі, так і всередині кейса;
- тест-кейс, тема якого не може бути зрозуміла і згодом виконана ніким, крім його автора, повинен бути публічно знищений.
Обгрунтування просте: автор кейса може захворіти, піти у відпустку, піти з компанії і т.д. Будь-який тест-кейс повинен створюватися з думкою про колегу, який одного разу візьме його в руки.
Приклад:
Якщо тема порожня або ж в ній просто надруковано «10», то кожна людина, виконуючий цей тест-кейс, кожен раз буде витрачати кілька хвилин свого часу і/або часу свого колеги на з'ясування того, що ж перевіряється цим тест-кейсом.
3. Зайвої деталізації. Надлишкова інформація лише ускладнює розуміння вкладеного в тему сенсу.
Тестувальник при виконанні тест-кейса спочатку прочитає тему, усвідомить її, вже приблизно уявить, що йому зараз потрібно буде виконати, і тільки після цього перейде до кроків.
Приклад:
Чи зручно буде виконувати тест-кейс, якщо в темі надруковано:
«У цьому тест-кейсі ми перевіряємо пункт 21.6 специфікації номер 34 «Сценарій додавання кредитної картки до рахунку користувача»?
До того ж, ім'я тест-кейса повинно бути унікальним для проекту і нести в собі опис функціональності, що тестується. Це життєво необхідно для спрощення пошуку необхідного кейса серед сотень і тисяч інших на проекті.
Навички, необхідні для написання тест-кейсів:
- Уміння розділяти систему на складові (робити декомпозицію). Тобто, потрібно не тільки вміти бачити систему як ціле, а й вміти розкладати її на складові частини. Це дуже корисна навичка для проведення функціонального тестування, де перевіряється кожна складова продукту.
- Уміння збирати та аналізувати вимоги до продукту. Якщо немає формально описаних вимог (специфікацій) – потрібно вміти їх збирати у розробників, аналітиків, користувачів.
- Уміння розставляти пріоритети. Тест-дизайнер повинен вміти відрізняти важливіше від менш важливого, а також розставляти пріоритети тестування.
- Уміння формулювати свої думки (письмово та усно). Це вміння важливе для тестувальника в принципі. Тест-дизайнеру воно дуже допомагає при створенні тест-кейсів.
- Знання технік тест-дизайну, а також уміння застосовувати їх на практиці.
Важливі моменти при складанні тест-кейса:
Розуміння вимоги, за якою складається кейс
Скласти і описати ефективний тест-кейс не вийде, якщо немає розуміння, яким саме чином повинен бути реалізований той чи інший функціонал програми. Ефективніше буде витратити сили та час на уточнення неточностей і в підсумку написати «робочий» тест-кейс, ніж спершу скласти абсолютно неправильний, зрозуміти в процесі тестування, що він не спрацював як треба, знову витратити час на уточнення, і тільки після цього повністю переробити і отримати робочий варіант.
Простота та легкість для розуміння
Важливо, щоб тест-кейс був описаний зрозумілими словами, без використання спеціальної термінології та складних мовних конструкцій, так як його можуть проходити фахівці різного рівня кваліфікації та спеціалізації (досвідчені тестувальники та початківці, керівники проекту, розробники, аналітики і навіть співробітники замовника, не завжди володіють достатнім рівнем знань у галузі комп'ютерних технологій).
Окрема увага приділяється наборам тестових даних
Якщо тест передбачає використання будь-яких даних, слід звернути увагу на правильність їх складання і подальші вказівки. В іншому випадку такий тест є марним.
Стандартні помилки при написанні теми тест-кейсів
Читати теорію – одне, робити на практиці – зовсім інше. Зазвичай в теорії все зрозуміло, а на практиці отримуємо приблизно такий тест-кейс:
«Тест-кейс № 01. Створення мешканця.»
Спробуйте, не дивлячись відповідь, самі знайти проблемні зони в цьому тест-кейсі. А потім перевірте себе.
Розберемо помилки кейса 01.
Абстрактна назва.
На перший погляд назва гарна, коротка і зрозуміла – адже ми дійсно створюємо мешканця. Але! Якщо ми тепер створимо ще кілька тест-кейсів на введення некоректних ПІБ, то у них буде та ж назва.
У підсумку, новий тестувальник, отримавши завдання перевірити кейс «Створення мешканця», виявить в системі два десятка перевірок з такою назвою і впаде в ступор – який же обрати?
Завжди пам'ятайте про «коротко, але змістовно». За назвою тест-кейса тестувальник, який знає проект, повинен зрозуміти, що треба робити, не заглядаючи в кроки. Тому доповнюємо назви – «Створення мешканця без по-батькові», «Створення мешканця c цифрами в полі «Ім'я»» і т. ін.
Виправимо тест-кейс щодо зауважень. Ось що вийшло:
«Тест-кейс № 02. Створення мешканця з коректними ПІБ.»
Вже добре, але чи можна ще поліпшити цей тест-кейс?
Зараз знову спробуйте, не дивлячись відповідь, знайти проблемні зони в цьому тест-кейсі. А потім перевірте себе.
Отже, помилки кейса 02:
Абстрактна назва.
Слова «коректний», «правильний» і т.д. в назві тест-кейса такий же маркер, як «помилка» в назві бага. Таких слів треба уникати.
Позитивних перевірок можна придумати хоч сто. Але чомусь вони будуть відрізнятися. «Створення мешканця, у якого немає по-батькові», – це теж кейс з коректним ПІБ. Тільки з такої назви відразу зрозуміло, про що кейс.
Тому забудьте про слова «коректний», «некоректний» і т.п., намагайтеся писати зрозуміліше. І завжди пам'ятайте принцип «коротко, але зрозуміло». А поділ кейсів на змістовні групи (негативні тести, позитивні тести, тести на особливі випадки) зробіть в системі керування тест-кейсами через прапори або окремі набори тестів.
Виправлена версія теми тест-кейса:
«Тест-кейс № 03. Створення мешканця з повним ПІБ.»
У цьому варіанті теми вже гранично зрозуміло, що даним тест-кейсом буде перевірятися можливість створення мешканця із зазначенням всіх трьох атрибутів – прізвища, імені та по-батькові.
