Testování začíná již na samém začátku projektu. Pokud v týmu pracuje několik lidí, je potřeba nastavit procesy tak, aby byl projekt čitelný a flexibilní. Ve velkých korporacích je běžné, že se projekt roztříští do poboček v různých zemí. K vedení projektu slouží agilní metodika ve formě Scrum. Jednotlivé úkoly se naplánují každému členu týmu na 14 dní tzv. Sprint. Každý den se celý tým sejde na krátkou chvíli, kde každý sdělí, zda postupuje dle plánu nebo mu něco brání v práci. Pokud je některý člen týmu na jiné pobočce v zahraničí nic mu nebrání se připojit přes skype či webex. Celý proces vede Scrum master, který má za úkol výsledky týmu předávat výše a řešit administrativní požadavky týmu (objednání různých převodníků, vývojových kitů, software atd.).  Tím se vývojář nebo tester věnuje pouze technické práci a není rušen „nedůležitými“ činnostmi. Po skončení sprintu se koná review a nové plánování až do té doby, dokud není cíl splněn.

Před samotným testováním se musí naplánovat procesy tak, aby výsledky testování měli k dispozici všichni, kteří je potřebují (vývojáři, manageři, jiní testeři). Musí se zaručit přehlednost jednotlivých testů , aby bylo možné určit, zda testy pokrývají celou požadovanou funkcionalitu. Jelikož se každý sprint přidává nová funkcionalita do zařízení (mění se firmware), musí se otestovat všechny funkce znovu. Nikdo není neomylný a nová funkce může ovlivnit, již stávající otestované funkce.  Proto je nutné co nejvíce testů automatizovat.

Proto se volí nástroj, k tomu určený a my zvolili Testlink, který se nám osvěsčil v jiných projektech. Tento nástroj neslouží ke spouštění jednotlivých testů, ale ke specifikaci a ke správě výsledků každého testu. Pokud jsou všechny testy automatizovány, provedou se všechny naplánované testy v daném sprintu. Tím je zaručeno plné otestování daného zařízení. Podrobné popsání jednotlivých kroků se na první pohled zdá zbytečné. Pokud se nalezne chybné chování je nutné, aby tester co nejpodrobněji popsal, za jakých podmínek se to stalo. Připomínám, že danou funkcionalitu nemusí psát kolega na pobočce, ale například kolega v Montrealu.

Pak stačí v nástroji pro správu chyb (bugů) vložit záznam o chybě, kde se v komentáři vyplní číslo testovacího kroku, které selhalo a kolega si tento krok najde v testlinku a dle popisu si problém nasimuluje u sebe na stole. Pro podrobnou analýzu dat, které se posílají vzduchem přes protokol Zigbee se používá software Ubiqua. Ten dokáže pomocí šifrovacího klíče dekódovat data a přehledně je zobrazovat. Na obrázku je vidět, že zařízení dvakrát odpovědělo stejným telegramem, což byla chyba v dodávaném stacku, která se později opravila.

Někdy se stane, že nalezená chyba je jen nepřesně popsána ve specifikaci a chyba se prohlásí za vlastnost a upraví se testovací krok. Pro správu chyb je několik nástrojů například Jira, TeamForge, kterým se říká Bugs Tracking System.  Výhodou těchto nástrojů je v tom, že se na chybu nezapomene. Tester zavede chybu, vývojář chybu opraví – nastaví příznak na solve - vyřešeno, a tester tuto chybu uzavře až po ověření. Práva v těchto systémech jsou nastaveny tak, že jenom testeři mohou chyby uzavírat.

Na obrázku níže v levé části je podrobné rozdělení testovacích kroků do jednotlivých částí. Například složka „Commissioning“, kde se testuje přiřazení/ odhlášení zařízení do systému (ke kontroléru). Obsahuje celkem 7 testovacich kroků, kde jedním z nich je, že zařízení se přiřadí do systému a po opětovném připojení napájení se zařízení musí samo přihlásit do systému a fungovat dále). Podrobně je to popsáno v pravé části obrázku.

Testlink také plní důležitou roli v přehlednosti a reportování na vyšší místa. Kolik a jaké testy byly v daném sprintu vykonány a s jakými výsledky - Pass/Fail a podrobný report. Výsledky testů se do Testlinku přidávají automaticky, pokud je vše automatizováno nebo výsledek tester vloží ručně. Ne vše lze automatizovat. Každý jednotlivý testovací krok má svůj report, kde je vidět datum, čas, označení firmware (build), výsledek, zda se jedná o automatizovaný test nebo ruční a na jakém zařízení byl test vykonán (platforma Dimmer).

Níže vidíte celkový stav po sprintu. Lze si vygenerovat srovnávací tabulku pro všechny sprinty, kde se může analyzovat stav firmware. Pokud se dostaneme do stavu, kdy se nalezne mnoho chyb (bugů) lze příští sprint naplánovat jen odstranění všech nalezených bugů a posunout implementaci nových funkcí. Pokud je potřeba prezentovat výsledky na vyšší místa, lze vygenerovat grafy ve formě „koláčů“, které jsou oblíbené hlavně u managerů.

Rozdělení testů

• Unit testy – tyto testy si většinou provede vývojář sám. Otestuje si základní funkcionalitu daného produktu a ověří si, zda implementace nové funkce proběhla úspěšně.
• Integrační testy – zde již nastupují testeři, kteří se zaměřují na komunikaci mezi dvěma zařízeními (pokud to zařízení mají umět) nebo na komunikaci mezi jedním zařízením a systémem. Například po odeslání příkazu ON/OFF po Zigbee se sepne/rozepne relé. Zařízení se musí chovat dle definovaných požadavků. Není cílem testu otestovat funkčnost celého systému.
• Systémové testy – Testuje se celý systém dohromady. Například Kontrolér se všemi možnými produkty, které tento kontrolér umí obsluhovat.
• Dlouhodobé testy – jedná se o testy na více dní či měsíců. Například se celý systém cyklicky vypíná a zapíná. Po připojení napájení se musí znovu spárovat a komunikovat.  
• Zátěžové testy – tzv.  stress testy, testuje se maximální vytížení komunikační linky či maximální rychlost spínání výstupu apod.
• Speciální testy – například u stmívače se kontroluje stmívací křivka, LED kompatibilita, o kterém jsme psali v článku „Kompatibilita led žárovek a stmívačů“,  
• EMC testy – jaké základní testy jsou nutné naleznete v článku „Testování zařízení pro inteligentní budovy“. Patří sem také ESD testy- podrobnosti se dozvíte v článku „Odolnost vůči ESD“

Závěrem

V druhém díle se budeme věnovat konkrétnímu systému pro testovaní, kde bude úkolem otestovat funkcionalitu třech typů zařízení pro automatizaci budov, které komunikují po Zigbee – Dimmer, Shutter a Switch (Stmívač, Ovládání žaluzíí a Spínač). Ukážeme si jaké systémy se používají pro samotný testovací proces. Jaký software a hardware jsme použili. Prozradím jen, že se jedná o nezvyklou kombinaci KNX zařízení a měřící karty od National Instruments.