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

Добре дошъл

Накратко: Верификацията пита „направихме ли го правилно“, а валидирането пита „направихме ли правилното нещо“. Курсът учи и двете, с изисквания, сторита, примери и тестове върху един магазин.

Проблем

Направено точно по изискването. И пак грешно

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

Пускат рекламата: „Безплатна доставка от 50 €“. Първите клиенти с количка за точно 50 € пишат сърдити имейли. Собственикът е мислил „от 50 €“, а е написал „над“.

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

Идеята

Два въпроса

Историята има два отделни въпроса:

  • Направихме ли го правилно? Прави ли програмата това, което пише в изискването? Това е верификация (verification). В историята тя мина.
  • Направихме ли правилното нещо? Изискването ли е това, което клиентът наистина иска? Това е валидиране (validation). В историята никой не го направи.

Двете се объркват, защото и двете звучат като „проверка“. Разликата е в мерилото: при верификацията то е написаното, а при валидирането е истинската нужда.

Обратният случай също се случва. Изискването казва „от 50 €“, а програмата прави „над 50 €“. Тогава изискването е вярно, а програмата не му отговаря. Хваща го верификацията.

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

Речникът на ISTQB взима определенията от ISO 9000. Верификация: потвърждение с проверка и обективни доказателства, че определените изисквания са изпълнени. Валидиране: същото, но за изискванията за конкретна употреба, тоест дали продуктът върши работа за това, за което е поискан.

IEEE 1012 (стандартът за V&V, последно издание от 2024 г.) подрежда двете като дейности през целия живот на системата, не само в края. Той въвежда и ниво на цялост (integrity level): колкото по-тежки са последиците от отказ, толкова повече и по-строга проверка. Магазинът е ниско ниво. Софтуерът на медицинско устройство е високо, и там се стига до формална верификация: математическо доказателство, че моделът на системата не може да влезе в забранено състояние. Тук няма да стигнем дотам.

Идеята

Примерът хваща и двете

Как щеше да се хване грешката навреме? С един въпрос, преди да се пише код: „А при точно 50,00 €?“

Конкретният пример събира двете проверки. Собственикът отговаря „безплатна, разбира се“, и изискването се поправя (валидиране). После същият пример става тест, който проверява програмата (верификация).

Така ще изглежда този пример в модула за сценарии. Езикът се казва Gherkin и се чете като изречение:

# language: bg
Функционалност: Безплатна доставка


  Сценарий: Поръчка за точно 50 €
    Дадено количка за 50,00 €
    Когато поръчам
    То доставката е 0,00 €

Затова курсът държи заедно бизнес анализа и тестването: изискването и тестът се срещат в примера. Правилото, с което работим оттук нататък, е поправеното: доставката е безплатна при поръчка от 50 € включително, иначе е 4,90 €.

Пробвай

Кое от двете?

1. Изискването казва „максимум 10 бройки от продукт в количката“. Програмата пуска 11-та бройка. Какъв е проблемът?
2. Връщането е „до 14 дни“, точно както е написано и направено. Счетоводството обаче брои от деня на доставката, а сайтът от деня на поръчката. Клиентите се карат. Какъв е проблемът?
3. Тестерът проверява, че поръчка за 49,99 € плаща 4,90 € за доставка, както пише в изискването. Какво прави?

Идеята

Кой какво прави

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

  • Продуктовият собственик (product owner) решава какво се прави и в какъв ред. Отговаря за стойността: защо това, а не друго.
  • Бизнес анализаторът (business analyst) разбира какво наистина трябва. Пита, слуша заинтересованите страни, пише изискванията, сторитата и примерите. Неговият въпрос е „какъв проблем решаваме“.
  • Програмистът прави решението. Неговият въпрос е „как“.
  • QA (quality assurance) проверява, и не само накрая. Добрият тестер пита „а при точно 50 €?“ още докато изискването се пише.

Валидирането е най-вече работа на анализатора и собственика, а верификацията на QA и програмиста. Границата не е стена: в историята с доставката тестерът щеше да спаси валидирането с един въпрос.

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

ISTQB разделя осигуряването на качеството (quality assurance) от тестването. Осигуряването е за процеса: как работим, за да не се появяват дефекти (рецензии, стандарти, обучение). Тестването е за продукта: намира дефектите, които все пак са там, и е вид контрол на качеството (quality control). На работа „QA“ често значи „тестер“. Курсът учи и двете.

Идеята

Пътят на курса

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

  1. Добре дошъл: валидиране и верификация, защо програмите грешат, какво е качество.
  2. Изисквания: кого да питаш, как да питаш, видовете изисквания и кое изискване е добро.
  3. Сторита и критерии за приемане: „Като … искам … за да …“, разбиване на големите сторита, правила и примери.
  4. Сценарии с Gherkin: Дадено, Когато, То; сценарии, които бизнесът чете.
  5. Проследимост: кое изискване с какво е покрито и какво се пипа, когато изискването се смени.
  6. Статично тестване: дефект, намерен в текста, преди да има програма.
  7. Техники за тестов дизайн: класове, граници, таблици на решения, състояния. Защо 49,99 €, 50,00 € и 50,01 € са три различни теста, а 30 € и 40 € са един.
  8. Нива, видове и процес: от теста на един компонент до приемането, планът, рискът и докладът за дефект.
  9. Нефункционално: използваемост, производителност и сигурност като изисквания, които се мерят.
  10. Автоматизация: сценариите стават тестове, които се пускат сами.
  11. Валидиране с клиента: приемното тестване и мерене след пускане.
  12. Проект: промо кодовете от заявката до пускането.

Задачите се проверяват веднага. По-нататък ще пишеш сценарии и тестови случаи, които се пускат срещу правилния магазин и срещу версии с истински грешки.

Идеята

Курсът и сертификатите

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

Програма Какво е Модули
ISTQB CTFL v4.0.1 основното ниво за тестери 0, 2, 3, 4, 5, 6, 7, 9
ISTQB CT-AcT v1.0 приемно тестване 2, 3, 8, 10
IIBA BABOK Guide v3 бизнес анализ 1, 2, 4, 5, 10
IREB CPRE Foundation Level 3.3.0 инженерство на изискванията 0, 1, 2, 4
ISO/IEC 25010:2023 модел на качеството 0, 8
IEEE 1012-2024 рамката на V&V 0

Термините се дават на български и в скоби на английски при първата им поява, защото на работа и на изпита ще ги срещнеш на английски.

Идеята

Какво трябва да знаеш

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

Изключението е модулът „Автоматизация“. Там сценариите стават код, и ти трябва един от езиците на сайта до модула „Програми в истинския свят“, където са тестовете на ниво компонент. Картата на курса го казва при модула.

Магазинът е същият като в другите курсове, в евро: продукти, количка, промо кодове, поръчки, доставка и връщане. Правилата му са истински и хората ги бъркат.

Тест

Провери се

1. Коя двойка е вярна?
2. Всички тестове минават, а клиентът казва „това не е, което исках“. Какво е пропуснато?
3. Кой решава какво се прави и в какъв ред?
4. Какво дава курсът спрямо ISTQB CTFL?

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