Software testen, wie doet wat?

[bvk]

Ik zit met het volgende vraagstuk en hoop op wat meningen en ervaringen van ervaren programmeurs.

Concreet: Ik wil weten wie er in een ontwikkel en test traject verantwoordelijk is voor het testen van bepaalde aspecten zoals de installer en de functionaliteiten. En vooral wat hierbij gebruikelijk is!

Ik werk voor een grote onderneming die van een grote ontwikkelaar een software pakket afneemt.
Nu heeft deze ontwikkelaar de nieuwste release afgegeven voor goedkeuring. In onze onderneming wordt de software vervolgens getest door een testgroep en ondergaat daarna nog functionele en gebruikers acceptatietesten.

Nu wil het geval dat pas bij de uiteindelijke gebruikers in een pilotfase een aantal gebreken met betrekking tot de installatie naar voren komen, maar uitsluitend onder één bepaalde Server variant van een ondersteund OS.

Nu geeft de ontwikkelaar aan niet onder alle ondersteunde en in het Functioneel ontwerp genoemde ondersteunde Operating Systems te kunnen testen en zal mogelijk (eigen interpretatie!) Microsoft gaan blamen.
Onze test afdeling zegt alleen maar functioneel te testen en is dit dus niet tegen gekomen. Ook met de verdere test is dit niet gecontroleerd.

Wij stellen als bedrijf dat de ontwikkelaar verantwoordelijk is voor het goed functioneren van de software op alle afgesproken besturingssystemen.

Mogen wij dit ook verwachten of hadden de gebreken in onze eigen tests naar voren moeten komen? (veel hangt af van afspraken, dat besef ik wel.)

In mijn eigen bescheiden mening is een ontwikkelaar verantwoordelijk voor zowel het gehele installatieproces alswel voor de programmatuur zelf? En had dit al moeten testen voordat ze de release bij ons afleverden of zit ik nu helemaal fout?

Ik hoop dat ik duidelijk ben,deze vraag hier terecht stel en jullie begrijpen dat ik niet in details kan treden...

[RobIII]

Is het nou echt nodig om met vingertjes te gaan wijzen dan waar de schuld ligt? Shit happens en het is nou eenmaal gebeurd. Het is stukken constructiever als je je nu met die software leverancier op het probleem stort en probeert samen tot een oplossing (of worst case: een workaround) te komen. Dan verdoe je je tijd niet met op-en-neer schuiven van "wie heeft het gedaan".

Dat het niet had mogen gebeuren ben ik met je eens, maar het is nu eenmaal zo.

Het is, zeker als er afspraken over gemaakt zijn, in principe de 'schuld' van de softwareleverancier die zijn afspraken (dus) niet nakomt, maar jullie test-omgeving (waar je sowieso nieuwe software hoort uit te rollen en testen voordat het in productie gaat) blijkt dus ook verschillend van de productieomgeving want anders hadden jullie zelf al het probleem (op tijd) geconstateerd. En inderdaad is het misschien maar in een heel specifiek geval en had de leverancier het ook bij 'beter' testen niet gezien / gemerkt. Da's nou eenmaal het leven van software. Makkelijkste oplossing: zet een backup terug en er is niets (meer) aan de hand That is: als je een backup hebt. Zo niet, eigen schuld

Sowieso, als het 'probleem' in een diepere 'laag' zit (zoals het OS onder de app) wist de leverancier (en testers etc.) misschien ook niets van dit (eventueel luikende) probleem en is het dus wel degelijk goed getest en akkoord bevonden. Je kunt dan wel de schuld bij MS of weet-ik-wie neer gaan leggen, maar daar wordt je probleem niet minder op

En dan nog: zonder inzage in jullie afspraken onderling en de gebruiksvoorwaarden van de software zelf kunnen we hier natuurlijk geen 'sluitend' antwoord op geven.

Verder heeft dit niets met programmeren te maken en lijkt me dit meer iets voor SG (als je over 'wetjes' en 'regels' wil babbelen).

[ Voor 29% gewijzigd door RobIII op 24-07-2007 19:29 ]

[Gerco]

Op zich vind ik het niet zo vreemd dat als een leverancier zegt, bijvoorbeeld Windows 2003 Server te ondersteunen dat ze dan niet *alle* varianten van Windows 2003 server in huis hebben. Er zijn er namelijk nogal wat, dan hebben we het natuurlijk nog niet over alle mogelijke ServicePack en hotfix combinaties die geinstalleerd zijn.

