Прутлівы план выпрабаванняў - ці сапраўды ён нам патрэбен?

Ці патрэбны нам гнуткі дакумент плана выпрабаванняў?

Планаванне выпрабаванняў - важная дзейнасць у працэсе тэсціравання, якая патрабуе ўважлівых разважанняў і рашэнняў не толькі кіраўніка выпрабаванняў (які звычайна адказвае за стварэнне плана выпрабаванняў), але і ўсіх членаў групы тэсціравання і кіраўніка распрацоўкі прадуктаў.

Некаторыя лічаць, што гэта самая важная частка працэсу тэсціравання (я асабіста лічу, што распрацоўка тэстаў і абстрактнае мысленне з'яўляецца найбольш важным), і марнуюць шмат гадзін і намаганняў на складанне выдатнага плана тэсціравання.


У падручніках прысвечаны цэлы раздзел, звязаны з планаваннем выпрабаванняў, як яго напісаць і што ўключыць у план выпрабаванняў, у той час як некаторыя кіраўнічыя органы і рэгулюючыя арганізацыі, такія як FDA, патрабуюць комплекснага плана выпрабаванняў для зацвярджэння прадукту.

У рэальным свеце ва ўмовах вадаспаду даволі часта дакумент плана выпрабаванняў з'яўляецца такім, які наўрад ці разглядаюць на працягу жыццёвага цыкла вырабу. Дзейнасць 'Планаванне і маніторынг выпрабаванняў' павінна быць пастаяннай дзейнасцю на працягу жыццёвага цыкла праекта, яна павінна абнаўляцца ў адпаведнасці са зменамі ў праекце, але ў большасці выпадкаў гэта не так; план выпрабаванняў альбо не абнаўляецца, альбо змены рэтраспектыўна робяць дакумент плана выпрабаванняў найменш каштоўным пабочным прадуктам.


Хоць планаванне выпрабаванняў амаль заўсёды разглядаецца як абавязковы прадукт у вадаспадным праекце, ці сапраўды нам патрэбны план выпрабаванняў для гнуткага праекта? гэта значыць, ці сапраўды гэта дадае каштоўнасць таму, што спрабуе дасягнуць уся каманда?

Спрытны маніфест відавочна спрыяе працуе праграмнае забеспячэнне над усёабдымнай дакументацыяй і рэагуючы на ​​змены над наступным планам.

У гнуткім асяроддзі змест рэлізу (элементы) абмяркоўваецца перад спрынтам, каб каманда тэставання загадзя ведала, які аб'ём і што трэба праверыць.

У 'гульні ў покер у планаванне' ацэнкі абмяркоўваюцца, каб каманда тэсціравання ведала, колькі часу спатрэбіцца для тэставання функцыі (гэта ўключае наладу асяроддзя, сцэнарыі, аўтаматызацыю, даследаванне, прадукцыйнасць і г.д.).


У 'сеансе напісання гісторый', дзе прадумваюцца дэталі кожнай функцыі, тэставая група ўжо пачынае пісаць сцэнарыі, каб ахапіць мноства спосабаў праверкі гісторый - гэта самае каштоўнае занятак каманды.

Падчас спрынту QA бесперапынна тэстуе новы код / ​​функцыю. Планаванне тэстаў становіцца дынамічнай дзейнасцю, паколькі прыярытэты дня змяняюцца. Тэставанне заснавана на тым, якая актыўнасць за дзень і вынік напярэдадні.

Цалкам відавочна, што план выпрабаванняў не выяўляе дэфектаў, але сцэнарыі выпрабаванняў будуць. Намаганні трэба накіраваць на стварэнне лепшых сцэнарыяў, чым на стварэнне плана выпрабаванняў.

На самой справе патрэбен кароткі гнуткі дакумент стратэгіі выпрабаванняў, які апісвае працэсы, прыдатныя да спрынтаў , г.зн. раздзелы пра планаванне спрынту, майстэрні спецыфікацый, кантроль якасці, аўтаматызацыю, ахоп выпрабаванняў, справаздачнасць да выпрабаванняў, асяроддзе выпрабаванняў, пастаноўку і г.д ... Гэта працэсы і мерапрыемствы, якія прымяняюцца да кожнага спрынту, але, вядома, атрыманы ў выніку бачання кампаніі.


Такім чынам, з улікам усяго гэтага, ці сапраўды дакумент Плана выпрабаванняў альбо шырокія стратэгіі выпрабаванняў засталіся ў мінулым? Ці сапраўды нам патрэбны спрытны план выпрабаванняў?