Силната тестова документация е основата на всяка качествена инженерна практика. С Trupeer можете да спестите часове от писането на тестови документи, като започнете с безплатни шаблони за тестова документация, персонализирате ги с вашите brand guidelines и превърнете тестовите планове в видео walkthroughs, които синхронизират инженеринг, продукт и QA.

Какво представляват безплатните шаблони за тестова документация?

Безплатните шаблони за тестова документация са повторно използваеми структури за документите, които се създават при тестова дейност: стратегия, план, тестови случаи, данни, резултати и доклади за дефекти.

Повечето търсения за тях всъщност са търсения на един документ. Тестовите случаи са това, за което тестерите прекарват времето си, а шаблонът за тестов случай е таблица със стъпки в нея — което не е трудно.

Проблемът не са шаблоните. Всеки публикуван шаблон за тестов случай има едни и същи колони: идентификатор, заглавие, предпоставки, стъпки, очакван резултат, реален резултат, статус. Тази структура е правилна и е стабилна от десетилетия.

Неправилното в повечето тестови набори е балансът на усилието в рамките на тази структура и това води до тестови случаи, които могат да минават, докато системата е повредена.

Форматът следва употребата. Безплатното изтегляне на Excel шаблон за тестови случаи е най-често работещият формат и пасва добре на таблицата със случаи. Word файлът с шаблон за тестов случай пасва на тестови планове и стратегии, които са текст. Примерен PDF документ за тест е това, което се прикачва към запис за пускане като доказателство.

Документите в един тестов набор

Шест документа, всеки отговаря на различен въпрос, и си струва да знаете кои реално ви трябват, преди да приемете каквото и да било.

Тестова стратегия. Как тази организация тества като цяло. Писана веднъж, ревизирана рядко, прилагана във всички проекти.

Тестов план. Какво ще се тества при това пускане или проект, в кои среди, от кого, с какви критерии за вход и изход и какъв график.

Тестови случаи. Отделните проверки. Стъпки и, най-важното, очаквани резултати.

Тестови скриптове. Автоматизираният еквивалент, при който даден случай е кодиран, вместо да се изпълнява от човек.

Тестови данни. Какви данни се използват за изпълнение на случаите — документация сама по себе си и често най-слабо контролираният елемент от целия набор.

Тестови резултати и доклади за дефекти. Какво се е случило и какво е било повдигнато. Това е, което обикновено се оказва примерният PDF документ за тестов случай, когато намерите публикуван такъв, тъй като резултатите са частта, която организациите запазват.

Всеки пакет с шаблони за тестова документация трябва да покрива и шестте, а повечето покриват две. Повечето организации имат третия и шестия и импровизират останалите. Това е преживяемо. Непреживяемото е третият да е написан лошо, защото всичко надолу по веригата зависи от него.

Как да персонализирате този шаблон в Trupeer

Стъпка 1: Отворете секцията Templates

Отидете в секцията Templates от главната навигация.

Стъпка 2: Изберете и отворете шаблон

Кликнете върху който и да е шаблон, с който искате да работите, за да го отворите.

Стъпка 3: Разгънете изгледа на шаблона

Ако е нужно, разгънете изгледа на шаблона, за да видите пълната структура и детайлите ясно.

Стъпка 4: Редактирайте шаблона

Кликнете върху Edit, за да започнете да променяте избрания шаблон.

В редактора можете да:

• Добавяте нови секции

• Дефинирате или актуализирате правила за форматиране

• Добавяте лого и настройвате позицията му и свързаните настройки

Стъпка 5: Запазете персонализирания си шаблон

След като направите всички необходими промени, кликнете върху Save, за да запазите обновения шаблон като свой.

Стъпка 6: Прегледайте и фино настройте шаблона

Когато искате да видите как изглежда вашият персонализиран шаблон, отворете Preview.

От екрана за преглед можете да продължите да правите корекции директно, ако е нужно, като гарантирате, че шаблонът изглежда точно както искате.

С шаблони за тестова документация можете да:

• Спестите часове от писане: Пропуснете празната страница със структури, използвани от опитни QA екипи.

• Подобрите покритието на тестовете: Вградените секции гарантират, че нищо важно няма да бъде пропуснато.

• Останете в бранд стила: Приложете логото, шрифтовете и цветовете си с brand kit-а на Trupeer.

• Стандартизирайте в продуктите: Използвайте едни и същи шаблони за всяко пускане и всеки екип.