Natuurlijk zou het niet moeten voorkomen, maar als de leverancier al die versies van al die OSen in huis moet hebben, hebben ze geen geld meer om de software te schrijven. Of de software moet natuurlijk 2x zo duur worden.

Het is nu eenmaal niet haalbaar om *alles* te testen wat in de praktijk voorkomt, niet als je met een budget werkt (zowel financieel als qua tijd).

Overigens betekent "ondersteund" niet "werkt gegarandeerd zonder een enkel probleem". Ondersteund betekent waarschijnlijk gewoon: "Als het niet werkt zoals bedoeld, doen we daar wat aan".

[ Voor 17% gewijzigd door Gerco op 24-07-2007 20:16 ]

[Blue-eagle]

Testen is een vak apart, zeker bij gecompliceerde software. Dus als ergens de fout moet liggen dan is het bij jullie testers, niet bij de programmeur(s). Een programmeur test functioneel maar gaat niet op tig diverse Operating Systems zijn code grondig door testen op stabiliteit, functionaliteit, snelheid, etc.

De test omgeving komt niet overeen met de live omgeving en heeft dus onvoldoende getest.

Maar wat hierboven ook al werd aangegeven.. vingertje wijzen schiet je weinig mee op, kost alleen tijd en frustraties. Leer ervan, pas je tests aan, zet een backup terug en gooi een taart om de hoek bij de klant met je excuses erbij *

* Mits de schade te overzien is, bij 5 mljn. schade zal een taart weinig helpen denk ik zo

[alienfruit]

QA en beta testers testen het...

[Hillie]

Het leukste is dat er in dit soort gevallen over het algemeen gekeken wordt naar zwarte pieten toeschuiven en het hele achteraf-verhaal, terwijl hier m.i. duidelijk uit spreekt dat het verhaal vooraf niet in orde was, nl. de testspecificaties. Laat dat een goede les voor de toekomst zijn. En zoals RobIII zegt: Je kunt nu gaan sandbaggen en de schuld trachten af te schuiven, maar dat zal je leverancier dan ook doen.

Helaas is het lastig om van tevoren alles te vangen, maar dat is dan ook een groot incrementeel leerproces.

[bvk]

Om even een misverstand uit de wereld te helpen: het was absoluut niet de bedoeling om de zwarte piet toe te schuiven en het gaat ook zeker opgelost worden.

Het was en is meer mijn bedoeling om er achter te komen wat gebruikelijk is qua testen. Ik begrijp echter uit de diverse reacties al dat testen op alle platformen meestal een onhaalbare zaak is, maar wat is dan wél haalbaar?

Je betaald zo'n ontwikkelaar dik natuurlijk, het lijkt mij dan een verkeerde zuinigheid om dan niet gewoon een teststraat te hebben staan met alle OS'en waar je voor programmeert? Je kunt die immers voor al je projecten gebruiken.

Of is het dan redelijk om van je klanten te verwachten dat ze een volledige teststraat hebben staan om software te testen die maar een keer in de paar jaar wordt afgenomen?

[Standeman]

Het hebben van een teststraat met automatische test-scripts e.d. kan een reden zijn om een andere leverancier te kiezen. Het is ook maar net hoe belangrijk de software is.
Is het software voor vluchtgeleidingssysteem van een 747, dan wil je wel dat het altijd werkt en juist werkt zoals omschreven staat in de specificaties. Wanneer je 1 of ander vaag gratis forum exploiteert, is het misschien wat minder belangrijk (nee, ik doel niet op GoT ) en kan je met een bugje leven die in de productieomgeving naar boven komt drijven.

Je kan verwachten wat je afspreekt. Daar komt het eigenlijk op neer. Als in het contract staat dat applicatie a op OS b moet draaien, dan mag je aannemen dat dit ook zo is. Indien dit niet het geval is, voldoet de software niet aan de specificaties en moet de leverancier het fixen en misschien een schadevergoeding betalen indien dit in het contract vermeld staan (bijv. een taart )

Vaak beloven leveranciers gouden bergen en willen klanten voor dubbeltje op de eerste rij zitten. Dat gaat echter vaak niet goed samen..

edit:

Het hebben van een teststraat o.i.d. zegt natuurlijk niets over de kwaliteit van de software. Het is wel een indicatie van hoeveel aandacht het testen bij de leverancier krijgt

