Така,
1.След като девелъпърите (разработчиците) напишат кода, релийз инженерите правят възможно тестването за тестърите в test environmenta-а (тест средата) - например http://main.sharelane.com . Тестърите правят един бърз smoke test ,за да се провери дали софтуера е годен за тестване и дали има смисъл да го правим.
Пример: Ако не можем да влезем в сайта main.sharelane.com, просто не можем да продължим с тестването => софтуера не е годен за тестване.
По правило, на един smoke test не му трябва повече от половин час и обикновено не изисква никакви специални тест кейсове.
Ако smoke теста fail-не (се провали), ние говорим с програмистите и релийз инженерите (може да има грешка от страна на релийз инженерите) и те почват да фиксват проблема. Щом го оправят, ние правим наново този smoke test. И така този малък цикъл се върти докато не pass-не smoke testa.
2.Щом всичко е наред, релийз инженерите правят code freezing (фрийзват кода) и го push-ват към тестовата среда (main.sharelane.com), и тестърите започват тестването на новите фийчъри като пускат тест кейсовете написани за този релийз.
3.След като фийчър тестингът е приключил успешно, тестърите започват тестването на старите фийчъри. Този тип тестване се нарича regression testing (регресивно тестване).
Тоест,след като сме приключили с тестването на новите фийчъри за релийз 2.0 (примерно), започваме да ползваме тест кейсовете си написани за релийз 1.0 за регресивно тестване.
Намерените бъгове се слагат в бъг тракинг системата, програмистите ги фиксват, а тестърите проверяват дали са фикснати като хората.
4. Веднъж regressive test-а преминал успешно (тук обикновено има конкретен deadline или срок за изпълнение), тестърите пускат acceptance тестинг (тестване за одобрение), по времето на който тестърите пускат специален сет от P1 тест кейсове (обикновено под формата на чеклисти) и правят ad hc тестинг (недокументиран тестинг базиран на интуиция и вдъхновение).
5.Когато acceptance testing-а приключи успешно, PMs (продукт мениджърите), тестърите, девелъпърите, релийз инженерите и мениджърите се събират за Go/No-Go мийтинг.
6. Релийзване на самия продукт.
