Onderzoek Test Driven Development
Voor onze opleiding voeren wij een onderzoek uit naar Test Driven Development (TDD). Om een indruk te krijgen wat softwareontwikkelaars belangrijke aspecten vinden tijdens het ontwikkelen hebben wij een kleine enquete gemaakt.
De enquete staat op http://www.vanarkelen.eu/tdd-onderzoek/.
Zou je ons hiermee willen helpen? Het kost ongeveer 2 minuten van je tijd.
De antwoorden zullen anoniem verwerkt worden.
Alvast bedankt!
Remco van Arkelen & Ronald van der Kooy
Rampzalig onderwerp, testen en requirements willen opdrachtgevers zich nauwelijks mee bezig houden...
Thanx voor je uitgebreide opmerkingen ;)
Dat is dus een van de zaken welke we willen onderzoeken, is een interessant en onderschat onderwerp.
Bedankt,
Remco
- Bij TestDriven Development denk ik bijvoorbeeld ook aan een uitgebreid testplan
- Laat je ook anderen (zonder kennis zeg maar) ermee testen, is ook een goede manier om bijvoorbeeld veiligheid/ eenvoudigheid te testen.
Stel hiervoor verschillende testcases op, die de testpersoon moet uitvoeren, wat kan er mis gaan -> Ook vantevoren al bepalen, wat er mis KAN gaan.
Zo zijn er nog veel meer dingen (google eens op testen volgens TMAP, dan kan je wel wat vinden over testen, waar je ook meer over kan onderzoeken)
Vantevoren bepalen wat er mis kan gaan, is dus evenmin nodig, alles draait om het opstellen van de test. En dus de requirements.
En laat die requirements nu net het grootste probleem zijn... 'de usergegevens moeten worden opgeslagen in de database'. Ok, wélke usergegevens? Wélke database? 'ja, je weet wel.', nee ik weet helemaal niks en ik wil ook niks weten, althans, ik wil een lijst hebben met usergegevens en een naam van een database hebben. Een programmeertaal zou ook wel handig zijn, evenals de vereiste userinterface, bv. via de browser.
Hier worden opdrachtgevers niet blij van, nu blijkt ineens dat zij moeten gaan nadenken over wat ze hebben willen. Men had gedacht daarvoor een domme ezel in te huren (lees: programmeur) maar die stinkt daar dus niet in. Een beetje programmeur voelt de bui al aankomen: 'Het systeem voldoet niet aan onze verwachtingen'. Wélke verwachtingen???
Járen ervaring met deze ellende, een eeuwige strijd tussen de opdrachtgever, de testmanager, projectmanager en de gebruikers. Doffe ellende.
@Remco: Mocht je meer informatie willen hebben of eens willen babbelen over dit onderwerp, laat maar even weten.
Geen verder commentaar
mvg
Wouter
Daarom noemde ik het testplan en dergelijke ook. Waarom: Om dezelfde reden als jij eigenlijk. Want zonder goede requirements (wat moet het precies kunnen, hoe moet het werken, enz.) Kan je geen goed testplan schrijven. Omdat jij begon over de requirements, en ik toch echt een testplan miste in de vragenlijst (TS vraagt wel of je iemand anders laat testen, maar hoe test diegene het dan? Aan de hand waarvan?)
Zonder goed testplan is goed testen ook bijna onmogelijk. Als jezelf gaat testen, dan weet je hoe je zou willen dat de dingen gaan. Als je een ander zou laten testen, zonder plan, dan wordt niet alles getest waarvan je wil dat het getest wordt.
Robert_Deiman schreef op 17.03.2008 08:22:
Laat dat 'bijna' maar weg!Zonder goed testplan is goed testen ook bijna onmogelijk.
Ik denk dat de basis van development altijd is: specs specs specs (requirements dus).
Schoonheidsfoutje: "ten alle tijden" -> "te allen tijde".
'Het moet met alle browsers goed werken'. Installeer alle (!!!) browsers dan maar even op de test-pc, zodra je klaar bent, praten we verder. Veel sterkte toegewenst.
Dit is niet te testen, niemand weet welke browsers er allemaal zijn, laat staan dat er iemand is die even alle browsers kan installeren. En wat dacht je van testen? Dat wordt al snel een factor 100 duurder, dan wanneer je bv.alleen met IE 6 en 7 (laatste SP's), FF 2.0, Opera 9 en Safari 3 gaat testen, waarbij je voor Opara en Safari alleen een regressietest uitvoert.
Het opstellen van requirements is een vak op zich. Of het echt te bouwen is en echt te testen is, dat zijn weer zaken die door de programmeurs en testers moeten worden beoordeeld.
Begin in elk geval met testen zodra je pen en papier oppakt om de requirements op te stellen. Ga je pas in een later stadium testen, zul je zien dat veel werk weer opnieuw gedaan kan worden. Achteraf testen is een garantie op een drama.
na verzenden:
Welkom.
Quote:
Hieronder vindt u de vragenlijst die wij opgesteld hebben n.a.v. ons onderzoek naar Test Driven Development.
We willen u vragen deze lijst zo zorgvuldig mogelijk in te vullen.
Bedankt, uw antwoorden zijn verwerkt.
We willen u vragen deze lijst zo zorgvuldig mogelijk in te vullen.
Bedankt, uw antwoorden zijn verwerkt.