[ Voor 8% gewijzigd door Standeman op 25-07-2007 08:49 ]

[Niemand_Anders]

Als in een functioneel ontwerp is aangegeven welke OS-en ondersteund worden, dan moet de leverancier ook op al die OS-en testen. Een groot development bedrijf heeft echt wel een MSDN of TechNet abonnement. Installeer op een machine Virtual Server of VMWare en je kunt vrij simpel alle besturings systemen testen. Een MSDN universal abonnement kost 3500 dollar per jaar. Voor een kleine 300 dollar per maand krijg je alle versies van alle besturings systemen, office pakket, server software in alle talen die je maar kunt bedenken. Deze versies zijn juist bedoeld voor development, wat deze mogen niet op productie systemen worden ingezet.

Als wij software afnemen (wat zeer zelden voorkomt) dan gebeurt dat in twee stappen. Stap 1: Er wordt een aflever datum afgesproken en een boete clausule als die niet wordt bereikt. Stap 2: Wij testen de software, als deze in de installatie al verkeerd gaat, keuren wij direct de versie af en mag de leverancier een nieuwe versie aanleveren.

Een gebruiker van een software pakket behoort niet te testen of module a goed werkt met module b. Een gebruiker test of het systeem werkt zoals hij verwacht. Hij mag er namelijk vanuit gaan dat de code zelf correct is. Wij hebben zelf ook enkele linux software pakketen, maar wij beschrijven precies welke versies van welke distributies wij ondersteunen. Wij ondersteunen dus niet linux, maar Suse, Debian en RedHat. Het zal waarschijnlijk ook wel werken op een Ubuntu machine, maar dat roepen wij dus niet. Een software bedrijf moet gewoon alleen de versies benoemen waarop hij test.

Verder als een klant voor een dubbeltje op de eerste rang wilt zitten en de ontwikkelaar geeft aan voor dat bedrag de software te kunnen schrijven dan is daar niets mis mee. De software moet gewoon goed werken, ongeacht of de klant veel of weinig betaald.

Recent voorbeeld: Ik ben momenteel bezig om Visual Team Services 2008 te testen. Microsoft heeft precies aangegeven op welke versies van Windows 2003 (inclusief service packs) het wel en niet draait.

[RobIII]

Het hele probleem is dat er (letterlijk!) een oneindig aantal combinaties zijn van combinaties van (al dan niet) ondersteunde OS-en, patch-combinaties, draaiende services die elkaar dwars zitten, software die (met elkaar) vecht etc. Je kunt als tester nog zo'n mooie straat hebben; het is gewoon onmogelijk om alle combinaties te testen. Nu blijkt het dus in een zeer specifiek geval voor te komen en dan denk ik dus: shit happens, dat is niet iets waar je meteen iemand de schuld van kunt geven. Je kunt met testen (of dat nou door hun of door jullie gebeurt) enkel trachten zo goed mogelijk alles na te lopen en controleren; 100% is onhaalbaar. En als iemand 100% of erg dicht bij die 100% moet kunnen komen dan ben je het nog altijd zelf met je testomgeving, want die kun je zo goed als identiek maken aan je productieomgeving. Dat lukt die softwareleverancier natuurlijk nooit.