• Бъдете готови за одит: Съответствие с IEEE 829, ISO 29119 и подобни стандарти.

• Достигнете до глобални екипи: Превеждайте тестова документация на 65+ езика с едно кликване.

Очакваният резултат е тестовият случай

Прочетете всеки тестов набор и вижте къде са думите.

Стъпките ще бъдат подробни. Отворете приложението. Навигирайте до екрана за плащания. Изберете транзакцията. Кликнете Refund. Въведете сумата. Потвърдете. Седем точни инструкции, всяка без двусмислие.

След това погледнете очаквания резултат. Той ще казва нещо от типа: възстановяването е обработено успешно.

Този ред е целият тест. Всичко над него е подготовка. И именно редът, който е получил най-малко мисъл, защото писането на точни стъпки е лесно, а дефинирането на това какво означава „правилно“ е трудно.

Последицата е, че тестерът следва седем точни инструкции, вижда нещо, което изглежда като успех, и отбелязва „преминава“. Не са направили нищо нередно. Документът е питал дали възстановяването е обработено успешно, те са видели съобщение за успех и то е било така.

Това, което документът никога не е питал, е дали е създадено точно едно възстановяване, дали главната книга е преместена с точно правилната сума, или дали някой елемент по веригата е получил дубликат.

Тестов случай, чийто очакван резултат може да бъде удовлетворен от оптимистично тълкуване на интерфейса, е тестов случай, който ще минава винаги, когато тестерът е в бързане — а това е най-често около пускане.

Писане на очакван резултат, който може да се провали

Три свойства и те са лесни за проверка в съществуващ набор.

Посочва състояние, а не впечатление. Не „записът се запазва правилно“, а „записът се появява в списъка със статус Active и модифициран timestamp в рамките на последната минута“.

Проверяемо е извън нещото, което е извършило действието. Това е свойството, което улавя скъпите дефекти. Ако действието се е случило в потребителския интерфейс, най-силният очакван резултат е проверка някъде другаде: в базата данни, в отчет, в системата по веригата, в извлечение. Интерфейсите са добри в отчитането на успех и лоши в отчитането на това, което реално се е случило отдолу.

Може да се провали, без системата да изглежда повредена. Ако единственият начин тестът да се провали е видима грешка, тестът открива само грешки, които се обявяват. Тиха неправилност е това, за което съществуват тестовите случаи, и това, което неясните очаквани резултати пропускат надеждно.

Практически одит, който отнема следобед върху набор от няколкостотин. Прочетете само очакваните резултати, игнорирайки стъпките. Пребройте колко биха могли да бъдат удовлетворени само като гледате екрана и колко използват думи като „правилно“, „успешно“, „както е очаквано“ или „без грешка“, които изобщо не са резултати. В повечето набори и двата броя са високи.

Какво трябва да съдържа шаблонът за тестов случай

Девет полета. Шаблонът не е проблемът и указанията срещу две от тези полета са.

Разграничението между blocked и not run е по-важно, отколкото изглежда. Набор, който отчита деветдесет процента pass, може да е изпълнил само шейсет процента от случаите си, а разликата е невидима, ако всичко, което не е преминало, е записано по един и същи начин.

Безплатни шаблони за тестова документация: структурата, която да копирате

Попълнени с реален пример, а не с плейсхолдъри. Системата е платформа за обработка на плащания.

Копирайте оттук.

Тестов план, в общ план. Обхват: обработка на възстановявания за пускане 4.9. В обхват: пълни възстановявания, частични възстановявания, възстановявания спрямо разплатени и неразплатени транзакции. Извън обхват: chargebacks, които не са променени. Среда: staging с обеми данни, подобни на production. Критерии за вход: build е разположен, smoke test е преминал, тестовите данни са заредени. Критерии за изход: всички случаи с приоритет one са преминали, няма отворени дефекти с приоритет one или two, корекцията на главната книга е чиста за целия цикъл.

Тестов случай.

Идентификатор: TC-118. Заглавие: Пълно възстановяване спрямо разплатена транзакция създава точно един запис за възстановяване.

Приоритет: One.

Предпоставки: Съществува merchant account M-4471 с разплатена транзакция T-88210 на 240.00. Балансът на главната книга за M-4471 е записан преди старта. Тестерът има разрешение за възстановяване.

Стъпки.

1. Отворете екрана за плащания и потърсете T-88210.

2. Изберете транзакцията и изберете Refund.

3. Въведете 240.00 и потвърдете.

