De afkorting OTAP staat voor Ontwikkeling, Test, Acceptatie en Productie. De OTAP-methode wordt veel gebruikt voor softwareontwikkeling. Het stelt je namelijk in staat om software te ontwikkelen en testen zonder dat de eindgebruiker daar iets van merkt. Wel zo prettig en veilig! We leggen je graag uit hoe de OTAP-straat precies werkt en hoe en waarom wij de OTAP-methode toepassen bij appontwikkeling.
Wat is OTAP?
OTAP is een pad van vier fasen die je doorloopt als je software ontwikkelt: Ontwikkeling, Test, Acceptatie en Productie. De “OTAP-straat” wordt dat ook wel genoemd. Pas bij fase 4 gaat de software daadwerkelijk live. Meestal gebruik je voor elke fase een aparte software-omgeving (dus de ontwikkelomgeving, testomgeving, acceptatieomgeving en productieomgeving). Soms zijn de testomgeving en acceptatieomgeving gelijk.
Software ontwikkelen of testen gebeurt dus in een aparte digitale omgeving. De eindgebruiker ziet hier niets van. De opdrachtgever krijgt pas iets te zien op het moment dat er daadwerkelijk wat ontwikkeld is. Ook het tonen van voorbeelden gebeurt in een aparte omgeving.
Alle wijzigingen die de Developer of Designer aanbrengt, zijn pas na het doorlopen van alle fases (en na goedkeuring van de opdrachtgever) in de daadwerkelijke app zichtbaar.
OTAP wordt veel gebruikt in softwareontwikkeling, maar je kunt het ook buiten de softwarewereld gebruiken. Het gaat er dan vooral om dat je diverse fases doorloopt voordat je iets op de markt brengt. Je ontwikkelt eerst het product of een deel ervan, gaat dat dan testen bij gebruikers, legt het vervolgens aan de klant voor en gaat het product pas daarna implementeren.
Kortom: het product ziet pas het levenslicht zodra het uitgebreid is getest en zodra de opdrachtgever er een klap op heeft gegeven.
Waarom werken met de OTAP-straat?
Werken volgens de OTAP-straat is heel belangrijk als je software ontwikkelt. Je wilt niet dat de eindgebruiker last heeft van tests of een onvolledige versie van de software te zien krijgt, inclusief mogelijke bugs. Door de OTAP-methode hebben Developers de ruimte en tijd om hun werk te doen en functies uitgebreid te testen voordat ze live gaan. Ook kan de opdrachtgever hierdoor feedback geven op de app voordat deze in gebruik wordt genomen.
Voorbeeld
Stel: jouw Developer gebruikt geen OTAP en gaat een nieuwe versie van je app ontwikkelen. De app heeft al duizend gebruikers. Er moet een nieuwe functie bij de app komen, namelijk dat gebruikers er ook foto’s mee kunnen versturen.
Terwijl de Developer die functie aan het ontwikkelen bent, stromen de klachten van gebruikers binnen. De app is traag. Er staat wel een knopje om foto’s te versturen, maar die functie werkt nog niet. Een bepaalde pagina ligt eruit. Logisch. De Developer is aan het werk en moet uitvinden hoe hij deze functie op een werkende manier kan toevoegen. Niet alles zal meteen perfect werken. Dat is niet erg, zolang de eindgebruiker er maar geen last van heeft. Daarom is werken volgens de OTAP-methode zo belangrijk.
Hoe passen wij de OTAP-methode toe?
Bij Iconica gebruiken we de OTAP-methode voor het ontwikkelen van maatwerksoftware, zoals apps en webapps. De OTAP-methode sluit goed aan op een visie waar wij sterk in geloven: Design Thinking. Dit betekent dat je software ontwikkelt met oog voor de wensen en behoeften van de gebruiker en dus ook snel iets gaat testen.
Daarnaast heeft de OTAP-methode veel overlap met Kanban: een managementtheorie die structuur geeft aan onze processen. Het houdt in dat we elk project in concrete brokjes werk verdelen en die aan de juiste professional uit ons en/of jouw team toekennen. Zo weet iedereen wat wanneer moet gebeuren.
Er zijn standaard meerdere versies van een app. Voor elke versie doorlopen we de OTAP-straat opnieuw. We beginnen met een Minimum Viable Product (MVP). Dat is de eerste versie die goed genoeg is om in de App Stores te zetten en die in elk geval de vereiste functionaliteiten bevat. Daarna komen er een tweede versie, een derde versie, etc. In de volgende versies voegen we extra functionaliteiten toe en kunnen we de app op basis van inzichten uit gebruikerstests en voortschrijdend inzicht verder finetunen.
> Lees ook: App ontwikkelen | Zo gaan we van een idee naar een eerste versie (MVP).
Ontwikkeling
Eerst ontwikkelen we de software of een onderdeel daarvan in de ontwikkelomgeving. Ons team van Developers realiseert daarvoor de gewenste functies. De Designers maken daarvoor bovendien een passend ontwerp. We spreken van tevoren met de opdrachtgever af wat we gaan doen en laten tussentijds natuurlijk alvast iets zien. Is bijvoorbeeld het design niet helemaal naar wens? Dan kunnen we vlot bijsturen.
Ontwikkeling vindt bij ons achter de schermen plaats. Terwijl wij hieraan werken, heb jij er geen last van. Je huidige website of app kan bijvoorbeeld gewoon blijven draaien. Alle wijzigingen die we aanbrengen, zijn alleen in de ontwikkelomgeving te zien.
Testen
Vervolgens zetten we de ontwikkelde versie van de app om naar een versie die we kunnen testen. Dat doen we op een aparte testomgeving. Deze lijkt zoveel mogelijk op de daadwerkelijke omgeving van de app. Het verschil is dat de testomgeving niet zichtbaar is voor de eindgebruiker, en dat we dus kunnen testen zonder dat iemand daar in de daadwerkelijke app iets van merkt.
> Lees ook: Een app testen, hoe gaat dat in zijn werk?
Soms testen we de hele app, soms alleen een specifieke functie. Denk bijvoorbeeld aan de inlogmogelijkheid of een betaalfunctie. We testen daarbij of het ontwikkelde product naar behoren en naar verwachting werkt. Ook doen we technische tests, zodat we zeker weten dat bijvoorbeeld een knopje doet wat het moet doen.
Na een aantal interne tests geven we de opdrachtgever een testversie van de app. Daarnaast gaan we de app testen bij eindgebruikers.
Het testen wordt gedaan door Developers of UX Designers uit ons team. Soms is de Scrum Master (een beslissingsbevoegde vanuit de opdrachtgever) degene die de tests doet.
Het is voor ons prettig om te kunnen testen in een testomgeving. Zo kunnen we bijvoorbeeld met een nep-transactie testen of een iDEAL-functie goed werkt, zonder dat iemand daarvoor daadwerkelijk geld moet overmaken. De eindgebruiker merkt daar niets van en kan de huidige versie van de software gewoon blijven gebruiken.
Acceptatie
Zodra de app succesvol door de interne tests heen is gekomen, leggen we deze aan de opdrachtgever voor. Dan volgt de acceptatiefase. Soms gebruiken we hiervoor een aparte acceptatieomgeving, soms gebeurt dit in de testomgeving.
De opdrachtgever gaat deze versie van de software uitgebreid doorlopen en proberen, en geeft uiteindelijk aan of deze versie goed genoeg is. De Product Owner bepaalt voor de opdrachtgever of deze versie van de app akkoord (“geaccepteerd”) is of niet. Zodra de opdrachtgever akkoord is, kunnen we de app in productie nemen.
Wordt deze versie van de app nog niet geaccepteerd? Dan gaat de software of een deel van de software terug naar de ontwikkelfase om de aandachtspunten te verhelpen. Er volgen dan opnieuw tests, gevolgd door een nieuwe acceptatieronde.
Productie
Na de definitieve goedkeuring van de opdrachtgever gaat de app naar de productieomgeving. Oftewel: we gaan de app publiceren in de App Store en daarmee live zetten. In de productiefase publiceren we dus de versie van de software die de eindgebruiker ziet en gebruikt.
Zodra een app naar de productieomgeving gaat, wordt de app in de App Store daarmee geüpdatet. De versie in de productieomgeving is wat de eindgebruiker te zien krijgt. Cheers, mijlpaal 1 is behaald!
Koffie drinken?
Meer weten over onze diensten als ontwikkelaar van maatwerksoftware? Bel, app of mail ons. We drinken graag vrijblijvend een (digitale) kop koffie met je.
T: 0314 – 78 25 67
Of stuur ons een WhatsApp-bericht.