Daarnaast: als er 1 klein specifiek dingetje mis gaat (en dan kan het voor jullie nog zo'n catastrofale gevolgen hebben) maar de software werkt verder 'ok' dan wordt het OS dus prima ondersteund (blijkbaar) en moet het 'ene dingetje' gewoon middels een bugfix verholpen worden (of dat dan in het onderliggende OS zit of in de app).

Niemand_Anders schreef op woensdag 25 juli 2007 @ 09:31:
Recent voorbeeld: Ik ben momenteel bezig om Visual Team Services 2008 te testen. Microsoft heeft precies aangegeven op welke versies van Windows 2003 (inclusief service packs) het wel en niet draait.

Mooi voorbeeld. Nu stel MS released volgende week een hotfix om probleem xyz te fixxen. MS heeft die hotfix al door-en-door getest. Jij test 'm in je testomgeving ook nog eens door-en-door. Alles blijkt prima te werken.
Nu rol je de hotfix uit naar je productieomgeving. En dan opeens *POEF* alles foetsie. Server uit. Alles dood. Na een reboot en uren zweten om alles weer online te krijgen blijkt dat de firmware van je RAID-controller (4.1.4.2) verschilt van de firmware in je test-server (4.1.4.3). En laat die 4.1.4.2 versie nou net niet lekker werken in combinatie met die hotfix waardoor je OS onderuit gaat etc. etc.
Waar ligt de "schuld" dan? Bij de firmware? Bij de driver? Bij de hotfix? Etc. Feit blijft dat het niet werkt en dat (in alle redelijkheid) niemand dit had kunnen zien aankomen; er zijn gewoon (letterlijk) te veel mogelijke combinaties van hard/software. Je kunt enkel zorgen dat je er zo veel mogelijk aan hebt gedaan om te garanderen dat het werkt.

[ Voor 49% gewijzigd door RobIII op 25-07-2007 09:44 ]

[hneel]

Het lijkt mij dat normaal gesproken de fabrikant het product test en niet zoals in jullie geval de klant.

[silverstorm]

hneel schreef op woensdag 25 juli 2007 @ 10:07:
Het lijkt mij dat normaal gesproken de fabrikant het product test en niet zoals in jullie geval de klant.

De klant moet altijd de applicatie testen. Het liefste op een machine die gelijk is met je werkelijke productie machine. Een software ontwikkelaar kan niet voor elk type computer/harde schijf/raid firmware/vga drivers etc gaan testen.

[Standeman]

RobIII schreef op woensdag 25 juli 2007 @ 09:36:
*knip*
Waar ligt de "schuld" dan? Bij de firmware? Bij de driver? Bij de hotfix? Etc. Feit blijft dat het niet werkt en dat (in alle redelijkheid) niemand dit had kunnen zien aankomen; er zijn gewoon (letterlijk) te veel mogelijke combinaties van hard/software. Je kunt enkel zorgen dat je er zo veel mogelijk aan hebt gedaan om te garanderen dat het werkt.

Bij jezelf (niet persoonlijk ), aangezien je testomgeving niet identiek is aan je productieomgeving. Het neergaan van een productieomgeving door een uitrol is bijna altijd aan een menselijke fout (zoals het niet identiek houden van de omgevingen of een gebrek aan kennis).

[bvk]

Zoals ik al zei kan ik niet teveel in details treden, maar de software draait niet bij ons zelf in een productie omgeving, maar bij onze klanten. Met de software sturen ze "dingen" naar onze server die vervolgens bij ons verwerkt worden.

We hebben dus getest of de software goed met onze servers werkt en dat deed het. Er van uitgaande dat de ontwikkelaar de installatie op de gewenste besturingssytemen had getest, niet dus...

[Hillie]

bvk schreef op woensdag 25 juli 2007 @ 16:34:
We hebben dus getest of de software goed met onze servers werkt en dat deed het. Er van uitgaande dat de ontwikkelaar de installatie op de gewenste besturingssytemen had getest, niet dus...

Assumption is the mother of all fuckups.

Ik doe iets wat enigszins lijkt op software testen, nl. hardware verificatie. Ik heb een aantal jaren bij een grote IC-fabrikant gewerkt als verification engineer, waarbij ik verificatieomgevingen voor delen van chips heb opgezet. Functionele verificatie op RTL-simulatieniveau, voor degenen die dat wat zegt. Strikt genomen is er een spec voor het IP'tje (IP=intellectual property, maar in dit vak eigenlijk een standaardnaam voor een stukje chipdesign), waar ik dan een verificatieplan tegenaan schreef en dat ging implementeren. Daarna natuurlijk bugrapportage en de hele mikmak.

Momenteel werk ik voor een leverancier van dit soort tools en moet dus ook de methodologie uitdragen die ik bij m'n vorige club ook naar binnen trachtte te werken. Dat gaat helaas niet makkelijk. Want waar is een verificatieplan allemaal interessant voor? Niet alleen voor mij en de designer van het IP'tje. Nee, ook projectleiding, software engineers, application engineers, system integrators, enzovoorts moet z'n zegje doen. Want iedereen heeft weer een eigen kijk op het toepassingsgebied en dus ook waarde in het verificatieplanningstraject.

Wat zie je dan in de werkelijkheid gebeuren: "Mwoah, schrijf jij maar en laat maar horen". Tja, goed hoor, ik maak iets naar m'n beste weten, en dan een reviewsessie. Uiteraard leest geen hond zo'n document voor de review, dus je krijgt een paar bruikbare zaken aangereikt en daarna gaat het hele project van start. Het verificatieplan heeft dus de status "accepted", met review van alle belangrijke stakeholders. Gedurende het project komen dan mensen met vragen "Hey, letten jullie hier eigenlijk wel op?" "Wordt dit-en-dat afgedekt?", you name it. Opmerkelijk vaak zijn dat heel elementaire zaken die men tijdens een enigszins voorbereide verificatieplanningssessie zo naar voren had geschoven. Maar nee, pas als alle deadlines vaststaan komt er taak na taak bij, waardoor planningen nooit meer gehaald worden en ik dus enorm gefrustreerd raak, want tja "Het is weer wachten op verificatie". Het hielp natuurlijk ook niet mee dat ik als startende junior tussen 'ouwe rotten' kwam te zitten.

Maar goed, moraal van het verhaal: Die aanname van hierboven kun je dus afvangen door dit soort dingen van tevoren te bespreken met alle betrokken partijen. Hele trajecten van acceptatie- en integratietesten, de hele flikkerse bende moet je gewoon vastleggen. Klinkt heel dom en oninteressant werk, en over het algemeen heb je een paar projectgeneraties nodig om dit soort zaken 'vloeiend' te laten lopen, maar wel noodzakelijk.

Wat je vaak in situaties met techneuten ziet: "Het moet al snel af, laten we meteen gaan kloppen!!!111". Niet handig, tijd die je in dit soort dingen investeert hoef je achteraf niet meer met het schaamrood op de kaken in te halen met patch- en debugsessies bij klanten.

Succes ermee, goede teststrategieën zijn beschikbaar, maar acceptatie en integratie daarvan in een organisatie zijn vaak een tweede..

[dusty]

in een pilotfase

De grootste vraag eerst; Is de pilotfase een pilot binnen jouw bedrijf voor de nieuwe versie (a) of heeft jouw bedrijf een pilot project van de software bedrijf aangegaan (b)?

Uiteindelijk antwoord op de vraag wie is verantwoordelijk voor het vinden van bugs?
bij a: Het software bedrijf.
bij b: Beiden, daarvoor is het een pilot project, ook de reden waarom een bedrijf tegen een redelijk hoge discount het programma aan kan schaffen.

[Chemist]

Als je de verschillende testmethodieken er op naslaat (zoals bijvoorbeeld TMap) dan horen dit soort dingen getest te worden in de productie acceptatietest (PAT). Daar zitten de beheerders en dergelijke en zijn horen alle kennis te hebben over de verschillende platforms in de organisatie.

In de praktijk komt het er op neer dat degene die dit het simpelst kan testen het ook test. Hoe eerder in het ontwikkeltraject des te beter (lees: goedkoper).

Verder horen dit soort dingen al ver voor het testtraject besproken te zijn en opgenomen in het (master)testplan. Juist door dit testplan met iedere betrokkene/afdeling te bespreken en te laten goedkeuren kun je dit soort problemen grotendeels voorkomen.

Aan de andere kant leert de praktijk ook dat poep gebeurd (zoals eerder al was opgemerkt). Niks aan te doen, niemand is perfect (ja, dat is even schrikken misschien; zeker voor projectleiders, maar het is echt waar !!! )

[bvk]

dusty schreef op woensdag 25 juli 2007 @ 20:11:
[...]

De grootste vraag eerst; Is de pilotfase een pilot binnen jouw bedrijf voor de nieuwe versie (a) of heeft jouw bedrijf een pilot project van de software bedrijf aangegaan (b)?

Uiteindelijk antwoord op de vraag wie is verantwoordelijk voor het vinden van bugs?
bij a: Het software bedrijf.
bij b: Beiden, daarvoor is het een pilot project, ook de reden waarom een bedrijf tegen een redelijk hoge discount het programma aan kan schaffen.

Geen van beide denk ik. Wij "bestellen" een op maat ontwikkeld programma om op diverse Windows omgevingen in zowel een stand-alone alswel in een server/client model geinstalleerd te worden bij onze klanten. De in de software gegeven input wordt naar onze servers verstuurd en verwerkt.

Wij geven in het FO (Functioneel Ontwerp) onze design eisen aan en die worden vervolgens geaccepteerd en omgezet in een programma. In dat FO staan termen als "should function without any error" en dergelijke.

We wensen vervolgens en in dat zelfde FO voor een correcte werking onder Windows 2000 Professional en hoger, heel normaal lijkt me.

We testen vervolgens zelf de functionaliteiten zoals we die opgegeven hebben in het FO, doet het wat we verwachten? We installeren het op bijvoorbeeld Vista of 2000 (noem maar wat) en voeren functies uit. Sturen dat naar de server en bekijken de resultaten => correcte verwerking, geen problemen.

Vervolgens selecteren we een aantal relaties en vragen deze mee te doen aan een Pilot. Installeer en/of upgrade naar de nieuwe versie en vertel ons je bevindingen.

En prompt melden een aantal klanten installatie problemen in een gangbare netwerkconfiguratie: XP met Win 2003 SBS als server (AD?). Andere versie van Server 2003 hebben nergens last van...

Meldingen zijn uiteraard doorgegeven aan de ontwikkelaar en deze is daar nu mee bezig.

Ik zal nu intern zeker aan gaan bevelen ook zelf grondiger te gaan testen, mede op installatie gebied. Maar mijn vraag blijft eigenlijk nog steeds staan, van wie mag je nu verwachten dat veel voorkomende configuraties getest worden voor release of pilot fase.

Let wel, dit is niet bepaald de eerste versie van deze software, de vorige versie kwam ongeveer gelijk met Server 2003 uit en de allereerste versie al in de 80'er jaren...

[dusty]

bvk schreef op woensdag 25 juli 2007 @ 21:35:
[...]
Geen van beide denk ik. Wij "bestellen" een op maat ontwikkeld programma om op diverse Windows omgevingen in zowel een stand-alone alswel in een server/client model geinstalleerd te worden bij onze klanten. De in de software gegeven input wordt naar onze servers verstuurd en verwerkt.

Wij geven in het FO (Functioneel Ontwerp) onze design eisen aan en die worden vervolgens geaccepteerd en omgezet in een programma. In dat FO staan termen als "should function without any error" en dergelijke.
[...]

Je antwoord op mijn vraag is dus A) de pilot project is een interne om te kijken of het programma wel correct is. Het antwoord is dan ook dat over het algemeen inderdaad de bugs vinden het verantwoordelijkeid is van het software bedrijf. Maar dat hangt zoals je zelf al zegt in de TS ook af van de contracten en de afspraken die gemaakt zijn.