Очакван резултат. Четири условия, всички от които трябва да са изпълнени.

Съществува един запис за възстановяване спрямо T-88210 и само един. Проверено в таблицата refunds, а не в интерфейса.

Балансът на merchant ledger за M-4471 е намалял точно с 240.00 спрямо записаната стойност при старта. Проверено в ledger report.

Извлечението на merchant за периода показва един ред за възстановяване на 240.00.

Статусът на транзакцията показва Refunded в интерфейса.

Забележете, че проверката в интерфейса е последна и е най-слабата от четирите. Включена е, защото потребителите я виждат, а не защото проверява нещо.

Реален резултат: записан при изпълнение, като стойностите от главната книга са наблюдавани, а не приемани.

Статус: pass, fail, blocked или not run.

Доказателства: изход от заявка от таблицата refunds и копие от реда в ledger report.

Доклад за дефект, ако не успее. Идентификатор на случая, какво е било очаквано, какво е било наблюдавано, среда, build, използвани данни, стъпки за възпроизвеждане, тежест. Полето за използвани данни е най-често пропусканото и най-често предотвратява възпроизвеждането.

Копирайте оттук.

Пример за тестова документация: триста и тридесет и осем преминавания

Brayford Payments обработва плащания с карти за малки търговци и наема около двеста души. Пусна ревизиран flow за възстановявания.

Модулът за плащания имаше триста и четиридесет тестови случая. User acceptance testing пусна целия набор. Триста и тридесет и осем преминаха. Два не успяха, бяха поправени и повторно тествани.

В production възстановяванията над определена стойност се прилагаха два пъти при конкретно условие за време. Работи девет дни, преди някой да забележи, като генерира около четиринадесетстотин дублирани възстановявания на стойност четиристотин и дванадесет хиляди паунда. Възстановяването на пари, които вече са платени на търговците, беше бавно и неудобно, и приблизително шейсет процента се върнаха.

Случай TC-118 покриваше възстановявания. Той имаше седем подробни стъпки и очакван резултат, който гласеше: възстановяването е обработено успешно.

Тестерът изпълни и седемте стъпки, видя съобщение за потвърждение и статус Refunded и записа pass. Това беше правилното прилагане на документа пред тях.

Никой не погледна главната книга. Нищо в случая не ги караше да го направят. Едно възстановяване и двойно възстановяване изглеждат идентично на екрана за потвърждение — точно затова проверката трябваше да се случи някъде другаде.

Последващият одит прочете всички триста и четиридесет очаквани резултата, игнорирайки стъпките.

Двеста и единадесет можеха да бъдат удовлетворени само като се наблюдава потребителският интерфейс. Четиридесет и седем не съдържаха изобщо проверяемо твърдение, използвайки фрази като works as expected, behaves correctly или completes without error.

Решението беше три седмици пренаписване, а не ново тестване. Всеки очакван резултат трябваше да назове състояние, да каже къде е проверено и да може да се провали без видима грешка. Когато естествената проверка беше извън интерфейса, там и отиваше. Някои случаи се сляха и наборът се сви до двеста и деветдесет.

Два пуска по-късно дефектите, открити по време на user acceptance testing, паднаха от средно четири на пускане до деветнадесет.

Това нарастване е резултатът. Дефектите в production през следващите шест месеца паднаха от единадесет до две.

Наборът не беше твърде малък. Той задаваше триста и четиридесет въпроса, на които системата можеше да отговори оптимистично.

Как да пишете тестови случаи в шест стъпки

1. Запишете очаквания резултат преди стъпките. Това обръща обичайния ред и ви принуждава да решите какво означава „правилно“, преди да опишете как да стигнете до него. Стъпките, написани след това, са по-кратки и по-подходящи.

2. Кажете къде се проверява резултатът. Интерфейс, база данни, отчет, система по веригата. Назоваването на локацията е това, което прави резултата проверяем от някой друг.

3. Попитайте как това може да минава, докато е грешно. Ако можете да отговорите, очакваният резултат се нуждае от още едно условие.

4. После запишете стъпките, по едно действие във всяка. Те са лесната част и трябва да отнемат най-малко време.

5. Запишете предпоставките, включително данните. Повечето провали да се възпроизведе дефект се свеждат до различни данни, а не до различни стъпки.

6. Приоритизирайте честно. Никой не пуска целия набор преди пускане. Да решите предварително кои случаи имат значение е по-добре, отколкото да решите в девет вечерта в деня преди това.

