В сферата на финансовите услуги това се нарича „процес на създател-проверяващ“. В управлението на риска е широко известно като „принципът на четирите очи“. В управлението на ядрените оръжия в САЩ се нарича „концепцията за двама души“.
Всъщност всички те правят едно и също нещо: тези процеси включват допълнително ниво на оценка, потвърждение, оторизация или одобрение, за да се гарантира точността, качеството или уместността на резултата.
В разработката на софтуер това се нарича тестване или осигуряване на качеството. Просто казано, тестването на софтуер оценява кода, за да се гарантира, че работи както се очаква. За да извършват тази дейност ефективно, екипите по качеството използват мощен инструмент, наречен тестов случай.
В тази публикация в блога разглеждаме какво представляват тестовите случаи, защо са необходими, кога да ги използваме и, най-важното, как да ги пишем.
⏰TL;DR: Как да пишете ефективни тестови случаи за качеството на софтуера
1. Какво е тестов случай в тестването на софтуер?Тестов случай е документиран набор от стъпки, входни данни, условия и очаквани резултати, използвани за проверка дали дадена функционалност работи както е предвидено.
2. Защо тестовите случаи са важни за екипите за осигуряване на качеството?Те помагат за откриването на дефекти, валидирането на изискванията, намаляването на риска и гарантирането, че новите актуализации не нарушават съществуващата функционалност.
3. Каква е разликата между тестов случай и тестов сценарий?Тестовият сценарий е общо описание на това, което трябва да се тества, докато тестовият случай предоставя подробни инструкции за това как да се тества.
4. Какво трябва да включва един добър тестов случай?Обикновено той съдържа идентификационен номер, описание, предварителни условия, стъпки за изпълнение, очаквани резултати и място за записване на действителните резултати.
5. Как екипите могат да пишат по-добри и по-бързи тестови случаи?Използвайте ясни стъпки, мислете като потребител, фокусирайте се върху една цел на тест, преглеждайте работата си с колеги и разчитайте на шаблони и инструменти, които могат да се използват повторно.
Какво е тестов случай?
Тестовият случай е набор от действия, условия и входни данни, използвани за оценка на качеството на софтуерно приложение.
Да приемем, че сте създали формуляр за въвеждане на името и имейл адреса на потребителя за абонамент за бюлетин. Тестовият случай за него ще посочва следното:
Действия [както насочени към потребителя, така и вътрешни]: Всичко, което се очаква да направи потребителят или софтуерът, за да завърши работния процес в разработвания софтуер.
- Потребителят въвежда име
- Потребителят въвежда имейл адрес
- Потребителят кликва върху „Изпрати“
- Потвърждаващо имейл изпратено до потребителя
- Данните се запазват в съответната база данни
- Данните се добавят към съответния списък за бюлетин
Условия: Изискванията, които се очаква потребителят или системата да изпълнят при извършване на своите действия.
- Запазете, ако валидирането за полето „име“ е прието, в противен случай покажете съобщение за грешка
- Запазете, ако валидирането за полето за имейл адрес е прието, в противен случай покажете съобщение за грешка
- Добавете към списъка за бюлетина само ако потребителят е потвърдил своя имейл адрес
- Ако потребителят вече съществува, покажете съответното съобщение за грешка
Входни данни: Примери за това какво е приемлив вход за функцията. Обикновено екипите за осигуряване на качеството [QA] създават тестови данни, които могат да тестват положителни и отрицателни резултати.
Например, ако условието за валидиране на полето „име“ е „може да съдържа само букви от азбуката и интервал“, тестовите данни биха били
- Джейн Доу, която отговаря на критериите
- Адам Сандер, което не отговаря на критериите
Защо тестовите случаи са важни в софтуерното инженерство?
Методът на тестовите случаи е всеобхватен, систематичен и повторяем подход към тестването на софтуер. Въпреки че основната му цел е да гарантира качеството на приложението, той добавя множество нива на стабилност и надеждност към самия процес на софтуерно инженерство.
✅ Идентифициране на дефекти: Тестовите случаи помагат за откриването на дефекти в софтуера. Те са решаващи за това дали приложението е безопасно за пускане в производствена среда.
✅ Проверка на изискванията: Тестовите случаи гарантират, че това, което сте създали, е точно това, което сте имали предвид от самото начало. Това е особено важно, ако сте сервизна организация, която разработва софтуер за външни заинтересовани страни с конкретни изисквания.
✅ Намаляване на риска: Тестовите случаи оценяват дадена функция по отношение на сигурността, производителността и финансовите рискове. Аналитикът по качеството включва и условия, свързани с нормативната съответствие, индустриалните стандарти и др., за да се увери, че всички аспекти са обхванати.
✅ Балансиране на цялостната картина: Дадена нова функция може да работи добре, когато е изолирана. Но когато бъде интегрирана в останалата част от софтуера, тя може да спре да работи или да доведе до спиране на друга функция. Тестовите случаи гарантират, че това ще бъде забелязано, преди да се отрази на потребителското преживяване в производствена среда.
Може ли един тестов случай да покрие всичко това? Не съвсем. В зависимост от функционалността, софтуера, системите, нуждите и целите на организацията, екипите за осигуряване на качеството изготвят няколко вида тестови случаи.
Какви видове тестови случаи използват екипите за осигуряване на качеството?
- Функционални тестове за потвърждаване на работата на функциите
- Единични тестове за изолирана логика
- Тестове за сигурност за защита и съответствие
- Тестове за производителност за скорост и мащабируемост
- Регресионни тестове за предотвратяване на повреди
За всеки тип софтуерно тестване има тестов случай. Ето някои от най-често използваните.
Тестов случай за функционалност: Този основен и фундаментален тестов случай оценява дали софтуерът работи според очакванията. Като минимум всеки QA специалист го пише.
Тестови случаи за единични тестове: Единичното тестване оценява част от функционалността или отделна единица. Например, специалистът по осигуряване на качеството може да напише единични тестове, за да провери дали полето за имейл адрес отговаря на различни условия.
Тестови случаи за сигурност: Те оценяват дали дадената функционалност отговаря на стандартите за сигурност, за да премине в производствена среда. Обикновено това включва тестове за оторизация, автентификация, съответствие със стандартите на OWASP и др.
Тестови случаи за производителност: Те потвърждават, че новата функция отговаря на изискванията за скорост, надеждност, мащабируемост и използване на ресурсите.
Тестови случаи за регресионно тестване: Регресионното тестване гарантира, че новата функция, която сте разработили, не засяга никоя от съществуващите функции в продукта.
В допълнение към тях могат да се изпълняват и специфични тестови случаи. Например, организациите, ориентирани към дизайна, могат да включат тестови случаи за потребителския интерфейс [UI]. Продуктите, които изпълняват част от по-голям работен поток, могат да създават много тестови случаи за интеграция. Други могат да създават специфични тестови случаи за използваемост, свързани с хеуристика, достъпност, включване и т.н.
Като продуктов собственик, вие решавате какво трябва да прави вашият софтуер и създавате тестови случаи, приложими към това. Трябва да обхванете всеки сценарий, който е важен за вас.
Означава ли това, че тестовият случай е просто тестов сценарий? Ни най-малко.
Каква е разликата между тестов случай и тестов сценарий?
Тестовият случай е изчерпателен запис на това как трябва да се държи новата ви функция [и как да я тествате]. Тестовият сценарий е описание на високо ниво на действията, които могат да се случат [и следователно да бъдат тествани].
Като разширим предишния пример, тестовият сценарий би бил „тестване на абонамента за бюлетина“. Тестовите случаи обаче биха били:
- Поле за име на теста с приемливо име
- Поле за име на тест със специални символи
- Поле за име на тест за имена на известни личности
- Поле за име на тест с цифри
- Поле за име на теста за заместващо или измислено име, като например Джон Доу
| Тестов случай | Тестов сценарий | |
|---|---|---|
| Дефиниция | Изчерпателна документация за това как да тествате дадена функция | Кратко описание на това как трябва да работи функцията от гледна точка на крайния потребител |
| Ниво | Действия на ниско ниво с детайлна отговорност | Действия на високо ниво с отговорност за цялостната картина |
| Фокус | Как да тествате [подробен запис на предвидената функционалност] | Какво да тествате [кратък списък на очакваните резултати] |
| Източник | Произтичащи от тестови сценарии | Произтичащи от потребителски истории и бизнес сценарии |
| Подход | Обмислете по-широк спектър от възможности и тествайте задълбочено | Имитирайте реални сценарии и тествайте съответно |
Сега, когато знаем разликите, нека отново насочим вниманието си към тестовия случай и го разгледаме по-подробно.
Какво трябва да включва един добре написан тестов случай?
Компонентите на един тестов случай са:
- Уникален идентификатор
- Цел или описание
- Предпоставки
- Стъпки за изпълнение
- Очаквани резултати
- Реални резултати за сравнение
Накратко, тестовият случай е подробна документация на всичко, което трябва да бъде тествано, за да се гарантира, че софтуерът работи според очакванията. Това го прави изчерпателен, детайлен и многостранен, включващ множество компоненти.
Някои от ключовите компоненти на тестовия случай са:
Идентификационен номер на тестовия случай: Всеки тестов случай има номер. Това може да звучи просто, но за да тествате приложението изчерпателно, ще изпълнявате различни тестове, които изглеждат сходни. Идентификационният номер на тестовия случай помага да ги разграничите.
Описание: Описание на това, което тествате. В горния пример това може да бъде: „Добавяне на реални, заинтересовани потенциални клиенти към базата данни на нашия бюлетин.“
Предварителни условия: Всички изисквания, които трябва да бъдат изпълнени за използването на тази функция. Например, по-горе обсъдихме валидирането за всяко поле. В допълнение към това, други условия могат да включват:
- Потребителят не трябва да е абониран вече за бюлетина
- Потребителят не би трябвало да се е отписал от бюлетина
Стъпки: Стъпки, които потребителят или системата трябва да изпълнят, за да завършат оценката и да я отбележат като успешна.
- Потребителят въвежда валидно име
- Потребителят въвежда валиден имейл адрес
- Потребителят отбелязва отметката за поверителност
- Потребителят натиска бутона „Изпрати“
Очаквани резултати: Списък с това, което системата трябва да направи след това.
- Ако потребителското име е невалидно, покажете съобщение за грешка
- Ако имейл адресът е невалиден, покажете съобщение за грешка
- Ако потребителското име и имейл адресът са валидни, запишете ги в съответната база данни
- След като се запише в базата данни, изпратете потвърждаващо имейл на потребителя
Реални резултати: Това са наблюденията на тестиращия след като е изпълнил тестовия случай. Това е информацията, която ще бъде изпратена обратно на разработчика, в случай че нещо не работи правилно.
- Тествах полето за име с Katy P3rry и то беше прието като валиден вход [въпреки че съдържа число]
С това сте готови да пишете ефективни тестови случаи. Ето как.
Как да пишете ефективни тестови случаи с примери
Ето как можете да пишете ефективни тестови случаи:
- Идентифицирайте реални сценарии на употреба
- Определете какво трябва да докаже успехът
- Документирайте ясни, повторяеми стъпки
- Определете резултатите за всяка вариация
- Записвайте състоянията на настройка и последващи действия
Написването на добър тестов случай изисква както бизнес логика, така и технологична проницателност. Трябва да го разберете както от гледна точка на потребителя в реалния свят, така и от технологична перспектива в дигиталния свят. По-долу е представена солидна рамка, която ще ви помогне да започнете това пътуване.
1. Как да определите подходящите тестови сценарии?
Преди да напишете тестови случаи, разберете реалните сценарии, в които ще се използва функцията. Прочетете потребителската история, проучете документа с изискванията или дори обсъдете спецификациите с разработчика.
Например, тестовите сценарии в предишния пример биха били: Потребителят успешно се абонира за бюлетина.
В тази стъпка е важно да се запитате дали документът с изискванията описва потребителя по някакъв конкретен начин.
Например, ако създавате функционалност за бюлетин само за платени клиенти, ще имате сценарий, при който потребители, които не плащат, може да се опитат да се абонират.
Затова прегледайте внимателно изискванията, спецификациите и потребителските истории.
2. Как целите определят вашите тестови случаи?
На този етап определете какво искате да постигнете чрез тестовете. Например, ако просто тествате дали функцията работи според плана, ще напишете функционални тестови случаи.
Ако обаче имате нужда и от сигурност и производителност, ще напишете и съответните тестови случаи. Това ще ви помогне да оптимизирате вашия гъвкав процес на тестване и да представите резултатите пред екипа за разработка.
3. Какво прави тестовите стъпки ясни и повторяеми?
Този етап е нещо повече от просто очертаване на работния процес. Той обхваща всичко, което QA трябва да направи, за да гарантира, че функцията работи както се очаква.
Бъдете изчерпателни: Влизайте в колкото се може повече подробности. Включете какво трябва да се случи въз основа на действието на потребителя/системата. Например, можете да напишете:
- Въведете името в полето за име
- Ако името съдържа цифра, покажете съобщение за грешка: „Моля, въведете име, съдържащо само букви и интервал“
- Ако името съдържа специални символи, покажете съобщение за грешка: „Моля, въведете име, съдържащо само букви и интервал“
- Ако името е заместващ символ, покажете съобщение за грешка: „Моля, въведете валидно име“
- Ако името е валидно, позволете на потребителя да го изпрати
Направете ги многократно използваеми: Повечето функции се припокриват с други функции от миналото. Например, полетата за абонамент за бюлетин може да са сходни с тези за създаване на нови потребителски акаунти. Използвайте ги отново колкото е възможно, за да поддържате последователност и ефективност.
Всъщност можете също да създавате шаблони за документи с изисквания към продукта, които могат да се използват многократно и от които е по-лесно да извличате тестови сценарии и тестови случаи.
Начертайте процеса: При сложни функции може да ви е трудно да документирате всички тестови случаи по линеен начин. В такива случаи опитайте с диаграма на потока.
ClickUp Whiteboards предлага изцяло персонализирано празно платно, на което да визуализирате работния процес на вашите функции. Не се чувствайте принудени да го правите сами. Създайте свои диаграми и ги споделете с всички заинтересовани страни – бизнес анализатори, разработчици, мениджъри по тестване и др. – и си осигурете тяхната подкрепа, преди да започнете!
Определете контекста: Докато тестовият сценарий очертава бизнес контекста, вие трябва да опишете ясно тестовата среда. Включете версията на софтуера, операционната система/браузъра, хардуера, форматите за дата/час, часовата зона и т.н. Също така, добавете линкове към документи и ресурси, които могат да бъдат полезни по време на изпълнението на теста.
4. Как трябва да се дефинират очакваните резултати?
Това е отговорът на въпроса „Какво ще стане, ако...!“ И така, какво ще стане, ако полето за име бъде валидирано? Какво ще стане, ако полето за име не бъде валидирано?
- Какво става, ако потребителят вече е абонат? Трябва ли да отхвърлите абонамента му или да го абонирате отново?
- Ами ако потребителят не е плащащ клиент – трябва ли да го помолите да плати сега?
- Ами ако потребителят вече се е отписал? Трябва ли да проверите отново, преди да го запишете отново?
По този начин очертайте очакваните резултати за всяка възможност. Колкото по-сложна е вашата функция, толкова по-дълъг ще бъде списъкът ви.
5. Защо са необходими пред- и пост-условията?
Днес никоя функция не е изолирана. В разработката на софтуер всяка функция е свързана с нещо друго, което означава, че тестването има редица предварителни и последващи условия.
Примери за предварителни условия
- Трябва да сте плащащ клиент
- Необходимо е да предоставите валидно име и имейл адрес
- Необходимо е да приемете общите условия
- Необходимо е да използвате най-новата версия на Chrome
- Необходимо е да сте влезли в профила си от мобилно устройство
Примери за посткондиции
- Трябва да бъде добавено в базата данни
- Необходимо е да потвърдите абонамента си чрез имейл
- Трябва да бъде добавен към списъка за бюлетина в CRM
Ако сте продуктов мениджър, който иска да се запознае с тестването, ето няколко инструмента без кодиране за продуктови мениджъри.
Това бяха основите, нека преминем към по-конкретните детайли.
Какви са най-добрите практики за писане на силни тестови случаи?
Най-добрите практики за писане на тестови случаи са:
- Мислете от гледна точка на потребителя
- Тествайте по една цел наведнъж
- Използвайте партньорски прегледи, за да откриете слабите места
- Създавайте шаблони за многократна употреба
- Подкрепете работата си с подходящи инструменти
Нека си го признаем: писането на тестови случаи е изкуство. Добрият тестов случай ще открие бъгове и дефекти, които дори не са били предвидени в изискванията. Например, какво ще стане, ако полето за името съдържа две интервали? Или ако фамилията на потребителя съдържа тире?
За да се уверите, че вашите тестови случаи са насочени към създаването на висококачествен софтуер, имайте предвид следните най-добри практики.
🧠 Мислете като потребител
Преди да напишете тестовите си случаи, помислете от гледна точка на потребителя. Бъдете критични и прецизни. В примера, който обсъждахме досега, може да попитате:
- Какво означава „име“? Име? Фамилия? Или и двете?
- Чие име е това? Не би ли трябвало текстът в полето да гласи „вашето име“?
- Трябва ли да има заместващ текст, който да насочва читателя?
- Ако потребителят въведе невалидно име, трябва ли съобщението за грешка да посочи какво не е наред?
Поставете се на мястото на потребителя. Проучете различни възможности и дори крайни случаи. Може да не създадете тестови случаи за всички тях, но проучването им помага за укрепване на функционалността.
🎯 Концентрирайте се върху едно нещо наведнъж
Не пишете функционален тестов случай, който е едновременно и тестов случай за използваемост, и тестов случай за база данни. Правете едно нещо наведнъж. По този начин, когато резултатът от теста е „преминат“ или „непреминат“, ще знаете точно какво е работило и какво не е.
Включването на прекалено много променливи в един тест ще усложни проблемите, когато тестът се провали.
👫 Не го правете сами
Тестовите случаи определят качеството на софтуера. Въпреки че това е проверката в процеса „създател-проверяващ“, тя се нуждае от още едно ниво на преглед от двама души. Затова, след като сте написали тестовите случаи, подложете ги на партньорска проверка.
Помолете колега да прегледа написаното от вас. Насърчете го да открие грешки и да даде критична обратна връзка. Полезно е също да направите това в сътрудничество с бизнес анализатори и разработчици, за да получите по-ясно разбиране за техните намерения.
♻️ Създавайте шаблони за многократна употреба
Сред всички най-добри практики при писането на тестови случаи най-ценната е създаването на шаблони. Независимо дали тествате сходни или напълно различни функции, шаблонът придава структура на вашите мисли. Включете ключови компоненти, механизъм за автоматично номериране или рамка за представяне на всички резултати от тестовете.
Шаблонът за тестови случаи на ClickUp е прост, но мощен пример за това как можете драстично да подобрите ефективността и прозрачността с помощта на повтаряема рамка. Този шаблон за начинаещи е персонализируем, което позволява на вашите екипи да свършат повече работа по-бързо. И още нещо? Можете да използвате този шаблон, за да идентифицирате кандидати за автоматизация и да удвоите усилията си в областта на осигуряването на качеството.
🛠️ Използвайте подходящите инструменти
В екип за разработка на софтуер, писането на изчерпателни тестови случаи за сложни функции може да бъде задача, отнемаща много време. Да не говорим за документирането и организирането им за лесен достъп.
За да направите това, изберете подходящия инструмент.
Кои инструменти помагат на екипите да управляват тестовите случаи ефективно?
Съвременните платформи за осигуряване на качеството свързват планирането, изпълнението, отчитането и автоматизацията, за да поддържат покритие в голям мащаб.
- ClickUp: Обединени задачи, бъгове, автоматизации и шаблони
- TestRail: Структурирано управление на тестовите случаи и проследимост
- BrowserStack: Валидиране на различни устройства и среди
- Jira: Свържете тестването с работните процеси по разработката
Доброто управление на тестовите случаи ви позволява да създавате, организирате, изпълнявате, записвате и наблюдавате това, което тествате. То помага на екипите за тестване да гарантират изчерпателност, без да губят ефективност. Помага на екипите за разработка да виждат ясно бъговете.
Макар ползите да са безкрайни, предизвикателствата също са много. Практическото правило за броя на тестовите случаи на функция е „толкова, колкото са необходими“. В зависимост от функцията, те могат да бъдат два – т.е. един положителен и един отрицателен. Могат да бъдат три, ако тестовият случай е условен. Или могат да бъдат много.
За да се справите с това, се нуждаете от надежден инструмент. Някои от най-добрите съвременни инструменти за QA тестване са:
ClickUp
Ето как ClickUp подобрява управлението на тестовите случаи:
ClickUp за софтуерни екипи е инструмент за управление на проекти „всичко в едно“, създаден да подпомага всеки аспект от инженерния процес. Управлението на тестови случаи не прави изключение.
Написване на тестови случаи: ClickUp позволява на екипите да управляват ефективно своя списък със задачи благодарение на надеждни функции за проследяване на бъгове и проблеми. Управлявайте съществуващите тестови случаи, както и създавайте нови с ClickUp. Използвайте формуляри за софтуерни екипи, за да записвате заявки/бъгове и автоматично да ги превръщате в задачи за екипа.
Видимост за операциите: Можете да го разглеждате като Kanban табло с различни статуси или да използвате календарния изглед, за да ги планирате. Управлявайте задачите на екипа за осигуряване на качеството с изгледа „Работна натовареност“ на ClickUp и преминавайте по-бързо към производствена среда. Използвайте шаблона за проследяване на бъгове и проблеми на ClickUp, за да получите цялостен поглед върху всички аспекти на тестването във вашия софтуерен проект.
Автоматизация в управлението на проекти: Интегрирайте безпроблемно управлението на тестови случаи в процеса на разработване на вашия продукт.
Използвайте ClickUp Automations, за да назначите подходящия тестиращ за всеки тестов случай. Когато QA промени статуса, автоматично го възложете обратно на разработчика за преглед.
С ClickUp за Agile екипи създавайте списъци за проверка, които могат да се използват многократно и да се добавят автоматично към задачите. Настройте ClickUp Brain, за да помогнете на QA екипите да пишат доклади по-бързо.
Вече готови най-добри практики: Използвайте десетките предварително създадени шаблони, за да структурирате процеса си на тестване. Започнете с различните шаблони за тестови случаи или шаблони за докладване на грешки.
След това опитайте шаблона за управление на тестове на ClickUp, за да оптимизирате тестовите си сценарии, тестовите случаи и тестовите цикли. С този шаблон можете да проследявате процеса, да оценявате резултатите и да си сътрудничите с екипа за разработка по отношение на бъгове/проблеми.
За начинаещите този шаблон включва и подробен документ „Как да започнете“, който ще ви преведе през целия процес.
Чудите се как да напишете тестови доклад? Имаме шаблон за вас. Изтеглете и използвайте подходящия за начинаещи шаблон за тестови доклад на ClickUp, за да обобщите резултатите от тестовете си и да ги предадете на разработчиците.
TestRail
TestRail е платформа за управление на тестове, предназначена за документиране и проследяване на тестови планове. Тя включва функции за проследимост, покритие, автоматизация на тестове и анализи. Интегрира се по подразбиране с редица инструменти за разработка на софтуер и предлага обширен API.
BrowserStack
BrowserStack е инструмент за тестване на приложения и браузъри. Той предлага тестване на приложения за iOS и Android, както и на уебсайтове в различни браузъри. Включва специфични модули за визуално тестване, тестване на достъпността, наблюдаемост на тестовете, автоматизация с малко кодиране и други.
Jira
Като един от най-популярните инструменти за гъвкаво управление на проекти, Jira служи и като софтуер за проследяване на бъгове. С Jira можете да създавате тестови случаи, като ги свързвате с потребителски истории, известни бъгове или други проблеми.
Въпреки това, тъй като Jira не е предназначена за управление на тестови случаи, функциите за отчитане и автоматизация може да са ограничени.
Готови ли сте да подобрите процеса си на тестване на софтуер? Изградете го с ClickUp.
В разработката на софтуер тестването играе ключова роля за гарантиране, че всичко е наред. То осигурява 360-градусова поддръжка.
Той валидира работата на екипа за разработка. Потвърждава съответствието с намерението на бизнес екипа. Остава верен на нуждите на потребителя по отношение на функционалност, производителност, сигурност и поверителност.
Управлението на толкова критичен и всеобхватен процес изисква добре обмислен набор от инструменти. Именно това е ClickUp.
Независимо дали следвате Agile, Waterfall или хибриден модел на разработка на софтуер, ClickUp предлага множество функции, проектирани да бъдат лесно персонализирани, за да се адаптират към вашите уникални нужди.
В допълнение към мощното и многостранно управление на задачите, ClickUp включва и набор от тестове, DevOps автоматизации, интеграции и шаблони, които имат голямо въздействие. Вижте сами. Опитайте ClickUp безплатно още днес.