[Anoniem: 3057]

bvk schreef op woensdag 25 juli 2007 @ 21:35:
[...]
Maar mijn vraag blijft eigenlijk nog steeds staan, van wie mag je nu verwachten dat veel voorkomende configuraties getest worden voor release of pilot fase.

Let wel, dit is niet bepaald de eerste versie van deze software, de vorige versie kwam ongeveer gelijk met Server 2003 uit en de allereerste versie al in de 80'er jaren...

Ik denk dat je de situatie als volgt moet bekijken:

Omdat de software moet draaien in een klantomgeving waar je geen enkele grip hebt op de configuratie waar het op draait behalve in grove hoofdlijnen, is het onmogelijk om de werking van deze software 100% te garanderen, omdat er te veel permutaties mogelijk zijn van software, patchlevels, configuratie, netwerkinfrastructurele zaken, aangrenzende software, etc. Je moet er wel naar streven om zo hoog mogelijke stabiliteit te bereiken, maar meer dan dat gaat niet lukken.

Als je dit terugbrengt naar het testen, zal je opmerkingen als "should function without any error" vermijden. Zoals het er nu staat lijkt het meer een contractuele knuppel om de leverancier mee te slaan dan een realistisch uitgangspunt. Om het testen functioneel en economisch rendabel te houden, zou ik de volgende aanpak nemen.