Първата стъпка е целият метод. Втората и третата стъпка улавят дефектите, които стигат до production.

Тестови случаи срещу тестови сценарии

Двете се използват взаимозаменяемо и разликата е нивото.

A test scenario е какво да се тества, описано на ниво, което всеки може да разбере. Проверете дали възстановяванията работят правилно за разплатени транзакции. Това е твърдение за покритие.

A test case е как да го тествате, със специфични данни, специфични стъпки и конкретен очакван резултат. Един сценарий обикновено генерира няколко случая.

Полезната дисциплина е да пишете сценарии първо, да се договорите за покритието спрямо тях с хора, които разбират бизнеса, и след това да пишете случаите отдолу. Ако го направите по обратния начин, получавате набор, който покрива всичко, за което човекът, който го е написал, се е сетил.

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

Тестова стратегия, тестов план и QA план

Трите документа над тестовите случаи и разграниченията имат практическа тежест.

A test strategy е организационна и дългоживееща. Как тестираме, какви типове тестване използваме, какви са нашите стандарти. Прилага се във всички проекти и се ревизира рядко.

A test plan е специфичен за пускане или проект. Обхват, среди, критерии за вход и изход, график, ресурси, рискове. Шаблон Excel за тестов план безплатно изтегляне ще ви даде график и матрица, а текстовите секции принадлежат в документ.

A QA plan е по-широк от двете, защото осигуряването на качеството включва всичко, което се прави, за да се предотвратят дефекти, а не да се открият: преглед на изискванията, дефиниция на done, стандарти за code review, съответствие на средите. QA plan template покрива това разграничение и има значение тук, защото документ, озаглавен QA plan, който съдържа само тестови фази, тихомълком се е превърнал в тестов план.

Практическият тест е времето. Дейности, които се случват преди да е свършена работата, са гаранция. Дейности, които се случват след това, са контрол, а тестването е контрол.

Какво не могат да поправят безплатните шаблони за тестова документация

Изисквания, по които никой не се е договорил. Тестовият случай проверява поведение спрямо очакване и когато очакването никога не е било уточнено, тестерите пишат случаи спрямо собственото си предположение за него.

Набор, който е твърде голям за изпълнение. Всяка организация стига до точката, в която пълният регресионен набор не се побира в прозореца. Да приоритизирате съзнателно побеждава приоритизирането под натиск и нито един шаблон за тестови случаи Excel free download няма да го направи вместо вас.

Неясен очакван резултат. Нито един шаблон за тестов случай: безплатно изтегляне и без прост шаблон за тестов случай Excel layout няма да го напише вместо вас, и това е единственото поле, което решава дали случаят работи.

Тестови данни, които не представят production. Дефектът на Brayford изискваше конкретно условие за време и реалистичен обем данни. Нито едното, нито другото съществуваше в тестовата среда и нито един шаблон не адресира това.

Тестери без правомощия да блокират. Критерии за изход, които могат да бъдат отменени от който иска да пусне, не са критерии.

Показвайте теста, вместо да го описвате

Два проблема в тази област са един и същ проблем и и двата са за доказателства.

Тестовото доказателство обикновено е отметка в колона със статус. Някой е пуснал случая и казва, че е преминал. Ако по-късно в тази област се появи дефект, няма начин да се установи какво реално е наблюдавано, така че въпросът дали случаят е изпълнен правилно не може да се отговори и обикновено се превръща в спор.

Вторият проблем е, че нов тестер, който се присъединява към екип, научава какво означава правилна проверка, като гледа някого, и ако никой няма време, го научава от документите — там идва и оптимистичното тълкуване.

Trupeer AI адресира и двете. Записването на изпълнение на тест създава писмен walkthrough с вече заснети и поставени екрани, заедно с видеото, във вашия собствен бранд. Това, което реално е наблюдавано във всяка стъпка, се улавя, вместо да се твърди, и това е доказателството, от което се нуждае записът за пускане, и материалът, от който новият тестер се учи.

Запишете го. Брандирайте го. Преведете го. Trupeer it.

Следват две точки. Записването на опитен тестер, който изпълнява сложен случай, показва проверките, които прави извън интерфейса — точно навикът, който писмените случаи не успяват да предадат. И когато тестването се извършва в различни локации или от аутсорсван екип, същият запис дефинира същия стандарт за проверка, вместо да го оставя на тълкуване.

