Тестова документация при тестване на софтуер (пример)
⚡ Умно обобщение
Тестовата документация определя структурирани артефакти, създадени преди или по време на тестване на софтуер. Тя подпомага планирането, изпълнението, tracнадеждност и осигуряване на качество чрез документиране на цели, стратегии, тестови случаи и резултати. Ефективната документация подобрява обхвата, прозрачността и повторяемостта в различните проекти.

Какво е тестова документация?
Тестовата документация е документация на артефакти, създадени преди или по време на тестването на софтуер. Тя помага на екипа за тестване да оцени необходимите усилия, track ресурси и напредък, както и да се осигури адекватно тестово покритие. Записът и докладите от теста са пълен набор от документи, които ви позволяват да опишете и документирате планирането на теста, дизайна на теста, изпълнението на теста и резултатите от теста, извлечени от тестовата дейност.
👉 Запишете се за безплатен проект за тестване на софтуер на живо
Защо е необходима формалност на теста?
За начинаещ е лесно да се предположи, че тестването е изпълнение на различните части от кода на ad-hoc база и проверка на резултатите. Но в реалния свят тестването е много формална дейност и е документирана подробно. Тестовата документация прави планирането, прегледа и изпълнението на тестването лесно, както и проверимо.
Степента на формалност на теста зависи от:
- Типът на тестваното приложение (AUT).
- Стандарти, следвани от вашата организация.
- Зрелостта на процеса на развитие.
Тестовите дейности обикновено отнемат между 30% и 50% от общите усилия за разработване на софтуер. Документацията помага за идентифициране на подобрения в процеса на тестване, които могат да бъдат приложени в бъдещи проекти.
Какви са видовете тестова документация?
Ето важните видове тестова документация:
„На практика тези документи се създават на различни етапи — от ранно планиране (политика за тестване, стратегия) до изпълнение и приключване (доклади за дефекти и обобщени доклади).“
| Видове документи за изпитване | Descriptйон |
|---|---|
| Тестова политика | Това е документ на високо ниво, който описва принципите, методите и всички важни цели за тестване на организацията. |
| Тествайте стратегия | Документ на високо ниво, който идентифицира нивата (типовете) на тестове, които ще бъдат изпълнени за проекта. |
| План за тестване | Планът за тестване е пълен документ за планиране, който съдържа обхвата, подхода, ресурсите, графика и др. на дейностите по тестване. |
| Изисквания TracМатрица на възможностите | Това е документ, който свързва изискванията с тестовите случаи. |
| Сценарий на теста | Сценарий на теста е елемент или събитие на софтуерна система, което може да бъде проверено чрез един или повече тестови случаи. |
| Тестов случай | Това е група от входни стойности, предварителни условия за изпълнение, очаквани постусловия за изпълнение и резултати. Разработена е за тестов сценарий. |
| Данни от теста | Тестовите данни са данни, които съществуват преди изпълнението на теста. Те се използват за изпълнение на тестовия случай. |
| Доклад за дефект | Докладът за дефект е документиран отчет за всеки недостатък в софтуерна система, който не успява да изпълнява очакваната си функция. |
| Обобщен доклад от теста | Обобщаващият доклад за теста е документ на високо ниво, който обобщава проведените тестови дейности, както и резултатите от тестовете. |
Кои са най-добрите практики за постигане на тестова документация?
В този раздел ще научим за най-добрите практики, които помагат за постигане на тестова документация с примери, които ще ви помогнат да я разберете по-добре:
- Включете QA в началото на проекта: Включете екипа по QA от самото начало на проекта, така че тестовата документация да се разработва успоредно с дизайна на продукта и изискванията.
Пример: QA сътрудничи по време на планирането на спринта, за да изготви първоначални тестови случаи въз основа на потребителски истории. - Поддържайте документите актуални: Не създавайте просто тестови документи и ги забравяйте — актуализирайте ги всеки път, когато изискванията или функциите се променят.
Пример: Когато API за вход се промени, незабавно актуализирайте свързаните тестови случаи и резултати. - Използвайте контрол на версиите: Управление и tracда се проверяват всички промени в тестовите документи чрез системи за контрол на версиите, за да се избегне объркване и загуба на данни.
Пример: Съхранявайте тестовите планове в GitHub, за да поддържате ясна история на версиите и опции за връщане към предишни версии. - Документ за яснота и цел: Записвайте само това, което помага на вас и вашите заинтересовани страни да разберат напредъка на тестването и резултатите.
Пример: Включете обобщени отчети за тестове, подчертаващи преминали, неуспешни и блокирани тестови случаи за преглед от ръководството. - Използвайте стандартни шаблони: Следвайте последователен формат — например шаблони на Excel или Word — за да улесните създаването и прегледа на документацията.
Пример: Използвайте стандартен „Шаблон за тестов случай“ с полета за идентификатор, описание, предварителни условия и очаквани резултати. - Централизирано съхранение на документи: Съхранявайте всички документи, свързани с проекта, на едно достъпно място, за да могат членовете на екипа лесно да ги преглеждат или актуализират.
Пример: Съхранявайте тестовите артефакти в споделен Google Drive папка, достъпна за целия екип по QA и разработка. - Включете достатъчно подробности: Избягвайте неясна или непълна информация; подробната документация подобрява разбирането и намалява грешките по време на изпълнение на теста.
Пример: Вместо „Проверка на входа“, напишете „Проверката на потребителския вход с валидни идентификационни данни пренасочва успешно към таблото за управление“.
Кога трябва да създадете тестова документация за тестване на софтуер?
Ето някои от ключовите моменти относно това кога трябва да създавате тестова документация за тестване на софтуер:
- Фаза на планиране: Преди да започне изпълнението на теста, е необходимо ясно да се дефинират обхватът, целите и стратегията за тестване.
- Подготовка на теста: По време на планирането на тестовете, за да се установят ефикасно срокове, ресурси и изисквания към средата.
- Анализ на изискванията: След анализа на изискванията, да се осигури пълно покритие на функционалните и нефункционалните спецификации.
- Стандартизация на дизайна: Преди да се проектират тестови случаи, за да се стандартизират форматите и да се поддържат tracлеснота във всички документи.
- Документация за сценария: По време на проектирането на теста, за документиране на сценарии, входни данни, очаквани резултати и подробности за тестовите данни.
- Готовност за изпълнение: Преди изпълнение на теста, да се провери готовността на тестовата среда, инструментите и точността на документацията.
- Оценка на публикацията: След тестване, да се запишат резултатите, дефектите и извлечените поуки за подобряване на процеса.
Какви видове шаблони са необходими за тестова документация?
Ето някои от шаблоните, които са ви необходими за тестова документация при тестване на софтуер:
| Име на шаблона | Инструменти |
|---|---|
| Шаблон за тестов план | Microsoft Word, Google Docs или Confluence за съвместно редактиране и контрол на версиите |
| Шаблон за тестов случай | TestRail, Зефир (в JIRA), Xrayили Excel/Google Таблици за структурирано управление на тестовете |
| Шаблон за тестов сценарий | JIRA, TestLink или Google Листове за документиране на условията на тестване на високо ниво |
| Изискване TracШаблон за матрица на ефективността (RTM) | Excel, Google Листове или TestRail за картаping изисквания към тестовите случаи |
| Шаблон за доклад за дефекти | ДЖИРА, Bugzilla или Azure DevOps за регистриране на дефекти и tracцар |
| Шаблон за обобщен отчет на теста | Сливане, Google Docs, или TestRail за събиране на резултати от тестове и анализ |
Плюсове и минуси на тестовата документация
Предимства
- Основната причина за създаването на тестова документация е да се намалят или премахнат всякакви неясноти относно тестовите дейности. Това помага за премахване на неяснотите, които често възникват, когато става въпрос за разпределение на задачите.
- Документацията не само предлага систематичен подход към тестване на софтуер, но също така действа като обучителен материал за новокурсниците в процеса на тестване на софтуера.
- Това служи като добра маркетингова и търговска стратегия за представяне на тестова документация, за да се демонстрира зрял процес на тестване.
- Тестовата документация ви помага да предложите качествен продукт на клиента в рамките на определени срокове.
- In Софтуерно инженерство, тестовата документация също помага за конфигурирането или настройването на програмата чрез документа за конфигурация и ръководствата за оператора.
- Тестовата документация ви помага да подобрите прозрачността с клиента.
Недостатъци
- Цената на документацията може да надхвърли нейната стойност, тъй като отнема много време.
- Много пъти се пише от хора, които не могат да пишат добре или не познават материала.
- Keeping tracПреброяването на много промени, поискани от клиента, и актуализирането на съответните документи е изморително.
- Лошата документация директно отразява качеството на продукта, тъй като може да възникне недоразумение между клиента и организацията.
Често срещани грешки, които трябва да се избягват в тестовата документация
Ето най-често срещаните грешки, които трябва да избягвате в тестовата документация:
- Избягвайте да пишете неясни или двусмислени описания на тестови случаи.
- Не пропускайте документирането на предварителните условия и зависимостите на теста.
- Никога не забравяйте да включите очакваните резултати за всеки тест.
- Избягвайте непоследователно форматиране в различните тестови документи.
- Не използвайте неясни или неизмерими цели на теста.
- Никога не пропускайте контрола на версиите за актуализации на тестовата документация.
- Избягвайте дублирането на информация в множество тестови артефакти.
- Не пренебрегвайте проверката на документацията за точност и пълнота.

