Как да разберем кога да спрем с тестването?

Question

И другият ми въпрос е:
Какво правим ако имаме малко време за тестване? Кои тестове да приоритизираме?

P.S. Ще съм благодарен ако ми препоръчате книга за QA, която се намира на българския пазар. Може и на английски :)

Благодаря! 

Answer 1

Здравей, 

това е много добър въпрос. Реално кога да спрем да тестваме зависи от това дали тестваме критична функционалност, дали тестваме нещо тривиално или тестваме софтуер, който е от жижнено важно значние. Например ако тестваш софтуер за self driving кола, тогава тестваш до откат. Реално там тестването никога не спира. Но ако тестваш нещо, което не е толкова важно може и да спреш по-рано. 

Това е решение на test lead-а или на QA manager ролята. Позиции, които предполагат, че хората имат много опит в тестването на софтуерни продукти. Много от решенията дали нещо да се тества много или по-малко идва и от опита. Препоръчавам ти да се абонираш за потребителската група за софтуерно тестване и да посещаваш месечните срещи. Много често има лекции на много опитни лектори, които споделят опита си. Например лекцията "Как се управлява QA екип", беше мега яка. Има видео към лекцията, може да го гледаш. 

Answer 2

Никога. Тестването не спира никога. :)
Алтернативно - тестването приключва, когато и фирмата разработваща услуга/продукт приключи.
Все едно да попиташ "Искам да имам яко тяло, тренирам много, храня се според това, коя храна ми се отразява най-добре, вече имам добре оформени плочки, гърди, дупа, бла бла бла, кога ще мога да спра да тренирам и да запазя това тяло?" Никога.

Формално обаче тестването приключва в един безметежен миг изразяващ се в няколко часа преди sign-off. Формално. Реално според зависи от компанията - може да разполагаш с разни седмици през годината, в които може да обърнеш внимание на инфраструктура, на разни house keeping неща и т.н., докато правиш това обаче ти - други -> тестват. :) Така, че не приключва никога. И това е добре.

По отношение на времето за тестване и приоритизрането - никога нямаш много време за тестване, времето по дефиниция никога не стига и винаги е малко. Особено малко е към края на рилийса. Тогава усещаш колко малко време имаш всъщност. Обикновено се приоритизира на база най-важното по отношение на продукта/услугата, нещата/features без които няма нито продукт нито услуга. Разбирай го така - каквото и ново да изкараш старото, което вече го има, което вече се ползва - трябва да продължи да работи, т.е. издънка по отношение на новите неща макар и кофти е окей, но издънка по отношение на старите неща, особено на функционалност без, която нямаш нито продукт нито услуга - НЕ. :)

Пример: Тестваш някаква пеймънт система - системата процесва плащания. Правите нов feature, който уведомява със SMS всеки, който е направил поръчка през системата използвайки своя акаунт. Клиентите няма да откачат ако този нов feature не работи като хората и има проблеми (примерно на всяко трето число от всеки трети ден на всеки трети месец няма SMS), но клиентите тотално ще отакчат ако старата им функционалност бъде засегната - например да не могат да правят плащания.

За да приоритизраш трябва да познаваш продукта. Може и да не го познаваш и пак да приоритизираш изхождайки от предишен опит, а ако нямаш такъв ... кофти - тогава следва импровизация и common sense - кое на теб ти се струва най-критично за тестване, без което продуктът/услугата няма да са нито продукт, нито услуга. И това не е универсално. Много зависи от поставените цели. Понякога се залага на нещо радикално ново и има стремеж то да е като хората като legacy нещата се загърбват (рядко, но се случва).

Няма универсална формула, всичко зависи от обстоятелствата и поставените цели (в контекст на приоритизиране).

По отношение на книги - google / quora / bing. :) Повечето, на които ще попаднеш са окей - дават теоретична основа, разказват добре за базовите знания, преповтарят на 70% едно и също... и това е. Ако искаш истински смислени и добри книги за тестване, чети книги от/за хора, които са създали красиви неща (все тая какви). :)

Answer 3

По отношение - кога да спреш тестването - най-общият отговор според мен е - когато в приложението могат да се изпълнят всички планирани и документирани бизнес- процеси  (функционален обхват) от потенциалните потребители с удовлетворени техническите изисквания за тях (като бързадействие например ..). Не трябва да съществуват критични грешки (съществуват дефиниции за сериозност на грешката (severity), което оценява цялостното въздействие на тази грешка върху работоспособността на изграждания софтуер). Възможно е  да се направи внедряване с някои известни bugs, които имат по-скоро козметичен характер (свързани с някои изисквания за GUI, непълни съобщения ...) - все проблемчета, които създават дискомфорт, но не са критични за функционирането и могат да се отстранят по време на гаранционната поддръжка. Добре е да се направи план за отсраняването на тези документирани несъществени несъответсвия, които са обвързани с времена и следващи инсталации, свързани с обновяване на софтуера.

Когато времето за тестване не е достатъчно - приоритетите са свътзани с най-използваните сценарии (като честота на използване и брой потребители на даден бизнес процес/тестови сценарии, като възможности за пробив в системата и т.н - зависи от конкретиката и предметната област на приложението, т.е за всеки проект си има специфика. И тук наистина основната роля е на стартши QA, който заедно с TL да дефинират приоритетите на база на оценените рискове.