Het portaal werkt is geen duidelijke opleverafspraak. Een ontwikkelaar kan bedoelen dat de homepage opent, terwijl u verwacht dat medewerkers veilig bestellingen kunnen exporteren. Maak vooraf acceptatiecriteria: concrete eisen waarmee u samen controleert of het afgesproken resultaat is geleverd. De testopzet hieronder is een voorstel voor uw project, geen wettelijke standaardtermijn of verplichte technische norm.
Begin met een gebruiker en een handeling
Schrijf per belangrijke functie wie iets doet, met welke invoer en welk resultaat. Benoem ook wat juist niet mag. Een medewerker mag bijvoorbeeld de eigen bestellingen bekijken, maar geen gegevens van een andere vestiging. Noteer de omgeving: browsers, apparaten, koppelingen en testgegevens. Vraag de ontwikkelaar welke onderdelen buiten de opdracht vallen. Zo ontdekt u verschillen vóór het bouwen.
Vermijd woorden zoals snel en gebruiksvriendelijk zonder verdere uitleg. U kunt samen een meetbare verwachting kiezen, met de omstandigheden waaronder u meet. Spreek bijvoorbeeld een bestandsgrootte en aantal testorders af. Zonder die omstandigheden kunnen twee juiste metingen toch verschillende uitkomsten geven. Kies waarden die bij uw werk passen en technisch haalbaar zijn.
Voorbeeld: drie tests voor een bestellingenportaal
| Test | Invoer of situatie | Afgesproken resultaat |
|---|---|---|
| Toegang | Testmedewerker van vestiging A logt in. | Alleen orders van A zijn zichtbaar, ook via een directe link. |
| Export | Tien verzonnen orders, waarvan één geannuleerd. | Negen regels met de gezamenlijk gekozen kolommen. |
| Koppeling valt uit | Boekhoudsysteem is tijdelijk onbereikbaar. | Een duidelijke foutmelding; geen dubbele order na opnieuw proberen. |
Dit zijn verzonnen afspraken, geen complete beveiligingsaudit. De tabel geeft beide partijen dezelfde proef. Bewaar de gebruikte softwareversie, testgegevens en uitkomst. Als de export negen regels bevat maar een bedrag ontbreekt, is de test niet geslaagd. Voeg dit toe aan de bevindingen in plaats van alleen te schrijven dat de export stuk is.
Spreek af wie test en wat een fout betekent
Kies een contactpersoon die bevindingen verzamelt en bevoegd is om namens u een resultaat te beoordelen. Spreek een haalbare testperiode en meldroute af. Maak onderscheid tussen een fout tegen de afgesproken eis en een nieuwe wens. Leg ook vast wat een kleine fout doet met acceptatie, betaling en herstel. Een demonstratie bij de ontwikkelaar vervangt uw afgesproken tests niet vanzelf.
Stel dat u na de test ook een grafiek per kwartaal wilt. Die stond niet in de exportafspraak. Bespreek dan als aparte wijziging de prijs, planning en invloed op bestaande functies. Anders kan een kleine wens de hele oplevering onduidelijk maken. Laat nieuwe afspraken schriftelijk bevestigen en houd één actuele lijst van eisen aan.
Controleer ook wat u na oplevering kunt gebruiken
- Welke broncode, handleidingen, accounts en installatie-instructies ontvangt u?
- Wie bezit bestaande onderdelen en welke gebruiksrechten gelden voor software van derden?
- Wie doet onderhoud en wie kan helpen als de oorspronkelijke ontwikkelaar stopt?
Intellectuele eigendom en toestemming om werk te gebruiken vragen eigen afspraken. Alleen bestanden ontvangen maakt de rechtenregeling niet duidelijk. Laat daarom beschrijven welke onderdelen onder een overdracht of licentie vallen. Test bij de overdracht praktisch of iemand anders met de aangeleverde instructies een testomgeving kan starten.
Gebruik uw testlijst bij de overeenkomst
De softwareontwikkelingsovereenkomst past bij bouwen of aanpassen van maatwerksoftware. Voor alleen onderhoud of bestaande software kan iets anders passen. U kunt gratis beginnen met een gezamenlijke testlijst en uw bestaande offerte controleren. Het document helpt om ook betaling, rechten en verantwoordelijkheden af te spreken. Voeg de actuele eisen als bijlage toe en controleer dat geen andere versie in de offerte staat.