Към съдържанието
wannacode

План и тестване по риск

Накратко: Времето за тестване винаги е по-малко от нужното. Планът казва какво, как, кой и кога; критериите за вход и изход казват кога да започнеш и кога да спреш. Рискът, вероятност по въздействие, подрежда какво да тестваш първо и колко дълбоко.

Проблем

Четири дни за две седмици работа

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

Какво ще тестваш? Ако започнеш от началото на списъка, на четвъртия ден още ще проверяваш страницата „За нас“, а промо кодът ще мине нетестван.

Идеята

Планът: какво, как, кой, кога

Планът на тестването (test plan) е договорът на екипа за тестването. Не е формуляр, а отговори на въпроси:

  • Какво се тества и какво не (обхват) и защо;
  • как: нивата, видовете, техниките, кое е автоматизирано;
  • кой и с какво: хората, средата, данните, инструментите;
  • кога: графикът и критериите за вход и изход;
  • рисковете и какво се прави с тях;
  • как се докладва: кой какво вижда и кога.

В каскаден проект планът е документ. В Agile екип е половин страница и разговор в началото на итерацията. Въпросите са едни и същи.

По-точно, за любопитните

Планът на тестването е CTFL v4.0.1, раздел 5.1.1. Документът за план според ISO/IEC/IEEE 29119-3 има още полета (контекст, комуникация, регистър на рисковете, стратегия, персонал, график). На изпита се пита за целта на плана и за типичното съдържание, не за точен шаблон.

Идеята

Колко ще отнеме?

Оценката на тестването не е налучкване. Има няколко прости техники:

  • По съотношение: миналите версии тестването е било 30 % от времето за програмиране. Програмирането сега е 20 дни, значи тестването около 6.
  • В три точки: питаш за най-добрия случай (a), най-вероятния (m) и най-лошия (b). Оценката е (a + 4m + b) / 6. Лошият случай дърпа нагоре и това е честно.
  • С екипа: всеки оценява сам, после се сравнява и се обсъжда разликата. Така работят и картите за покер в Agile (Planning Poker).

Оценката е оценка. Казваш я с допускането си: „5 дни, ако средата е готова в понеделник“.

По-точно, за любопитните

CTFL v4.0.1, раздел 5.1.4, изброява четири техники: по съотношение (ratios), екстраполация, Wideband Delphi (на която Planning Poker е вариант) и оценка в три точки. При трите точки програмата дава и стандартното отклонение: (b − a) / 6.

Пробвай

Оцени

1. Тестването на промо кода: в най-добрия случай 2 дни, най-вероятно 4, в най-лошия 12. Каква е оценката в три точки?
2. Миналите три версии тестването е било около 30 % от времето за програмиране. Сега програмирането е оценено на 20 дни.

Идеята

Кога започваш и кога спираш

Тестването няма естествен край: дефекти винаги има още. Затова се договарят критерии за вход и изход (entry and exit criteria):

  • Вход: кога има смисъл да започнеш. Версията е на тестовата среда, тестовете на компонент минават, тестовите данни са заредени, сторитата имат критерии за приемане.
  • Изход: кога спираш. Всички тестове за висок риск минават; няма отворен дефект с критична тежест; регресионният набор е зелен; рисковете, които остават, са записани и приети.

Критерият се проверява, не се усеща. „Готови сме“ е мнение, „0 отворени критични дефекта“ е факт.

В Agile екип критериите за изход на стори са в Definition of Done, а за вход в Definition of Ready.

Пробвай

Можем ли да започнем? Можем ли да спрем?

1. Кое е добър критерий за вход в системното тестване на версията?
2. Кое е добър критерий за изход?
3. Петък е, пускането е в понеделник. Тестовете за промо кода са изпълнени на 70 %, един дефект със средна тежест е отворен. Кой решава дали се пуска?

Идеята

Рискът казва какво първо

Изчерпателното тестване е невъзможно, а времето не стига. Въпросът е какво да тестваш първо и най-дълбоко. Отговорът е рискът.

Рискът е нещо, което може да се случи и ще навреди. Има две мерки:

  • вероятност: колко е вероятно да има дефект тук? Новият код, сложният код, кодът, сменен набързо, частите с много дефекти досега;
  • въздействие: колко вреди, ако има? Пари, много клиенти, закон, репутация.

Нивото на риска е вероятността по въздействието. Промо кодът, написан наново (вероятност 5), който може да раздава пари (въздействие 4), е 20. Страницата „За нас“ с нов телефон е 1.

Тестването по риск (risk-based testing) подрежда тестовете по това число: високият риск се тества първи, с повече техники и повече случаи; ниският накрая или само с бърз преглед. Ако времето свърши, неизпитаното е най-малко опасното.

По-точно, за любопитните

Рискът е CTFL v4.0.1, раздел 5.2. Програмата различава продуктови рискове (продуктът да не прави каквото трябва: грешна сума, бавна количка) и проектови рискове (нещо да попречи на работата: закъсняла среда, болен човек). Анализът на продуктовите рискове има две части: идентифициране и оценка, а контролът им е чрез смекчаване (тестване) и наблюдение. Скалите 1–5 тук са пример: на практика има и скали ниско, средно, високо.

Упражнение

Тестване по риск

1. Подреди по риск. Четирите дни от началото. Подреди частите на магазина в реда, в който ще ги тестваш: най-високият риск (вероятност по въздействие) отгоре.

Подреди от най-високия риск към най-ниския.

  1. Връщането: не е пипано (вероятност 1, въздействие 3)
  2. Доставката: прагът е сменен (вероятност 4, въздействие 3)
  3. Промо кодът: написан наново в тази версия (вероятност 5, въздействие 4)
  4. Страницата „За нас“: сменен е телефонът (вероятност 1, въздействие 1)
  5. Плащането с карта: не е пипано, но всичко минава през него (вероятност 2, въздействие 5)
  6. Лимитът в количката: не е пипан (вероятност 2, въздействие 2)

Тест

Провери се

1. Как се смята нивото на риска?
2. Какво е продуктов риск?
3. Защо планът изброява и какво НЯМА да се тества?
4. В Agile екип има ли план на тестването?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·