Tegenwoordig is het allemaal cloud, maar een aantal jaren geleden hadden we het nog over software oriented architecture (soa) en daarna software as a service (SaaS). Bedrijven als Salesforce en Atlassian zijn vooral met het laatste groot mee geworden. Maar wat is nu eigenlijk SaaS en wat heeft dit voor invloed op het werk van een software tester?
Saas is het online aanbieden van software tegen een bepaalde fee. In de cloud is SaaS de applicatielaag boven op de platform as a service (PaaS)- en infrastructure as a service (IaaS)-laag. De software is voor elke gebruiker gelijk en het is schaalbaar, in tegenstelling tot de application service provider (asp). Het werkt niet met licenties (zoals asp), maar op basis van fees (abonnement).
Dit maakt het voor klanten makkelijker om over te stappen naar een andere leverancier en daarom is het van belang voor de SaaS-leverancier snel en kundig issues op te lossen buiten de reguliere releases om. Betrokkenheid met de klant is dus van belang voor de SaaS-leverancier.
Omdat de software in principe gelijk is voor elke klant, kan een software testteam door middel van gestructureerde regressietesten (liefst automatisch) snel verifiëren of alles nog naar behoren werkt (of gaat werken). Hierdoor kan het proactief het development-team waarschuwen als er issues zijn, voordat de klant het ziet. Vaak worden hierbij vooral de interfaces getest die door middel van webservices met elkaar communiceren. Vanwege de schaalbaarheid spelen performancetesten ook een belangrijke rol.
En dan hebben we het nog niet gehad over security-testen. Geen enkele SaaS-leverancier wil in de krant wegens lekken in zijn software. Er wordt dus al wat gevraagd van een testteam om de kwaliteit van een SaaS te waarborgen.
De SaaS levert een bepaalde online dienst, waarbij domeinkennis onontbeerlijk is, maar daarnaast ook technische (XML, web, performance, security et cetera) kennis noodzakelijk is om aan te geven waar het mis gaat. ‘Het werkt niet!’ zeggen gaat niet meer op voor een tester.
Maar daarnaast moet een tester ook duidelijk weten wat de eisen zijn van de klant. Een goede technische oplossing wil nog niet zeggen dat het functioneel werkt. Weten wat de kant wil is een must om er zeker van te zijn dat de software doet wat het moet doen.
Kortom, een unieke kans voor een software tester om te laten zien dat hij zijn vak verstaat!
Cordny, dude, er gaat nogal wat mis in je opinie.
SOA staat niet voor software oriented architecture maar voor *service* oriented architecture. Ofwel een architectuur die veel gestoeld is op het gebruik van Application Programming Interfaces (API’s) en in mindere mate Command Line Interfaces (CLI’s). Da’s een totaal ander concept. SOA kun je wat vergelijken met PAAS, alleen hoeft een SOA niet per se cloud gericht zijn, is zelfbediening geen vereiste en gaat het niet om wel of niet betalen per gebruik.
“In de cloud is SaaS de applicatielaag boven op de platform as a service (PaaS)- en infrastructure as a service (IaaS)-laag.”
– Zo wordt het vaak getekend en zo onthouden mensen het wellicht makkelijk… alleen is het niet waar. SaaS hoeft helemaal niet op een Platform as a service gebouwd te worden. SaaS doet het ook prima op een hosted omgeving of direct een Infrastructure as a service.
Dat het wel voorkomt betekent niet dat het altijd zo is.
“De software is voor elke gebruiker gelijk” is ook niet per se waar en een verkeerde aanname. Zo kun je JIRA in afnemen als SaaS, maar vervolgens kun je met extensies, koppelingen en workflows behoorlijke veranderingen aan brengen zodat het niets eens meer hetzelfde eruit ziet.
“Dit maakt het voor klanten makkelijker om over te stappen naar een andere leverancier”
– SaaS maakt het vaak juist niet makkelijker over te stappen naar een andere leverancier omdat SaaS nu juist een punt oplossing is (die je met een SOA kunt extenden).
Met Open source software op een IaaS kun je wel makkelijker overstappen, maar SaaS vaak dus niet. Je kunt niet van Salesforces overstappen op zeg bijvoorbeeld Microsoft Dynamics. Of van Dropbox naar Sharepoint online.
“Betrokkenheid met de klant is dus van belang voor de SaaS-leverancier.”…. Hmm, zelfs dat is discutabel. Salesforce luisterd wel naar de markt, maar naar jou als klant? Niet echt.
Maar als je het hebt over testers en saas en saas en klant.. dan bedoel je de relatie van een tester naar de saas leverancier? De klant in jouw stuk is dus de SaaS aanbieder?
Ik heb nogal wat aan te merken en da’s jammer omdat je namelijk in mijn ogen gewoon goed in je vak bent als (saas) tester. Maar hier zie ik nog wat verbeterpunten 😉
Saas als “unieke kans” voor software tester en vervolgens een opsomming van onjuistheden (zie reactie Henri), algemeenheden en open deuren : Automatische testen hebben altijd voorkeur. In vroeg stadium defects vinden ook. Security. Domeinkennis. Niet echt Saas specifiek he. Ja, requirements dat je die weet, altijd handig. Beetje aangeven wat er precies misgaat ipv doetutnie conclusie. Tja, als je toch bezig bent..
Weten wat de klant wil, lezen we. Die wil geen onzin, geen algemeenheden en geen open deuren. Die wil een QA expert.
Excuses heren,
Dit was geschreven als een 13 in een dozijn-artikel. Met zelfs verkeerde uitleg van afko’s. Iets te enthousiast..
Volgend artikel wordt weer een inhoudsartikel met minder marketing en meer QA. Schoenmaker, blijf bij je leest.
Bedankt voor de feedback, die wordt gewaardeerd.
No worries Cordny, van jou kunnen we het hebben 🙂
Als we zo gaan beginnen is er geen lol meer aan, he. Ik verwacht volharding in je standpunt en een hakken-in-zand houding, ook al voel je aan dat je er op sommige punten wellicht naast zit. Voor voorbeelden, zie de reacties van Dekkinga 😉
No worries Felix,
bij het volgende artikel
ben ik weer van de partij
om de discussie aan te gaan.