Материалът стои във вашата knowledge base и служи и като training за нови тестери. Дали пускането може изобщо да се случи, е отделен въпрос, покрит в release requirements template. Последователността във вашите документи е въпрос на настройване на brand kit веднъж и настройката е покрита в document template setup guide.

Често задавани въпроси

Има ли безплатно изтегляне на Excel шаблон за тестови случаи?

Excel е стандартният работещ формат за тестови случаи и им подхожда добре, защото наборът е таблица, която филтрирате по модул, приоритет и статус. Безплатното изтегляне на Excel шаблон за тестови случаи ще ви даде стандартните колони и е наистина добър старт.

Заслужават си две допълнения. Колона, която записва къде се проверява очакваният резултат, т.е. интерфейс, база данни, отчет или система по веригата. И отделни стойности за статус за blocked и not run, тъй като сливането им скрива колко от набора реално е изпълнен.

Има ли проста версия на Excel за шаблон за тестов случай?

Да, и простото обикновено е правилното. Прост Excel layout на шаблон за тестов случай с идентификатор, заглавие, приоритет, предпоставки, стъпки, очакван резултат, реален резултат и статус покрива почти всичко.

Устоявайте на добавянето на колони. Шаблоните за тестови случаи натрупват полета, които изглеждат полезни на етапа на дизайн, и се оставят празни на практика, а набор с осем попълнени колони е по-полезен от набор с двадесет, от които дванадесет са празни.

Има ли версия на Word за шаблон за тестов случай?

Word пасва на околните документи, а не на самите случаи. Word файл с шаблон за тестов случай работи за тестов план, тестова стратегия или обобщен отчет, които са текст.

За самите случаи документът не е добър вариант. Не можете да го филтрирате, не можете да сортирате по приоритет и актуализирането на статуси за двеста случая в Word таблица по време на тестов цикъл е достатъчно бавно, че хората спират да го правят точно.

Има ли шаблон за тестов случай: безплатно изтегляне, което си струва да се използва?

Колоните са стабилни от десетилетия, така че шаблон за тестов случай: безплатно изтегляне ви спестява много малко и всяка публикувана версия е като цяло една и съща.

Оценете всеки от тях по един въпрос. Има ли указания, прикрепени към колоната за очакван резултат, или това е просто празна клетка? Празната клетка е мястото, където повечето тестови набори грешат, и нито един шаблон не го решава, но шаблон, който подканва къде се проверява резултатът, ще подобри това, което се записва в нея.

Има ли безплатно изтегляне на Excel шаблон за тестов план?

Excel пасва на графика, матрицата за покритие и плана за ресурси в рамките на тестов план. Безплатното изтегляне на Excel шаблон за тестов план обикновено ще ви даде това.

Текстовата част принадлежи в документ: обхват, критерии за вход и изход, среди, допускания и рискове. Те се четат и договарят, а договарянето в клетки на spreadsheet върви зле. Запазете и двете и реферирайте едното от другото.

Къде мога да намеря примерен PDF документ за тест?

Публични записи за обществени поръчки, университетски проекти и някои стандартизиращи органи публикуват реална тестова документация, а примерен PDF документ за тест от някой от тези източници е по-информативен от търговски шаблон, защото е създаден при реални ограничения.

Прочетете примерен PDF документ за тестов случай за очакваните резултати, а не за структурата. Структурата може да се пренесе от всякъде. Как реалният екип е формулирал какво означава „правилно“ и дали техните проверки са извън интерфейса — това е частта, която си струва да научите.

Къде мога да намеря примерен PDF документ за тестов случай?

Същите източници важат и тук, а регулираните индустрии са най-богатите, тъй като там тестовите доказателства трябва да оцелеят при одит и обикновено са написани по-точно в резултат.

Когато четете примерен PDF документ за тестов случай, вижте дали колоната за реален резултат съдържа наблюдения или отметки. Отметките ви казват, че наборът е пуснат. Наблюденията ви казват какво е било видяно и само второто е доказателство.

Има ли комплект шаблони за документация за софтуерно тестване?

Да, комплектът е от шест документа: стратегия, план, случаи, скриптове, данни и резултати с доклади за дефекти. Комплект шаблони за документация за софтуерно тестване обикновено покрива плана и случаите и оставя останалото.

Тестовите данни са най-често липсващото и най-често предотвратява възпроизвеждането на дефект. Документирането на това какви данни използва наборът и как се обновяват си струва колкото още петдесет тестови случая.