Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 9 minutes
Eerder heeft Bits&Chips al ruimschoots aandacht besteed aan de enorme inspanning die Philips moest leveren voor de tijdige vrijgave van zijn digitale platte ATSC-tv voor de Amerikaanse markt. Voornamelijk is stilgestaan bij het belang hiervan voor de Eindhovense elektronicareus en bij de ingezette overwerkmode. In dit artikel geven Harro Jacobs, Edwin van der Velden en Edwin Witvoet van LogicaCMG inzicht in hoe de softwarevalidatie en vrijgave is ingericht en welke processen en activiteiten cruciaal zijn gebleken voor de snelste route naar productierijpe software.
Het Innovation Center Eindhoven (ICE) van Philips Semiconductors draaide begin dit jaar overuren om de embedded software voor een digitale televisie af te leveren aan Philips Consumer Electronics. Het project was cruciaal. De CE-poot van het Eindhovense concern stond voor de massa-introductie van een grote platte ATSC-televisie op de Amerikaanse markt. ATSC is de Amerikaanse standaard voor digitale tv-uitzendingen. De markt hiervoor belooft te gaan exploderen in de VS.
ICE was verantwoordelijk voor de ontwikkeling van een groot aantal softwaresubsystemen, integratie en validatie, en het algehele projectmanagement van het zogenaamde TV810-platform (interne codenaam JaguarATSC). Philips Consumer Electronics gebruikt dit platform als basis voor een nieuwe generatie televisies en nam de product-integratie en -industrialisatie op basis van dit platform voor zijn rekening.
De kern van het projectmanagementteam bestond uit de programmamanager, de programma-architect, de integratiemanager en de validatiemanager. Binnen Validatie waren twee teamleiders aangewezen voor de aansturing van de twee validatieteams. De taken van deze teams waren het definiëren van de testsuite, het testen van de platformreleases, het rapporteren van de status en het definiëren van doelstellingen.
Een project onder grote druk met een harde deadline heeft behoefte aan snelheid, doelgerichtheid en gerichtheid op meetbare resultaten. Daarom werden alle kernactiviteiten binnen het gehele project in een strikte heartbeat gepland en uitgevoerd, zowel in ontwikkeling, integratie als validatie. Het strikte wekelijkse ritme van de heartbeat zorgde voor voorspelbaarheid. Medewerkers wisten precies wanneer ze wat moesten doen en konden hun werkzaamheden zodoende optimaliseren.
Validatie heartbeat
Binnen Validatie ontstond een goed geoliede machine rondom een aantal kernactiviteiten. Dagelijks vanaf acht uur ‘s ochtends voerden testers een vaste reeks regressietests uit in combinatie met een variabele serie, toegespitst op het valideren van de nieuwe functionaliteit. Om half tien volgde een terugkoppeling naar Integratie voor eventuele corrigerende maatregelen. Progressie en regressie werden vastgelegd en gerapporteerd.
Elke vrijdag werd een uitgebreide releasetest uitgevoerd, waarna het team met de klant besprak om de release al dan niet te accepteren. Hierover later meer.
Elke maandag tijdens de reporting out werden de architecten en integrators geïnformeerd over de testresultaten en kwamen de nieuwe doelstellingen op tafel. Welke problemen kregen de hoogste prioriteit? Deze directe terugkoppeling was van groot belang om snelheid te maken en de doelstellingen te halen.
Van maandag tot en met vrijdag werd de testsuite uitgebreid voor een zo volledig mogelijke dekking van de requirements. Opmerkelijk was de enorme hoeveelheid denkbare combinaties en systeemtoestanden. De tv ondersteunt Dual Window, waarbij het scherm links en rechts verschillende bronnen toont (bijvoorbeeld een dvd-film links en een sportuitzending rechts). Figuur 1 geeft een overzicht van de mogelijke combinaties. Per combinatie zijn er weer verschillende mogelijkheden voor het type audio of signaalcodering. Werken alle eigenschappen zoals helderheid en contrast? Moet er wel of geen ondertiteling bij en in welke taal? Deze combinatorische explosie leidt tot een bijna oneindig aantal mogelijkheden, die niet allemaal kunnen worden getest. Met de (on)afhankelijkheden van de diverse functies in hun achterhoofd hebben de architecten een behapbare doorsnede gekozen.
Ook is veel aandacht besteed aan verbindingen tussen de tv en diverse randapparatuur. Met name de nieuwe standaard HDMI (High Definition Multimedia Interface) voor het doorgeven van de hoge beeld- en geluidskwaliteit van bijvoorbeeld een dvd-speler aan een tv is uitgebreid getest met veel verschillende voor HDMI geschikte dvd-spelers.
Elke avond werden duur- en stresstests gestart op ongeveer twintig opstellingen, waarvan ‘s ochtends de resultaten werden verzameld en gerapporteerd. Zo maten de testteams voor elke platformrelease de mean time between failure (MTBF), waarbij het testprogramma een willekeurig zappende gebruiker nabootste.
Een aantal ervaren ontwikkelaars in de VS testten iedere wekelijkse release met live uitzendingen. Dit omdat de labcondities niet overeenkomen met de praktijksituatie: de ultieme infrastructuur. De live uitzendingen zijn meestal niet volledig volgens specificatie. Natuurlijk moet de tv hier wel goed mee omgaan. De software werd dus aangepast voor correcte afhandeling in dit soort situaties.
Wekelijks (voor het eind van de zaterdag) kreeg de projectleiding een voortgangsrapportage met onder meer de status van de laatste release, performance to schedule en de risico‘s.
Releasetest
Op wekelijks basis kwamen platformreleases beschikbaar. Behalve dat de klant dit verwachtte, was dit releaseritme ook intern van cruciaal belang om het platform stap voor stap te kunnen verbeteren. Om goed inzicht te krijgen in de kwaliteit van deze releases werd een uitgebreide releasetest ontwikkeld van ongeveer 2500 testcases. Pas na een bewezen kwaliteitsniveau gebruikte de klant een platformrelease voor product-integratie, om regressie in het product te voorkomen. De uitvoer van de releasetest lag op het kritieke pad. Dit was voor ons reden om dit erg goed te organiseren. Het was welhaast een militaire operatie.
Eén persoon was verantwoordelijk voor de voorbereiding van de releasetest. Deze bestond uit het plannen van de tests en de testopstellingen over de test-engineers. Het bleek geen makkelijke opgaaf, omdat er veel verschillen waren in de testopstellingen. Enerzijds vanwege schaarse resources. Zo waren niet alle opstellingen voorzien van de laatste engineeringsamples en ook randapparatuur was beperkt beschikbaar vanwege de aanzienlijke kosten. Anderzijds waren de opstellingen vaak defect en moesten er regelmatig hardwarepatches worden toegepast. Elke testopstelling werd de avond voor de releasetest op orde gebracht, inclusief randapparatuur en de nodige software.
Omdat de testuitvoer op het kritieke pad lag, werd het hele validatieteam erbij betrokken, soms zelfs versterkt met mensen van het integratieteam. Om met zo‘n twintig personen goed te kunnen starten, werd voorafgaand aan de releasetest, om acht uur ‘s ochtends, een kick-off gehouden. Tijdens deze aftrapmeeting werden de planning en eventuele details over sommige opstellingen besproken. Daarna lichtte de architect iedereen in over de verwachte status. Hij noemde waar belangrijke wijzigingen waren doorgevoerd, zodat daar extra aandacht aan kon worden gegeven. Ook kon hij al melden welke problemen opgelost zouden moeten zijn, of er juist nog inzaten, zodat iedereen met deze bagage efficiënter aan de slag kon.
Na de kick-off gingen de testengineers aan de slag. Continu werd de voortgang van iedereen in kaart gebracht. De planning werd waar mogelijk gedurende de ochtend aangepast, zodat onverwachte problemen niet tot vertraging van de releasetest hoefden te leiden. Het doel was klaar te zijn voor één uur ‘s middags.
De testengineers noteerden nieuwe bevindingen op gele memootjes. Daarnaast verwerkten ze de testresultaten in elektronische testformulieren. Een kernteam bestaande uit de validatiearchitect en de key-integratoren bestudeerden alle bevindingen. Het werken met memootjes bleek handig, omdat ze efficiënt konden worden gegroepeerd en verdeeld. Zo kreeg het kernteam snel een indruk over de platformstatus en kon het met zijn achterban de belangrijkste bevindingen direct oppakken. Ten tweede werd zo voorkomen dat er meerdere rapporteren voor reeds bestaande problemen werden ingediend.
Om precies één uur ‘s middags begon een consolidatiemeeting met alle test-engineers en de validatiearchitect. Tijdens deze bijeenkomst namen ze de memootjes door, zodat ze meer inzicht verkregen in de ernst van de problemen. Omdat zoveel testexpertise was vertegenwoordigd, was het eenvoudig om goede acties te definiëren en te verdelen om de gevonden problemen verder te analyseren.
Daarnaast konden we al tijdens deze meeting een aantal views op de testrapportage inzien. De resultaten werden besproken en vergeleken met de indruk die de testengineers over het platform hadden. Dit gaf een goede onderbouwing aan de resultaten zodat we met meer zekerheid aan de definitieve rapportage konden werken.
Een bijkomend effect van de consolidatiemeeting was dat iedereen heel betrokken was bij de belangrijke taak van die dag. Er werd echt samengewerkt aan een rapportage voor de klant.
Na de consolidatiemeeting werden de gevonden problemen verder geanalyseerd, zodat goede en volledige probleemrapporten (PR‘en) konden worden ingediend. De validatiearchitect reviewde elke PR voordat deze werd ingediend, enerzijds om detailinzicht te krijgen in de platformkwaliteit, anderzijds om het kwaliteitsniveau van de PR‘en te waarborgen.
Naast het indienen van nieuwe probleemrapporten, valideerden we ook opgeloste PR‘en. Het integratieteam leverde de lijst aan met geïntegreerde PR‘en. Deze beschouwde ontwikkelteams op componentniveau weliswaar als opgelost, maar alleen validatie op platformniveau kon de zekerheid geven waar de klant om vroeg. Het doel was om alle PR‘en ruim voor vijf uur ‘s middags te hebben verwerkt. Helaas lukte dit niet altijd, zodat vaak de zaterdag nog werd gebruikt om dit af te ronden.
Diezelfde dag om vijf uur volgde de checkpointmeeting met de klant. Ter voorbereiding van dit overleg werd alle rapportage op orde gebracht. Ook de laatste bevindingen van de key-integratoren, van de acties die tijdens de consolidatiemeeting waren gedefinieerd en van de PR-verwerking werden vastgelegd.
De klant was erg tevreden met deze volledige rapportage. Niet altijd was hij even blij met de kwaliteit van het platform, maar het inzicht dat hij in de kwaliteit had, bleek voor hem voldoende om onze releases telkens weer te accepteren.
Rapportage
De basis van de rapportage startte bij het verzamelen en opslaan van de testresultaten. Dagelijks werden er ongeveer 750 tests uitgevoerd en wekelijks zo‘n 2500 bij de releasetest. In totaal moesten we dus ongeveer 6000 testresultaten per week verwerken.
Om dit gestructureerd aan te pakken hadden we gekozen voor een centrale database met daarin de basisgegevens over elke test, de engineer die de test uitvoerde en de tijd die hij daarvoor nodig had. Daarnaast werden per dagelijkse baseline de resultaten van elke uitgevoerde test opgeslagen in afzonderlijke kolommen.
Het was van groot belang dat alle resultaten in een database stonden en niet gedistribueerd over verschillende bestanden. Vanuit de onbewerkte testresultatendata was het mogelijk views te genereren voor de rapportage. Het was ondoenlijk en onbeheersbaar om vanuit meerdere bestanden een consistente rapportage te maken. Ook speelde mee dat de tijd voor het maken van het verslag erg kort was op de dag van de releasetest, waardoor de gegevens wel centraal moesten worden gearchiveerd.
Op basis van deze testresultaten ontwikkelden we een aantal views. Het zogenaamde dashboard gaf zicht op de testresultaten die op hoog niveau de status van het platform per feature aangeven. Er was een view met de progressie en regressie van de release ten opzichte van vorige versies. Ook maakten we een overzicht met het aantal tests dat slaagde of faalde, inclusief doelstellingen. Deze view geeft inzicht in het verloop van het percentage geslaagde tests, afgezet tegen de gestelde doelen. Ten slotte waren er overzichten met het aantal gevonden probleemrapporten per release, en per PR het aantal testcases dat erdoor faalde.
Het bleek dat iedere fase in het project een specifieke view nodig had. Aan de start van een maturity-fase had het project een gedetailleerd overzicht nodig. Naarmate het project vorderde en deze overzichten geen informatie meer gaven waar de problemen geconcentreerd waren, werden andere views interessanter.
Het kernteam droeg de validatierapportage in zowel programma- als integratiemanagement. Dit was noodzakelijk om het project goed te kunnen sturen en plannen. Even zo belangrijk was dat de rapportage werd teruggekoppeld aan de belanghebbenden, in het bijzonder het integratieteam en ons eigen validatieteam.
Onze rapportage werd omgezet in duidelijke doelen en prioriteiten. Dit gold voor het validatieteam (maken van nieuwe of aanpassen van bestaande tests) en het integratieteam (het oplossen van blokkerende problemen). Interessant hieraan was dat het validatieteam ook werd aangesproken op het halen van de doelstellingen en zodoende proactief de voortgang in integratie en development op dagelijkse basis volgde.
Een voorbeeld van een view waarmee duidelijke doelen voor de volgende release gesteld konden worden, is het overzicht van problemen met het aantal testcases dat zij blokkeren. Het doel van deze grafiek is het weergeven van de belangrijkste problemen die de we nog met onze testsuite konden vinden. Elke week na de releasetest kreeg het integratieteam de opdracht de topvijf van deze lijst op te lossen voor de volgende release. Dit was een concreet en haalbaar doel, waardoor we grote stappen konden zetten in het aantal tests dat passeerde. De doelen werden niet alleen wekelijks gezet, maar ook dagelijks naarmate het project vorderde. Aan het begin van een integratiecyclus stelde het integratieteam per dag een doel welke problemen met dagelijkse releases/baselines opgelost moesten zijn.
Conclusies
Het blijkt dat ondanks de enorme inspanningen van het validatieteam, het nog vaak voorkwam dat belangrijke fouten pas werden gevonden tijdens veldtests. Op veel van die problemen was het niet mogelijk te anticiperen omdat exacte veldcondities nooit volledig in het lab waren te simuleren.
Verder laat het artikel zien dat alleen gestructureerd testen niet voldoende is. Een strikte heartbeat, een goede organisatie van de testresultaten en daaruit afgeleide doelstellingen, en een goed inzicht in de mogelijkheden en onmogelijkheden van de testdekking zijn alle nodig voor een geslaagde validatie.
Het TV810-project is succesvol afgerond. De productie van de tv‘s draait nu op volle toeren en de verkoop door de grote Amerikaanse winkelketens komt goed op gang.
