rabsi zei:
dan moet de programmeur een interface bouwsteen voorzien die de output parameters van de module weergeeft en waar de tester de input parameters kan simuleren (zoals die van de andere modules (nog niet geprogrammeerde modules) zouden komen). Om sommige fouten te kunnen waarnemen moeten wel de gewenste functie van de module omschreven worden.
Of een programmeur kan ook "zelf" gaan testen. Ik heb wel eens voor gehad dat de testers zeiden het crasht "heel soms", maar t'is precies "random". En dan zei je, okay dan fix ik het niet, ik heb niet genoeg informatie en dan zei de manager : Fixen of xxxx!!! De klant betaald niet als dit niet opgelost is. Dus zie maar dat het werkt tegen morgen of er hangt een vlieg in de boter! Daar sta je dan he? Dan ging ik dus echt dat 1000x uitvoeren tot dat de op het eerste zicht "random" crash zich voordeed. En dan met debuggen kon ik exact zien waar het in de code misging en ook waarom.
Emerxill zei:
@Malika
Ok, dat helpt u in te leven in de taak van de programmeur. Maar ge geeft toch zelf toe dat ge zeer weinig technische kennis nodig hebt om te testen op dat niveau.
Alles wat ge hier aanhaald is nietmeer dan methodologie. Der is nog groot een verschil tussen zeggen dat "het crasht" en het analyseren van de stacktrace en de programmeur vertellen in welke lijn code hij het moet gaan zoeken en hem bijv vertellen dat hij best een 'short' gebruikt als variabele ipv een 'byte'.
Als tester vertelt ge de developer wat ge gedaan hebt om de boel te laten mislopen zodat die het kan reproduceren en het maar uitzoekt waaraan het ligt.
Enkel een Tester-Programmeur moet technische testen uitvoeren(Testen, Foutmelding registreren, opzoeken in code en de regels in de code doorgeven aan de programmeur waar het exact mis gaat). Meestal wordt die job echter door de zuivere programmeur gedaan, maar in feite is dit een functie op zich.