Защо и защо е необходима тестова документация?

Преди много време…

Някъде в младостта си започнах да работя като служител на отдела за тестване в една компания. Там съществуваше тестова документация под формата на контролни списъци в Excel и някои изисквания за 1-2 страници за разработчици, където тестерите понякога можеха да търсят. С течение на времето компанията спря да отделя време за писане на CHL, но документацията за разработчиците все още беше повече или по-малко прилична. Тъй като компанията се занимаваше с обичайното разработване на софтуер за мобилни устройства, оказа се скъпо да поддържате актуалната документация за тестове и като цяло да я създавате за тестери. Спецификацията се превърна в рядкост.

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

- Завършихме да правим покупка на теми в приложението!
- Ad-hoc компилацията вече е сглобена! След час трябва да изложите!
- Също така поправихме критични грешки и поставихме този „gizmo“ в кода.
- Карайте някакъв дим, изведнъж нещо се счупи!
- и т.н.

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

- Слушай, спомня ли си някой какво се е случило тук? Някой знае как трябва да работи?
- Не помня вече. Трябва да попитам разработчиците ...
„Хм ... Мислиш ли, че си спомням какво направих преди три месеца? Имам 5 приложения! Вече не помня къде и какво съм писал някога ...
... (времето изтича)
- Не знам. Ами нека бъде.
- Не повтарям грешката ви. А-а-а-а ... натискате този бутон, когато излизате. И аз винаги натискам, че ...
- Слушай, не помниш ли как проверихме такива абонаменти? И така трябва да бъде? Изглежда, че не трябва да е така ... не помня.

И няма кой да попита. Няма специалисти, които да се занимават с документацията. Тестерите често извършват цялостно тестване на приложението, което отнема много време - цели седмици, понякога и месеци. И на въпроса: "Кога ще приключите с проверката?", Последва отговорът: "Критичните грешки се отървават!" Нямаше ясно разбиране колко време ще отнеме тестването на програмата. А времето, както знаете, е пари. Резултатът беше нещо, което започна да живее свой собствен живот ...

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

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

Ето колко фирми работят. И не всеки получава добри резултати.

Въпреки че горното е неточна история, тъй като са изминали много години и нещо е перифразирано, значението е същото. Има компании, които все още пишат тестова документация и активно я използват. Обикновено това са големи компании, които разработват многофункционални мащабни системи. И има компании, чийто живот може да зависи от качеството и наличността на документацията (например, една компания разработва автопилот за самолет). Разработването на автопилот може да отнеме години, като в крайна сметка го пусне веднъж. Това е много скъп процес. Ако автопилотът има грешки, загубите ще бъдат колосални.

Как гарантирате, че вашият продукт е с високо качество и се продава добре? Трябва да започнете с документация.

Под каква форма и с каква цел е необходима тестовата документация?

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

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

TK (техническа задача) - позволява да предадете същността на предмета на развитие на служителите на компанията. Помага да се разбере какъв вид функционалност трябва да има продуктът в разработка (понякога посочва използваните технологии и методи).

Защо е необходимо?

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

На новите служители няма да е необходимо да се разказва за значението на програмата и методите за нейното изпълнение. Ще бъде възможно бързо да се актуализира всеки човек.

ToR помага на служителите да разберат по-добре програмата. Неразбирането на разработвания продукт води до грешки.

При тестване няма да се правят опити за проверка на ненужни неща. На първо място ще се провери какво задължително трябва да работи според ТЗ.

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

ChTZ (частно техническо задание) - създаден на базата на ТЗ. Обикновено съдържа пълно описание на конкретна част от продукта, който се разработва и VI (случаи на употреба, сценарии за използване на обекта на разработка от потребителите, оформления на разработената част на обекта на разработка, неговата логика и същност).

Защо е необходимо?

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

Помага на новите служители да се ориентират в големи и мащабни проекти, тъй като някои системи отнемат седмици на обучение. Имайки под ръка ChTZ, служител може лесно да намери необходимата информация в него, веднага започвайки тестване. Няма да е необходимо да се включват други служители, които познават продукта, като по този начин ги отвлича вниманието от работата им. Очевидно спестяване на време!

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

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

CHTZ и TK могат да бъдат показани:

в текстова форма със снимки

под формата на графичен шаблон-таблица

под формата на мисловни карти, UML или подобен алгоритъм

Проектна документация, изготвена от изпитатели

CHL (контролен списък) - списък с неща за проверка.

Защо е необходимо?

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

Води история на преминати тестове. Ще бъде лесно да запомните кои тестове са преминали с грешки и да ги проверите отново.

CL с резултатите ясно показва на всеки служител на компанията текущото състояние на разработвания продукт. Помага да се определи неговата готовност.

Помага да се запомни какво вече е проверено и кое не.

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

Контролни списъци могат да бъдат написани:

под формата на таблици (удобно в Google Sheets)

под формата на мисловни карти (удобно в XMind)

под формата на списък с проверки в специално проектирана система (удобно в Sitechco)

като списък в текстов документ, който е познат.

TC (тестов случай) - създаден въз основа на CTZ (ако има такъв) от тестови анализатори и тестери.

Защо е необходимо?

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

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

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

Тестови случаи могат да бъдат показани:

като таблица с текстови данни

в специална услуга за поддържане на тестови случаи (например в TestLink).

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

Защо е необходимо?

Визуално показва какъв резултат се получава от извършената работа.

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

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

Помага да се вземат решения за по-нататъшни действия (например дали си струва да се пусне версия на програмата в текущото й състояние).

Пример за писмен доклад:

Как да определите какъв вид документация трябва да бъде включена в даден проект?

По-долу са дадени примери за това кога и каква документация и инструменти могат да се използват като минимално необходими.

За проект до 15 души (проекти с ниска сложност):

техническо задание (предпазва разработчиците от неразбиране на задачата, тъй като няма документация);

контролни списъци (лесни за поддръжка, без да отнемат много време);

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

За проект от 15 до 50 души (проекти със средна сложност):

база от знания (например в Wiki);

доклади под формата на писмо с приложеното попълнено PM с указание за критични грешки.

Голям проект - от 50 души и повече (проекти с висока сложност):

частно техническо задание;

база от знания (например в Wiki);

доклади във формата, приета от компанията (обикновено под формата на писмо с подробни графици и прикачени файлове);

друго (зависи от вида, целите и нуждите на компанията).

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

Какво да направите, ако писането на документация отнема много време?

Опитът показва, че когато работите по малък проект, трябва да сте гъвкави. Можете да модифицирате документацията, така че нейната поддръжка да е удобна и да не отнема много време. Например ТЗ може да се направи под формата на презентация или уебинар и да се получат уточняващи въпроси от разработчиците. Всеки тип документация има своите плюсове и минуси, така че трябва да експериментирате и да не се страхувате да създадете нещо ново. Всички научни открития се правят чрез проби и грешки и също се случват неуспехи.!
Но отрицателен резултат също е резултат! Трябва да можете да го използвате и да го вземете предвид при по-нататъшните си експерименти, докато се постигне приемлив резултат. Страхотни решения и успех в писането на документация.!