Blackboard Testproces

Presentatie over: "Blackboard Testproces"— Transcript van de presentatie:

1 Blackboard Testproces
Ellen Peters – CES Information Management

2 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: (in weekend: 3300) Aantal unieke gebruikers per maand: rond de Technisch beheer is uitbesteed aan het bedrijf Blackboard

3 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

4 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

5 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.

6 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

7 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’

8 Best practices en valkuilen