TOP 13 помилок тестувальників, Різне, Програмування, статті

Дивна назва?


Зазвичай TOP-и круглочісленние (Fortuna 500, Руська 10-ка і т.д.)?


Чому саме 13? Чи не тому, що по загальноприйнятій думці (програмісти часто вважають свою думку – загальноприйнятим) тестувальники приносять одні нещастя?


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


Все набагато простіше …


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


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


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



  1. Вимоги
  2. Тест-кейси
  3. Управління помилками
  4. Документування
  5. Взаємодія

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


Вимоги


1. Вимоги необхідно тестувати


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


Мало того, що їх треба тестувати. Тестувати вимоги необхідно на самих ранніх етапах і / або стадіях процесу розробки (думаю, що Америки я не відкрив). Починати тестувати вимоги треба одразу, як тільки у вас з’явилася унікальна можливість отримати до них доступ, незважаючи на те, де і в якому вигляді вони знаходяться – в електронному вигляді, розміщені на загальнодоступному ресурсі, вислані вам по електронній поштою або тільки що сформувалися в голові консультанта / аналітика і ще не отримали формального відображення.


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


Наслідками або відсутності тестування вимог взагалі, або відкладання тестування вимог до кращих часів або тези “всі їхні недоліки виявляться в процесі розробки і тестування” є:



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


У висновку нотатки про тестування вимог ще раз наважуся повторити критерії якості вимог до програмного забезпечення:



Тест-кейси


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


Тест-кейс (тестовий випадок, test case) – Це набір умов та / або змінних, за допомогою яких тестировщик визначатиме наскільки повно тестоване додаток задовольняє пропонованим до нього вимогам. Для того, щоб переконатися, що вимога повністю задовольняється, може знадобитися кілька тест-кейсів. Для повного тестування всіх вимог, що пред’являються до додатка, повинен бути створений / виконаний щонайменше один тест-кейс для кожного вимоги. Якщо вимога має дочірні вимоги, то для кожного такого дочірнього вимоги повинен бути створений / виконаний також принаймні один тест-кейс. Деякі методології (наприклад, RUP) рекомендують створювати щонайменше два тест-кейсу для кожного вимоги. Один з них повинен виконувати позитивне тестування, інший – негативний.


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


Що формально характеризує написаний тест-кейс? Наявність відомого введення (Вхідні дані) і очікуваного результату, Який досягається після виконання тесту. Вхідні дані називаються передумовою тесту, а очікуваний результат – постусловіем тесту.


Написані тест-кейси часто об’єднуються в тестові набори (test suite).


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


2. Тест-кейси необхідно писати за вимогами


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


Одним з визначень якісного продукту (не обов’язкового програмного) є те, на скільки даний продукт задовольняє пропонованим до нього вимогам. Виходячи з такого підходу до якісного продукту, можна дати таке визначення тестування. Тестування – Це процес перевірки відповідності продукту пропонованим до нього вимогам. Тобто в процесі тестування програмного продукту ми визначаємо чи відповідає те, що написали програмісти, тому, що написали консультанти та аналітики (формалізувати вимоги і побажання Замовника).


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


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


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


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


Тому, резюмую все описане вище – базисом для підготовки тест-кейсів повинні бути вимоги (в тому чи іншому вигляді), а ні в якому разі не готовий продукт.


3. Тест-кейси повинні не повторювати вимоги, а перевіряти їх


Лінь … Вона є як джерелом великих проривів і відкриттів, так і причиною, яка робить безглуздою виконану роботу, проведеного даремно часу. Свідомість будь-якого почину, будь роботі надає результат (бажано, звичайно, позитивний), заради якого ця робота замислювалася і виконувалася.


Теж саме можна сказати і про тест-кейсах. Сенсом написання / виконання тест-кейсів є перевірка того, наскільки тестоване додаток задовольняє пропонованим до нього вимогам. Результатом виконання тест-кейсу повинні стати його проходження або провал, що підтвердить відповідність реалізації вимогу чи ні (до речі, для тестувальника будь-який результат є позитивним, правда, в разі провалу тест-кейсу – Більш приємним :)).


Що я маю на увазі, коли пишу, що тести повинні не повторювати вимоги, а перевіряти їх?


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


Є одне з функціональних вимог до системи, для якого необхідно написати тест-кейси: Значення в поле “Сума” має розраховуватися як сума значень з полів “A” і “B”.


Тест-кейс, написаний ледачим тестувальником:



Дії:


Ввести значення в поля “A” і “B”.


Очікуваний результат:


