Hoe we testen bij Open-i?

Hoe we testen bij Open-i? Praktijkverhaal van een van onze testconsultants 

Adjai Bahorie, 41 jaar en ruim 10 jaar als ICT-er in verschillende functies; functioneel beheerder tester, testcoördinator en testspecialist legt graag uit hoe we testen bij Open-i. Bij Open-i in dienst als testconsultant en verbonden aan project “Fine 3.0”. In dit project wordt de Oracle Forms omgeving vervangen door een compleet opnieuw ontworpen en ontwikkelde APEX 5.0 applicatie met 100+ schermen. Met recht een uniek project te noemen.

Zijn ervaring met FINE 3.0 en visie op “Wat is testen eigenlijk en hoe testen we bij Open-i?

Testen van software is simpel gezegd “het vaststellen in hoeverre de software aan de eisen voldoet”, klinkt eenvoudig maar is vaak uitdagend.

Voor FINE 3.0 bestond FINE 2.0, deze applicatie voor de energiebranche is gebouwd op een complexe Oracle-database met een enorme hoeveelheid Forms schermen. Omdat flexibiliteit het unique selling point is van FINE is het systeem nogal uitgebreid en kent het veel mogelijkheden. Deze zijn bij aanvang van FINE 3.0 in kaart gebracht en op basis daarvan is een aanpak gedefinieerd. Ondanks dat het eerste stadium van het project een interne ontwikkeling is, is er toch gekozen om een testplan en een full time tester bij de ontwikkeling te betrekken. In dit geval in een 1 op 4 verhouding. 1 Tester per 4 ontwikkelaars.

In dit project is geen sprake van een simpele ombouw van Forms naar Apex schermen maar is een nieuwe opzet gehanteerd die uitgaat van het gebruikersperspectief. In FINE 2.0 lag de nadruk op maximale configureerbaarheid van de applicatie terwijl in 3.0 de focus ligt op processen. Vragen als “Hoe kan de gebruiker zo snel en accuraat mogelijk dit proces uitvoeren?” en “Is dit scherm eenvoudig genoeg om iemand snel in te kunnen werken?” voeren de boventoon zonder aan uiteindelijke flexibiliteit in te willen leveren. De opdracht die ik meekreeg was dus niet alleen het technisch- en functioneel testen maar ook op gebruikersvriendelijkheid. Als pure tester een zeer lastige opgave, als voormalig functioneel beheerder en vooral energiebranche specialist ook een hele leuke.

Hoe realiseer je een succesvol testtraject?

In een later stadium worden de gebruikers overleggen gebruikt om input te krijgen op FINE 3.0 en de kunst voor mij is om het zodanig te hebben getest dat er zo min mogelijk verbeterpunten door gebruikers aangedragen hoeven te worden. Om er een succes van te maken moet je de juiste mensen aan elkaar koppelen, met de juiste instelling en juiste vragen stellen aan elkaar, maar hoe doe je dit allemaal als tester?  Voor FINE 3.0 is bewust gekozen voor een Agile aanpak d.m.v. met elkaar te communiceren en elkaar op te zoeken voor het juiste verwachtingsmanagement. Dit is wel een héél lastig/uitdagend punt om met ontwikkelaars te realiseren die het liefst alleen maar willen ontwikkelen en zo min mogelijk communiceren en documenteren. Vandaar de keuze voor Agile, korte lijnen en direct schakelen maar toch op een gestructureerde manier testen.

Uiteindelijk kreeg ik na elk ontwikkeld onderdeel de vraag om te testen, dit gebeurde zowel technisch als functioneel en vanuit het gebruikersoogpunt. In het begin was dit onwennig voor de ontwikkelaars omdat een bevinding niet altijd een technische fout als oorzaak had maar soms ook cosmetisch. Na verloop van tijd begonnen de ontwikkelaars te wennen aan deze manier van werken en nadat enkele gebruikers bij klanten ook positieve feedback gaven werd ook het belang hiervan ingezien.

Ben je getriggerd of nieuwsgierig geworden? Je bent van harte welkom, neem contact met ons op en maak kennis met ons en Fine 3.0 in een innovatieve Agile omgeving…

Open-i staat bekend om

Ons laatste nieuws

Open-i zorgt voor oplossingen die bedrijven en instellingen verder helpen.
Om hierin meerwaarde te kunnen verzorgen zijn we altijd bezig met nieuwe ontwikkelingen.

nieuwsarchief

waar kunnen we mee helpen?

x