Докато подготвя следващата публикация от поредицата за автоматизация. Исках да споделя някои интересни, по мое мнение, материалът от книгата Agile тестване: Практическо ръководство за тестери и пъргав отбори.
Така че, видове тестове е много, много: натоварване, повод, здрав разум, черна кутия, бяла кутия, и така нататък. Дълго време не съм виждал по-добър и ясен, по мое мнение, системата, която ще съдържа нормалната група на всички тези видове, както и да даде обяснение за това кога и защо трябва да се наложи да ги използвате. И съвсем наскоро прочетох за Agile тестване квадранти (ATQ), за което искам да кажа.
Всъщност самата система изглежда така:
Както може да се види, класическата фигура 2 * 2. Така че, на една от осите на тестовете са разделени на бизнес ориентирани и ориентирани към технологиите, другата ос - за тестове, за да подкрепят отбора и за "Продукт на критика." Само искам да отбележа, че номерацията не казва нищо за това, кога трябва да се проведат тези тестове.
Нека да мине през всеки един от секторите.
Сектор Q1 представлява практика, известна като TDD. Това е проста: Първите тестове, след което код. Тези тестове са преди всичко отговорност на екипа за развитие. Всички тези тестове трябва да се минава през ПО, както за постоянно качество за проверка на код. Всичко това е боядисан в много източници, за тези, които не са практикували TDD, искам да предложа тук е връзката.
Q2 сектор съдържа тестове по-високо ниво, които вече са свързани с бизнеса. Успешното преминаване на тези тестове е задължително да се говори за края на функционален. Тъй като може да се каже, че този или тази функционалност е направена, когато той решава един набор от нужди на бизнес потребителите. На това ниво, най-вече тества на външната обвивка на заявлението: на интерфейс, API, уеб услуги, и така нататък. От друга страна, този сектор включва изпробване на прототипи, макети, проектиране и така нататък. Често, за да се позовава на опитите, които се възползват от тестовете за дългосрочно приемане. въпреки че това не е съвсем вярно, тъй като тестовете на сектори Q3 и Q4 също отнесени към тестване на приемане.
Тестовете на Q3 сектор включват задължително участие на експерти в областите на домейни на експерти използваемост, потребители, и така нататък. Това често се случва, че функционалността се реализира в действителност не се реши проблема на клиента, или че нещо е погрешно развитие на екипа. Отново, това би могло да бъде нови аспекти на работата с обекти или домейн разкриха, че предназначен интерфейсът не е удобно за потребителите. Точно тук идва и в тестове, предназначени да "критика" на продукта. Веднага казвам, че думата "критика" тук има положителен конотация. Излишно е да казвам, че това изследване може да бъде само за употреба, тъй като без сценарий не може да идентифицира проблемите, установени, въпреки че, разбира се, можем да използваме помощни средства, например, за да изтеглите данни.
И накрая, последната сектора на Q4. което говори за тези тестове, които не проверяват решаване на бизнес проблеми, и говорят за това колко добре нашата молба е писано чрез думи като сигурност, производителност, стабилност, скалируемост и така нататък. Тези тестове могат да помогнат, как да се провери съответствието с нефункционалните изисквания, ако има такива, както и да разберете колко добре проектирани приложение е вече в ранните етапи. Тези тестове са от голяма полза, за да се избегнат проблеми в бъдеще. Ясно е, че за извършване на такива проверки, е необходимо да се използват специални инструменти, които се представят в момента много.
По този начин, Agile тестване квадранти са един вид контролен списък, който показва, че се движим в правилната посока, че процесите са достатъчно автоматизирани и могат да бъдат ангажирани в тестовете за изследователски ръчно. И най-важното, Agile тестване квадранти показват колко успешни нашия продукт, от бизнес гледна точка.
Свързани статии