Om in hele gangbare situaties installatie en de basiswerking van de software te garanderen, zal er voor die situaties een testomgeving opgezet moeten worden en beiden getest worden. Om dit te bereiken zal je
1) bij je klanten moeten uitzoeken welke configuraties / infrastuctuur /etc zij gebruiken
2) de antwoorden van je klanten groeperen naar "grote gemene deler"-configuraties
3) per "grote gemene deler"-configuratie de kosten van het opzetten en onderhouden van een testomgeving en het testen hierop van nieuwe versies afzetten tegen het aantal klanten waarvoor je goede werking kan garanderen als je deze testomgeving kan gebruiken.
4) vastleggen welke "grote gemene deler"-configuraties je daadwerkelijk gaat opzetten en gebruiken
5) eens per half jaar onderzoeken of er aanleiding is opnieuw je behoefte aan testconfiguraties aan te passen (bijv. omdat er een nieuw OS of SP aankomt of omdat je klantenkring sterk gewijzigd is)

Bij een project als dit moet jouw bedrijf (de klant) duidelijk de lead nemen, waarbij de inhoudelijke kennis (bijv. bepalen van kosten, etc) van jouw leverancier afkomstig is. Belangrijkste deliverable is de lijst met te testen configuraties, die op basis van een duidelijke business case (d.w.z. welke baten wil ik en wat mag dat kosten) is opgesteld. Je eist vervolgens van je leverancier dat hij de werking van de software op de vastgestelde omgevingen tegen vastgestelde kosten garandeerd. Voor zaken die erbuiten vallen eis je support, maar zal er een nacalc-berekening wordt toegepast, waarbij verwijtbare fouten van de leverancier op hun kosten gefixt moeten worden.

