Компютърни тестове, най-добри практики

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

Малко заобикаляне през теорията

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

Четири основни нива на тестване може да се изчисти:

Единични тестове: те имат за цел да проверят функционалността на определен раздел от кода, независимо един от друг. Следователно потенциално ще идентифицираме дефект на определено място.
Интеграционни тестове: След като бъдат проведени модулните тестове, това включва тестване на системата като цяло, тоест чрез интегриране на всички нейни компоненти. Възможни са два варианта, в режим на компонент по компонент или в режим „голям взрив“.
Тестове на системата: целта на тази фаза е да се провери дали разработката работи правилно на теория, но също така и в контекста, даден от потребителя.
Тестове за приемане които се стремят да валидират развитието между различни проектни екипи (MOE => MOA), а след това и с потребители.

В рамките на тези различни нива са различни видове тестове. Можем да цитираме най-често срещаните:

И на практика какво дава ?

Необходимостта от стратегия и план за изпитване от фазата на разработка

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

A fortiori, използването на количествени тестове дава възможност да се идентифицират екстремни или гранични случаи. Ако изчислението изисква например цената на изпълнение, какво ще стане, ако е отрицателна? Трябва ли да осигуря мантинела, ако е гадна? По този начин избягваме риска да задаваме тези въпроси в следващите фази, където разходите за коригиране на грешки могат да бъдат по-високи (особено при управление на V-цикъл, по-малко при Agile).

В този смисъл, така наречените методи за „непрекъснато тестване“ (Test Driven Development, Behavior Driven Development), които комбинират както кодиране, така и автоматични тестове в строителния процес, осигуряват голямо предимство: незабавно откриване на грешки чрез едновременно тестване на техническите и функционалните части. Времето се спестява, а времето е пари.

Значението на планирането

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

Различните фази на теста се припокриват помежду си, така че не можем да преминем към фаза, без да сме проверили предишната, което се разбира от само себе си. Без изпитване от край до край преди тестове за дим, - извика маршал Ла Палис! По-конкретно обаче трябва да се обърне специално внимание на последователността на тези тестове, както и на съответната им продължителност. Колко трудно е дадено упражнение, толкова трудно е оценката на натоварването, специфично за всеки проект. Непредвидено събитие, което никога не може да бъде изключено, откриването на проблем понякога може да доведе до появата на много други, по-многобройни и по-сериозни за коригиране. След това малката буболечка изведнъж се превръща в мравуняк, където много други малки звяри чакат тихо, приклекнали в сенките, готови да изплуват веднага щом един от тях бъде открит. За да се избегне каквото и да е въздействие върху следващите фази и датата на производство, силно се препоръчва да си дадете марж от около 10% от общото очаквано натоварване, само за да се чувствате комфортно, ако възникне неочакван елемент.