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

Защо рано

Накратко: Дефектът в изискването струва една дума, ако се хване при четене, и седмица работа, ако се хване след пускането. Статичното тестване (рецензия и статичен анализ) търси дефекти, без да пуска програмата. То намира самия дефект, докато динамичното вижда отказа. Двете не се заменят, а се допълват.

Проблем

Една дума, пет пъти

Помниш изискването „безплатна доставка над 50 €“, когато собственикът искаше „от 50 € включително“. Дефектът е една дума. Нека проследим колко струва тя според това кога я намираш.

  • При четене на изискването: анализаторът пита „а при точно 50,00 €?“. Поправката е една дума. Пет минути.
  • При разговора за сторито: добавя се пример „50,00 € → безплатна“. Още пет минути.
  • При теста на готовата програма: програмистът поправя кода, тестерът тества пак, пускането се отлага с ден.
  • След пускането: клиентите са платили 4,90 €, които не дължат. Връщат се пари, пише се писмо, поправката е спешна, а част от тях вече не вярват на магазина.

Дефектът е един и същ. Работата, построена върху него, расте с всяка стъпка.

Идеята

Цената на дефекта по фази

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

Кога е намерен Какво трябва да се направи отново
при четене на изискването думата в документа
при разговора за критериите думата и един пример
при теста на готовата програма кодът, тестовете, ново пускане
след пускането всичко горе, плюс парите, клиентите и доверието

Затова тестването започва рано. Не когато има програма, а когато има първото изречение. Това е и един от седемте принципа: ранното тестване пести време и пари.

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

ISTQB CTFL v4.0.1 казва в главата за статичното тестване, че дефектите, намерени рано, често са много по-евтини за поправяне от намерените късно в жизнения цикъл. Същата идея стои зад думата shift-left, която ще срещнеш по-нататък в курса.

Често се цитират точни коефициенти: „10 пъти в кода, 100 пъти след пускането“. Внимавай с тях. Те идват от изследвания отпреди десетилетия (най-известното свързват с Бари Боем), и числата им са оспорвани. Например Лоран Босавит в книгата „The Leprechauns of Software Engineering“ проследява откъде идват и колко малко данни има зад тях. Посоката е опитът на всеки екип. Точният множител зависи от проекта.

Идеята

Статично и динамично

Има два начина да търсиш дефекти.

  • Динамично тестване: пускаш програмата и гледаш какво прави. Тестерът слага 50,00 € в количката и вижда 4,90 €. Това е отказ. После някой трябва да намери дефекта, който го причинява.
  • Статично тестване (static testing): проверяваш работен продукт, без да го пускаш. Четеш изискването, модела, кода или тестовете и намираш самия дефект, директно.

Статичното има две форми. Рецензия (review): хора четат и коментират. Статичен анализ (static analysis): инструмент чете кода или модела и търси познати проблеми, например променлива, която никога не се ползва, или код, до който програмата никога не стига.

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

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

CTFL v4.0.1 (глава 3) изрежда разликите: статичното тестване намира дефекти директно, а динамичното предизвиква откази, от които после се търси дефектът. Статичното може да се приложи и към продукти, които не могат да се пуснат (документи, модели), и да хване качества, които не зависят от изпълнението, като поддържаемостта. Динамичното може да хване неща, които се виждат само при работа, като производителността.

Статичният анализ най-често върви автоматично при всяка промяна на кода. Компилаторът, който казва „тази променлива не е инициализирана“, вече е такъв инструмент.

Пробвай

Статично или динамично?

1. Анализаторът чете спецификацията на връщането и пита „14 дни от кога?“.
2. Тестерът слага в количката продукти за 50,00 € и вижда доставка 4,90 €.
3. Инструмент минава през кода и казва „тази променлива никога не се ползва“.
4. Колега чете критериите за приемане на сторито за промо кода, преди работата да започне.

Идеята

Какво се рецензира

Почти всичко, което може да се прочете и разбере:

  • изисквания, сторита и критерии за приемане;
  • модели: процеси, машини на състоянията, таблици на решения;
  • код;
  • тестови случаи и сценарии;
  • планове, договори, ръководства за потребителя.

Рецензията на изискването е особена. Тя е и верификация (вярно ли е записано, еднозначно ли е, проверимо ли е), и валидиране (това ли е нуждата). Когато собственикът прочете „над 50 €“ и каже „не, исках от 50 €“, той валидира. Когато тестерът попита „а при точно 50,00 €?“, той верифицира.

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

Пробвай

Рецензирай критериите

Критериите за отказа на поръчка, преди работата да започне. Отбележи проблемите и избери вида на всеки.

Натисни думите, които са проблем; отново, за да махнеш отметката. Със стрелките се минава от дума на дума.

Идеята

Ранна обратна връзка

Има и по-лесен начин да хванеш дефекта „над 50 €“ рано: да покажеш нещо на собственика. Пример, прототип на количката, таблица с цените на доставката за 49,99, 50,00 и 50,01 €. Той поглежда и казва „тази не е вярна“.

Честата обратна връзка от заинтересованите страни пази от най-скъпия дефект: продукт, направен правилно, но не това, което е трябвало. Колкото по-рядко питаш, толкова повече работа се прави по грешна посока, преди някой да забележи.

Затова рецензията не е само за QA. Собственикът, складът, счетоводството четат изискванията, които ги засягат. Те ще видят неща, които ти не можеш.

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

CTFL v4.0.1 нарича това ранна и честа обратна връзка от заинтересованите страни (раздел 3.2). Тя помага изискванията да се разбират еднакво и проблемите да се виждат рано. Без нея екипът рискува да построи продукт, който не отговаря на нуждата, и да го разбере чак при приемането.

Упражнение

Колко струва

1. Пътят на дефекта. Подреди моментите, в които дефектът „над 50 €“ може да бъде хванат, от най-евтиния до най-скъпия.

Подреди от най-евтиното до най-скъпото място, където дефектът може да бъде хванат.

  1. При рецензия на кода: „> 50“ не е „от 50 включително“
  2. След пускането: оплакване от клиент, платил 4,90 €
  3. При четене на изискването: „а при точно 50,00 €?“
  4. При теста на готовата програма: количка за 50,00 €
  5. При разговора за критериите: пример „50,00 € → безплатна“

Тест

Провери се

1. Какво е статично тестване?
2. Какво намира статичното тестване, което динамичното не намира лесно?
3. Защо дефект в изискването струва повече, ако се хване след пускането?
4. Рецензиите хващат много. Значи ли това, че тестовете на готовата програма не трябват?
5. Кое твърдение за „дефектът струва 100 пъти повече след пускането“ е вярно?

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