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