Blackboard Testproces Ellen Peters – CES Information Management

Kenmerken Blackboard Digitale leeromgeving: elk vak een eigen ‘website’ Ook gebruikt voor: aanbieden van opleidingsgerelateerde informatie aan studenten; samenwerken/documenten delen door medewerkers Gemiddeld aantal logins op werkdagen: 5700 (in weekend: 3300) Aantal unieke gebruikers per maand: rond de 10.000 Technisch beheer is uitbesteed aan het bedrijf Blackboard

Koppelingen met andere UT-systemen Blackboard Aanmaak courses + inschrijving docenten Inschrijving studenten in Bb courses Tonen OSIRIS cursusinfo in Bb courses Accounts studenten en medewerkers Accounts Bb gastgebruikers OSIRIS TAP

Soorten wijzigingen die getest worden Soort wijziging Hoe vaak per jaar? Hoeveel werk per keer? Releases van Blackboard Fix/patch voor 1 probleem 5x 1 a 2 uur Cumulatieve patch 2x 12 uur Nieuwe (versie van) building blocks Service pack 1x 80 uur Nieuwe release plugins Bb van externe partijen 3x 16 uur Koppelingen andere UT systemen   Nieuwe versie van koppeling of nieuwe koppeling 1x per 2 jaar 24 – 60 uur Nieuw versie bronsysteem Algemene software die samenwerkt met Blackboard (bijv. Java, Windows, Office) < 1x 4 uur Wijzigingen functionele inrichting (los van releases) 4x 2 – 24 uur

Doel van het testen Bij een upgrade naar een nieuw service pack Nagaan ongewenste wijzigingen in functionele inrichting Nagaan of er geen bugs in zitten met te grote impact Bij gevonden bugs: nagaan of er een workaround voor gebruikers is (reparatie vrijwel nooit mogelijk voor invoering release) Nagaan exacte werking nieuwe functies; plus besluit wel/niet beschikbaar stellen en nagaan bijbehorende wijzigingen in functionele inrichting Doel bij testen van de zelf ontwikkelde koppelingen: nagaan of het werkt zoals beschreven in het functioneel ontwerp en zo nee, de fouten laten herstellen.

Bestuderen release notes Testplan maken / bijwerken Het eigenlijke testproces Bestuderen release notes Testplan maken / bijwerken Kloon laten maken naar acceptatie Testen en wijzigen kloon Testcases maken Nieuwe release laten installeren Testen Rapporteren bugs bij leverancier Testen workarounds en / of patch Go / No go Invoering op produktie Testen voor vrijgave Vrijgave aan gebruikers

Best practices en valkuilen Standaard testplan Standaard Excel file voor notatie testresultaten Als je zelf een functioneel ontwerp moet maken: al nadenken over testcases- en acties helpt om specificaties volledig uit te werken Valkuilen: Vergeten bij planning rekening te houden met onderhoud op gekoppelde systemen (Sommige) testacties / resultaten niet noteren omdat ‘je ze toch wel onthoudt’

Best practices en valkuilen