Значення в поле “Сума” має розраховуватися як сума значень з полів “А” і “B”. (Іноді ще також в графі з очікуваним результатом зустрічаються такі “шедеври” як: Див в ТЗ, відповідно до ТЗ, спостерігаємо очікувані значення і т.п.).



Тест-кейс, написаний неледачих тестувальником:



Дії:


1. В поле “А” ввести значення 2


2. В поле “B” ввести значення 3


3. Натиснути на кнопку “Розрахувати”


Очікуваний результат:


В поле “Сума” відобразилося значення 5



Чим другий тест-кейс краще першого?


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


Далі, якщо мова йде про приймальних тест-кейсах, які повинні обов’язково виконати розробники перед тим, щоб передати версію на тестування, то тут у випадку з першим тест-кейсом взагалі все погано. Тобто реакція розробника на такий тест-кейс така (суджу по своєму власному досвіду): “Я ж і так все робив за вимогами, тому має все працювати, як я і зробив. Тим більше я колись перевіряв, що 2 + 2 = 4 “. І розробник зі спокійною совістю ставить Pass і переходить до наступного тест-кейсу (який напевно буде таким же неоднозначним :)).


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


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


4. Написання приймальних тест-кейсів (за певними правилами)


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


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


Для припинення такої ситуації було перепробувано безліч різних способів і методів, починаючи з дружнього роз’яснення, проведення навчальних семінарів, написання чек-листів та пам’яток для розробників і закінчуючи різними ступенями покарання (наскільки дозволяє корпоративна культура), але нічого не допомагало. Тому було вирішено готувати деякі набори приймальних тест-кейсів для розробників, які вони в обов’язковому порядку повинні проганяти на системі для розробки перед викладенням тестової версії. Обов’язковою умовою викладення тестової версії є 100% Pass приймальних тест-кейсів. Після викладення тестової версії тестувальники починають свою роботу з повторного прогону того ж самого приймального набору для перевірки того, що розробники дійсно виконали всі тест-кейси (а не просто проставили позначки). Я тут не вдаюсь в технічні деталі всієї цієї процедури. За результатами такої перевірки тестувальниками відбувається розбір польотів, після якого хтось отримує прянички, а хтось батоги.


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


Парочку таких правил я вже написав в попередньому пункті: тест-кейси (в тому числі і приймальні) повинні перевіряти вимоги, а не повторювати їх і тест-кейси повинні бути однозначними, тобто максимально однаково розумітися як тестувальниками, так і розробниками. Тут про інше.


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


2. Існує два варіанти підготовки приймальних тест-кейсів: перший – після підготовки набору тест-кейсів для повного тестування вибрати з нього тест-кейси для приймального тестування, які покривають основний (позитивний) шлях роботи програми, другий – спеціально підготувати набір тільки приймальних тест-кейсів.


Однозначно сказати, який варіант краще, не можливо. Все дуже сильно залежить від ситуації і від тестованої функціональності. Одне можу сказати абсолютно точно (це і є таке правило) – Тест-кейси повинні бути складені таким чином, щоб вони не залежали від тих даних, від тих ситуацій, об’єктів тощо, якими тестировщик оперує на тестовій системі. Тобто всі необхідні дані, об’єкти і т.д., необхідні для прогону приймального тест-кейсу, повинні бути підготовлені самими розробниками. Як цього добитися? Написати допоміжні тест-кейси (або ж написати допоміжні дії в тому ж самому приймальному тест-кейсі), які дозволять зробити всі попередні приготування для основного тест-кейсу. У приймальних тестах для розробників не можна посилатися на якісь об’єкти з тестової системи. Самі розумієте, розробник просто може не знайти їх і, в кращому випадку, постарається розібратися в ситуації, а в гіршому – напише коментар до цього тест-кейсу і поставить Blocked.


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


Скорочено звучить він так – один тест-кейс – одна перевірка.


Як реагувати на наступний тест-кейс?



Steps


1. Дія 1


2. Дія 2


3. Дія 3


4. Дія 4


Expected Results


1. Результат 1


2. Результат 2


3. Результат 3


4. Результат 4



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


Тут же постає ще й інше питання – який статус виставляти для тест-кейсу, якщо або частина дій виконалася, а частина ні, або в результаті успішного виконання всіх дій частину очікуваних результатів з’явилася, а частина ні?


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


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


5. Своєчасність відміток про проходження / збої тест-кейсів


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


В нашому випадку мета проста – в будь-який момент часу відслідковувати поточну ситуацію по процесу виконання тест-кейсів:



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


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


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


Виконавши 125 тест-кейсів тестировщик навряд чи точно згадає, які тест-кейси пройшли успішно, а які ні.


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

Тому давайте робити все в свій час! Як то кажуть: “Дорога ложка до обіду”.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*