... Или, с други думи, как да се изчисли времето за тестване, така че всички повярвали? В края на краищата, в действителност, ние обикновено - с два гола. Първо - намери време, за да не се правят грешки и правилно да разпределят ресурсите - най-вероятно в началото да го направя добре още няма да работи. Втората цел е по-реалистично: да отброява оставащото време за тестване, за да се докаже на някого, че имате нужда от повече хора в екипа, да обясни защо не е нужно време, и т.н. Странното е, че само след 50 да се направи втората, след това .. и първият, който да се приготви!
Нека сега разгледаме как да отделите време, за да се тества, като се използват конкретни примери.
Случай 1: "Ето TK, колко време е необходимо да се пише тестовете?"
Да кажем, идва при нас идва папката обем с добре формулирани от гледна точка на задание (ТЗ). Попитахме колко време е необходимо да се пише тестовете (TC) на целия случай.
Преди да можем да отговорим на този въпрос, ние трябва да познаваме добре:
- Кой ще пиша на превозното средство?
- Какво urovencheloveka. който ще напише на превозното средство: тя е по-малка или по-голям опит от теб? Ако той има по-малко опит, разбира се, че ще се нуждаят от повече време. Ако той има най-много опит като имате, тогава вашата оценка се слеят. Ако човек е по-стръмен вас, тогава аз не разбирам защо сте били помолени да отброява оставащото време.
- Какво е нивото на технологични знания. дали човек ще бъде в състояние да извърши тестване на ниско ниво, както всички да разберете дали той ще се разбере какво се случва с базата данни, например?
- Какво е нивото на познаване на предметната област. Това е още по-важно, отколкото на нивото на знания за технологията, защото ако ние, например, трябва да тествате някои натрупа финансова приложение, и ние не разбираме изобщо какво облигациите и опции - много време ще бъдат изразходвани за разбиране на предметната област. За да се разбере без това, колко е трудно TK, колко сложно продукта, и в крайна сметка, колко богат и как по принцип трябва да е на превозното средство, е трудно.
- Защо и за кого написана от TC?
- За себе си - ако ние тестваме нашата вътрешна развитие. Ние разполагаме със собствена продукт, нашият собствен екип и пишем TC е за вашия продукт.
- За клиента. Понякога поръчките на клиентите само за тестване, а понякога - само TC. Понякога той иска тест веднъж, а след това го оставете един артефакт, в която той ще бъде в състояние да се тества. TC за клиента може да бъде по-малко детайли, както и подробно, но по различен начин, отколкото ако сме писали превозно средство за себе си. Така че, ние разбираме всички условия на изпитване, но ние може би трябва да се предписва в детайли всички видове сложни неща TC на предметната област. Клиентът може да се разбере напълно проблем домейн, но не можем да знаем какво е валидиране на формата, а той ще трябва да го обясня.
- За проверка при приемане - в този случай, превозното средство все още по-трудно да пиша, отколкото към клиента, защото това е изследване, резултатите от което клиентът не може да приеме, ако не искате. TC така за проверка при приемане пишем много по-официално - не трябва да има език, като "всичко работи правилно", тъй като клиентът не може да ви накара да се направи нищо, и никога на такива превозни средства.
- За автоматизация. Тук трябва да се мисли за тестване, контролирана dannmi, как да го автоматизира, и така нататък. Г.
- За душата. В този случай, ние просто искаме да разберем, и няма искане от страна на екипа за тестване.
- Къде са написани на система за управление на тест?
- Позната среда.
- Непозната среда. В непозната обстановка, разбира се, ще ни е необходимо повече време.
Отговорите на тези въпроси зависи от колко време е необходимо да се напише един положителен тест - T1. Също така е необходимо да се разгледа време да пиша отрицателен TC (тя ще бъде по-нататък T-1). Моят опит е, че негативният TC обикновено написани вече - тъй като те обикновено се нуждаят. Разбира се, това се случва по различни начини, но ми се струва, че по-добре знаем на предметната област, толкова по-добре разбираме в заявлението, по-добре да разбере къде и как тя може да падне, толкова повече ще се отрази негативно TC. Ако, например, има един отрицателен, може би не е преценила правилно прилагане на три положителни TC. Ако една положителна можете да излезе с отрицателен TC 500, това е - добра работа. съотношение I на положителни и отрицателни средство - обикновено в границите от половин до 1/5.
Т. ч. Трябва да намерим време да пиша положителна TC, за да се прецени доколко положителни и отрицателни, и да брои през цялото време.
Опции за ценообразуване:
- Грубо експерт. Например, ние знаем, че обикновено е TK една страница пишем TC 5. Обикновено едно превозно средство пишем 20 минути. Мандатът на 300 страници. 5 х 20 х 300 = 30 000 - това е колко минути без да се замисля пишем TC.
- Тестване отнема X период от време от момента на проекта.
- Писане тест случаи време Y на време да се тества
- Разделяне TK в еднородни части (например функционална) и се опитват да пишат на превозното средство за всяко от
- Вижте колко време им е отнело да пиша за превозното средство на определен брой страници, всяка част, на тази основа да се изчисли колко време трябва да продължи да пише за всяка част на превозното средство
- Ние добавите до броя за всяка от времето
Сега нека да се опитаме да преброим колко часа сме отишли за написването на превозното средство (но имайте предвид, че не тестване на всички):
Оценка ние не сме съгласни, но това е добре - поне ние бяхме в състояние да се намери някой. И ако имате достатъчно време на нашата оценка, можем да направим оценка на редица начини.
Ние вярваме, че времето с помощта на Agile
Сега нека да поговорим за гъвкава разработка, когато няма технически спецификации. Не е много ясно как да се прецени, но е възможно да се разпределят някои подходи. Например, можете да направите следното:
- Просто проверете изоставането;
- пиша с висока TC;
- запишете всички стъпки в спринта и се опитайте да изчислите колко ще отнеме време - този подход се анализира по-долу.
Сега малко отстъпление за QA-мениджъри, мениджъри на проекти. Всички стъпките за създаване и случаи на провеждане на теста ние можем да се разделят на следните компоненти:
Случай 2: "Това е част от функционална, колко време ще бъдат изразходвани за тестване?"
Колко време ще отнеме да се тества в определена част от функционалните? За да направи тази оценка, има различни начини:
Можете да видите колко време е необходимо обикновено, за да се тества подобна функционалност. - Можете да потърсите същата функционалност. Ако ние сме преди това е показала такава. Това е много удобно! Ако не сте, разбира се, записани за последен път, колко време отне.
- Дедуктивната оценка - ако знаем колко тази функционалност се осъществява в общ функционален (ако например, ние вече знаем колко време е необходимо, за да завършите регресия), ние просто се види, че това функционално тестване ще вземе, например, една пета част от времето.
- Индуктивен оценяване - ние помним колко време отделяте за всяко превозно средство. Гледаме на функционалността и осъзнавам, че ние трябва да го тествате 10-15 TC.
Че в този случай е важно да се има предвид? Какви нови функции отново може да поиска изготвяне време на околната среда. Важно е да се има предвид съществуването на коефициента на познаването на системата: повече време, за да се тества дали ги shooing първи път, отколкото ако ги shooing втори или трети път. Но ако има идва за втори път в един месец, вие сте все още го прогонва, като че ли за първи път - все пак, това е всеки по свой начин.
Случай 3: "Защо си че нищо не?!"
На следващо място, много често срещан въпрос, зададен от тестерите: "Какво са всичко, което правят, защо сте преобладават нищо, защо трябва да помогне с автоматизация на защо не искате всеки ден ние пусна нова версия - тя определя нещо ново не , "
За да се покаже това, което правим, ние можем за всеки проект да се напише изцяло всички задачи, които се извършват при спринт, и ги боя в дни: изчисли колко време се отделя за всяка задача в даден ден. Така че можете да видите средната, максималната и минималната товара.
Един пример за такава таблица:
Когато го направих, аз видях, че натоварването да не винаги да бъдат оптимално разпределен - понякога зареждането на големи, а понякога и на половин ден, за да се направи нищо. Това дава възможност да се направи някои изводи и някак рационализиране на процеса, разпределение на натоварването - например, някои неща правят предварително, дори и да не е в пълно съответствие с логиката на процеса. Например, ако в началото на спринта имаме много свободно време, ние можем вече да започнете да пишете истории от потребителите на следващия спринт. Въпреки, че ние не знаем структурата на следващия спринт, но ние сме най-вероятно може да се отгатне, че тук това са две или три истории това определено ще - те обикновено са най-критично, те обикновено са все още трябва да се пренапише, така че това е добро упражнение.
Получаваме багажника в по дни часа. И ако се окаже, че всеки ден трябва 24 часа от тестове, а ние имаме само двама души ... Така че, определено трябва трета тестер!
Case 4.1: "Ние произвеждаме събрание в петък, а дори и по-рано - толкова, колкото е необходимо време, за да се тества"?
В този случай, процеса на тестване е конструиран както следва:
- тест дим + тест пълна регресия на х на брой от най-важните платформи + тест за основна функционалност на всички платформи + тестове на пълна регресия на платформите (вж. Matrix).
- Повторно тестване: пуши тест и валидиране xvse платформа.
Тестовете за пълна регресия на платформите се извършват в този случай, както следва (Cr, FF и т.н. тук - различна платформа, в този случай - браузъри ..):
За тази матрица, можем да видим, че за всеки тест платформа всяка част на функционалната: в края на краищата се оказва, че всички ние сме на проверка и изпитване, за да работят на всяка платформа функционалност. Можем също така да се премести на матрицата - в края на краищата се оказва, че ние всяка функция все още проверка на всяка платформа за определен брой писти. Той има една проста схема - и може да бъде в действителност 20 конфигурации, без възможност за автоматизиране на тестването им - разбира се, в този случай ние не разполагат с време, за да се провери, както и ще бъдат тествани от матрица.
В резултат на това, ние получаваме по следната формула:
ΣT = (Tprec + Treg) х (Qmain + 1) + (+ Tprec Tbase + Tsmoke) х Qconf + (Tsmoke + Tvalidation) х Qconf х Qreturns
Qmain - броят на основната конфигурация, в която се тества всичко.
Qreturns - броят на възвръщаемост.Според тази формула, е ясно колко време сме отишли. На него можете да се опитате да следите на времето, потърсете тест отнема най-много време. Той също така ще стане ясно къде и какъв по-добър автомат - ние разбираме, където автоматизация ще ни спаси голямата част от времето.
Case 4.2: "Твърде много тестове! Нека по-бързо. "
Ако са необходими за извършване на тестове по-бързо, ние можем да се намалят на броя на тестове на следните принципи:
- Ние разглеждаме приоритетите:
- тест - ако ние боя приоритетите на TC. След това ние ще работим само с най-висок приоритет превозното средство;
- потребителски истории и буболечки. Ако нашият автомобил, прикрепен към тях.
- Очакваме в бележките по версията (бележки по версията), който включва:
- критична функция. без които заявлението не работи и никой не му пука;
- обявени нови функции - като му публично обявени, от съществено значение е да се провери на потребителите;
- поправя критични грешки (най-вероятно, грешките вече ще са проверени);
- твърди, корекция на грешки - казахме, че ние се определи нещо, а ние проверяваме;
- Известни проблеми (известни проблеми) - достатъчно парадоксално, но ние трябва да ре-тест грешките, които сме декларирали като грешка, която пуснахме на продукта. Защо направи това? На първо място, трябва да се провери, че техният ефект е точно същото като това, което сме описали. На второ място, ние проверяваме дали работи, че байпас тази грешка, която ние предлагаме.
- Вместо да се намали обемът на тест може да се увеличи екип.
- Добави програмисти - най-доброто от своя същия проект. Например, те могат да пишат генератори на данни и т.н. - всичко за автоматизация или poluavtomatizatsii. Те го правят добре, а отговорността за тестване все още не е върху тях - така че те да не страдат, защото техният код не работи. По същата причина, можете да помолите някои програмисти проверяват код за други програмисти.
- Обадете тестери от други проекти или проект, но са ангажирани в нещо друго.
Като цяло, процесът на истински тест може да се представи под формата на триъгълник. Ъглите на триъгълника - това е:
- обем тест.
- Брой на хората в екипа.
- Срок. за които е необходимо да се извърши тестване.
Скоростта и качеството на изпитване зависи от тези три аспекта, а именно - върху тях трябва да се мисли, за да планират успешно работата. Например, ако ние сме поканени да тествате продукта за нереалистично кратък период от време, а ние не отговарят, или да откаже такава работа (ако не искате да се освободи ниско качество на продукта е, разбира се), или да работят с посочените по-горе аспекти. След това можете да:
- Намаляване на размера на тестване.
- Увеличаване на броя на хората в екипа.
- Попитайте удължи тестване.
Последният начин - може би най-надеждни: в действителност хората в екипа може да даде нелеп, и намаляването на обема на тест може да доведе до освобождаването на суровия продукт.
Също така, методът работи тук - да попитам защо тези условия. Може би трябва само една функция на един клиент - след това го направи специално съобщение, а след това се тества за останалото.
И накрая, в случай, че: завършване на проекта вече е освободен
Ако проектът е вече, но получи молба да го променят, тъй като те се изчисли по време на изследването, развитието и така нататък. Д. В този случай, време е обикновено, но това се умножи по две, защото всички всички хора са забравили вече в други проекти - това отнема време, за да се запознаят със системата. Освен това, добавянето може да бъде извън стандартния цикъл, така, с изключение на добавянето на този тест може да се наложи пълна регресия - след това добавете време за приключване на регресия.
Свързани статии