Пътен тест план - Наистина ли се нуждаем от такъв?

Нуждаем ли се от Agile документ за план за изпитване?

Планирането на тестове е важна дейност в процеса на тестване и изисква внимателни мисли и решения не само от мениджъра на теста (който обикновено отговаря за създаването на тестовия план), но и от всички членове на тестващия екип и мениджъра за разработване на продукти.

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

Учебниците посвещават цял ​​раздел, свързан с планирането на тестове, как да се напише такъв и какво да се включи в план за изпитване, докато някои ръководни органи и регулаторни организации като FDA изискват изчерпателен план за изпитване, за да одобрят продукт.

В реалния свят, в среда на водопад, доста често документът за тестовия план е такъв, който почти никога не се разглежда по време на жизнения цикъл на продукта. Дейността на „Планиране и мониторинг на тестове“ трябва да бъде непрекъсната дейност през жизнения цикъл на проекта, трябва да се актуализира според промените в проекта, но в повечето случаи това не е така; планът за изпитване или не се актуализира, или промените са със задна дата, което прави документа на плана за изпитване най-малко ценния страничен продукт.

Въпреки че планирането на тестовете почти винаги се разглежда като задължителен продукт в проект за водопад, наистина ли се нуждаем от план за тестване за гъвкав проект? т.е. дали наистина добавя някаква стойност към това, което целият екип се опитва да постигне?

Подвижният манифест явно благоприятства работещ софтуер над изчерпателна документация и в отговор на промяната следвайки план.

В гъвкава среда съдържанието на изданието (елементите) се обсъжда преди спринта, така че екипът за тестване предварително да знае какъв е обхватът и какво трябва да се тества.

В „планирането на покер играта“ оценките се обсъждат, така че тестващият екип знае колко време ще отнеме да тества дадена функция (това включва настройка на средата, сценарии, автоматизация, проучване, производителност и т.н.).

В „сесия за писане на истории“, където се обмислят подробности за всяка функция, тестовият екип вече започва да пише сценарии, за да обхване многото начини, по които историите могат да бъдат тествани - това е най-ценната дейност на екипа.

По време на спринта QA непрекъснато тестват нов код / ​​функция. Планирането на теста се превръща в динамична дейност, тъй като приоритетите за деня се променят. Тестването се основава на това каква е активността за деня и резултата от предния ден.

Ясно е очевидно, че планът за изпитване не разкрива дефекти, но сценариите на теста ще го направят. Усилията трябва да бъдат насочени към създаване на по-добри сценарии от създаването на план за тестване.

Това, което наистина е необходимо, е кратко документ за гъвкава стратегия за тестване, описващ процесите, приложими в спринтовете , т. е. раздели за планиране на спринта, семинари за спецификации, ръчно осигуряване на качеството, автоматизация, покритие на теста, докладване на тестове, тестови среди, етап и т.н. ... Това са процеси и дейности, приложими за всеки спринт, но разбира се, получени от визията на компанията.

И така, имайки предвид всичко това, документът за тестовия план или обширните тестови стратегии наистина са нещо от миналото? Наистина ли се нуждаем от Agile Test Plan?