Bovenstaande is een realistischer plan dan "het moet altijd werken en de leverancier moet alles testen", want tenzij je te testen configuraties noemt en daar ook duidelijk op afrekent, is het een onhaalbare kaart.

Ik hoop dat je hier iets aan hebt. Succes!

[Anoniem: 51637]

bvk schreef op dinsdag 24 juli 2007 @ 18:33:

Nu geeft de ontwikkelaar aan niet onder alle ondersteunde en in het Functioneel ontwerp genoemde ondersteunde Operating Systems te kunnen testen en zal mogelijk (eigen interpretatie!) Microsoft gaan blamen.

Als hij een produkt aanlevert zal hij dat vantevoren moeten aangeven, en niet achteraf.

Ik vind het overigens ook vreemd dat hoewel er gespecificeerd is onder welke OS'en dit zou moeten werken dit niet door jullie getest wordt. Als je weet dat een deel van je gebruikers met een bepaald OS werkt moet je de afweging maken of het het waard is om een testomgeving met die software in te richten en daarop te testen - en dus het risico te lopen waar jij tegenaan gelopen bent, namelijk niet testen in de veronderstelling dat het wel goed gaat en toch gebruikersproblemen krijgen.

Ik denk dat wanneer jullie leverancier op basis van die specs is gaan bouwen het zijn verantwoordelijkheid is dat het ook werkt op de gespecificeerde OS'en. Maar dat had dan, vind ik, door je eigen testteam ook getest moeten worden. Nu hebben de gebruikers problemen, maar die hadden door jullie testers gesignaleerd moeten worden. In het testplan had een deel ingeruimd moeten worden voor het (globaal) testen op verschillende omgevingen, omdat je van tevoren weet dat je daarmee te maken krijgt.

[ Voor 5% gewijzigd door Anoniem: 51637 op 27-07-2007 21:45 ]

[TheBrain]

bvk schreef op woensdag 25 juli 2007 @ 21:35:
[...]
Wij "bestellen" een op maat ontwikkeld programma om op diverse Windows omgevingen in zowel een stand-alone alswel in een server/client model geinstalleerd te worden bij onze klanten. De in de software gegeven input wordt naar onze servers verstuurd en verwerkt.
....

.....Maar mijn vraag blijft eigenlijk nog steeds staan, van wie mag je nu verwachten dat veel voorkomende configuraties getest worden voor release of pilot fase.

Omdat het een maatwerk programma is dient de klant ook een goed testtraject te voeren.

In dit specifieke geval denk ik dat de verantwoordelijkheid gedeeld is en dat je dus met je leverancier om tafel moet om ervoor te zorgen dat deze ervaring verwerkt wordt in de testen die de leverancier uitvoert.

Dan nog ontkom je niet aan het zelf testen op dat soort configuraties omdat je toch dat risico moet uitsluiten. Maar uitwisselen van elkaars testresultaten of het inrichten van de tests conform dezelfde methodiek zal daar bijvoorbeeld een verbetering in kunnen brengen.

[Hillie]

Als er geen communicatie omtrent testgegevens e.d. bestaat behalve "ja hoor het werkt", moet de standaardmethode die zijn die bij ongeteste software hoort. Zonder inzicht kun je er niet van op aan natuurlijk.

[SmartDoDo]

offtopic:
SG => CSA