Softwaretesters verenigt u

Och, wat een onzin zeg! Ik ga ook zo te werk en ik zit echt niet op voor een klontje suiker.

Ik ken ook collega-testers die naar de bouwer stappen en zeggen "Dit is fout" en dan weer weglopen. Of wat denk je van defects die op en neer gaan? Assigned-fixed-failed-fixed-failed-fixed, etc, zonder dat er ook maar één keer overlegd wordt. Gaat nergens over.

Maar goed, die houding komt uiteraard van twee kanten. Als ik een defect heb opgevoerd en de bouwer kan hem niet reproduceren, vraagt hij net zo goed aan mij of ik het voor kan doen. En als ik een fixed defect terug krijg en ik vind niet dat ie fixed is, stap ik altijd eerst naar de bouwer om te vragen of de nieuwe build er wel op staat, deze fix wel goed is meegekomen en weet ik veel wat om te kijken wat er mis is gegaan en indien nodig kijken we er nog een keer samen naar.

In mijn laatste project ging alles zo soepel, dat de TM en PL er eigenlijk geen omkijken naar hadden. Nou ja... qua onderlinge communicatie dan. De knelpunten zaten bij ons uiteraard in de tijd en het feit dat de gebruikers bij de GAT eigenlijk heel veel nieuwe wensen hadden, die ze er tóch in wilden zien en niet wilden wachten tot de volgende release, maar da's een politieke discussie en daar had ik als tester niets mee te maken...

quote:

Op woensdag 26 november 2008 08:59 schreef LadyXochi het volgende:
Och, wat een onzin zeg! Ik ga ook zo te werk en ik zit echt niet op voor een klontje suiker.

????? Is dit aan mij gericht? in dat geval zat er een bug in de boodschap denk ik

het hele leven is 1 groot spelletje

quote:

Op woensdag 26 november 2008 09:24 schreef sigme het volgende:
Mindere leidinggevenden hebben graag allemaal gelijke poppetjes.

Precies...zoiets probeerde ik te zeggen met dat opzitten voor een klontje, maar dit is beter verwoord

als mensen welles nietes spelletjes gaan spelen moet jij als manager dat toch oplossen ? Of snap ik de rol van manager niet ?

Beetje makkelijk om je beste tester te ontslaan omdat hij graag welles / nietes doet Creeer dan als manager een omgeving waarin dat niet kan gebeuren.

Bah, ik zit met griep thuis en morgen is het jaarlijkse testnet event

Ik weet niets van een testnet evenement morgen.
http://www.testnet.org/Produktie/Evenementen/ThemaAvond.html
Ben je niet in de war met vorige maand ?

Ik heb trouwens ook een bloedhekel aan mensen die spelletjes spelen.
Ik had zo'n vrouw in mijn vorige testteam zitten, daar was echt nauwelijks mee samen te werken.

Definieer spelletjes?

quote:

Op woensdag 26 november 2008 09:10 schreef sigme het volgende:
Tsja, ik begrijp niet goed waaruit zou blijken dat ik spelletjes zou spelen.

Dat zei je zelf... Jij hebt over een rol "spelen"... Is mijns inziens heel wat anders dan "mijn vak uitoefenen". Daar hoef je geen rol voor te spelen, dan ben je gewoon jezelf..

[ Bericht 14% gewijzigd door existenz op 26-11-2008 18:53:04 ]

quote:

Op woensdag 26 november 2008 09:13 schreef Scorpie het volgende:

[..]

Dan mag je de Teamleider er ook uit trappen, de bouwers ook, en o ja, vergeet jezelf ook niet.

Nee, ik wil een team waarin iedereen samen werkt. Dat je wel eens een discussie hebt is niet meer dan normaal. Maar ik wil een team waarin er gezamelijk een doel bereikt wordt (Wat het doel ook mag zijn). En niet een tester die op zijn teentjes is getrapt als een developer zegt: Dat is geen bug, of Dat is een CR. Iedereen dient elkaar te helpen indien nodig. De developer mag dus het testen makkelijker maken (let op, ik heb het over het functionele testen, niet over de unittests ed.) voor de tester als het even kan, de tester mag meedenken in technische/functionele oplossingen voor problemen (tot op zekere hoogte natuurlijk, ik ben geen fan van testers die technisch de implementatie kennen omdat het testen negatief kan laten werken). Het liefste verander ik al die "mag"jes in "moet"jes.

En hen en weer schieten van issues gebeurd alleen wanneer de developer het niet goed oplost.... Als de developer de bug niet gereproduceerd krijgt, dient hij om meer info bij de tester te vragen en dan gezamelijk het probleem te bekijken indien nodig.

[ Bericht 2% gewijzigd door existenz op 26-11-2008 18:54:08 ]

quote:

Op woensdag 26 november 2008 10:30 schreef Fugie het volgende:
als mensen welles nietes spelletjes gaan spelen moet jij als manager dat toch oplossen ? Of snap ik de rol van manager niet ?

Beetje makkelijk om je beste tester te ontslaan omdat hij graag welles / nietes doet Creeer dan als manager een omgeving waarin dat niet kan gebeuren.

Dat welles/nietus geldt wat mij betreft voor iedere rol binnen een project. Niet alleen voor de tester, maar dit is het centrale testers topic

quote:

Op woensdag 26 november 2008 08:23 schreef Captain_Fabulous het volgende:

[..]

Testers die opzitten voor een klontje suiker krijgen bij jou dus opslag?

Als het een tester is die een groot punt maakt van een tekst die zwart is ipv blauw (Wat nergens gespecificeerd staat), wat hij mooier vindt en weigert de applicatie te accepteren omdat dat soort zaken niet opgelost zijn, mag hij van mij inderdaad direct weg. Staat het wel gespecificeerd, dan heeft hij inderdaad een punt, maar dan ligt het aan de context hoe groot zijn punt is natuurlijk (Heeft de kleur een betekenis is het natuurlijk wel belangrijk). Het probleem is hier echter dat de "mierenneukers" vaak ook in de categorie: "Wat ik vind moet opgelost worden" vallen en ze het niet willen accepteren dat er software opgeleverd wordt die anders is dan zij willen (Maar wel is wat de klant wil volgens de specs)...

[ Bericht 38% gewijzigd door existenz op 26-11-2008 18:51:40 ]

quote:

Op woensdag 26 november 2008 18:39 schreef existenz het volgende:

[..]

Dat zei je zelf... Jij hebt over een rol "spelen"... Is mijns inziens heel wat anders dan "mijn vak uitoefenen". Daar hoef je geen rol voor te spelen, dan ben je gewoon jezelf..

Je vak uitoefenen kan echter ook inhouden dat je in een team een bepaalde rol hebt. Die rol kan wisselen wanneer de samenstelling van het team verandert. Het is dan best prettig als iemand flexibel genoeg is om ook in de rol die het beste bij het team past te kunnen functioneren.

quote:

Op woensdag 26 november 2008 18:45 schreef existenz het volgende:

Het probleem is hier echter dat de "mierenneukers" vaak ook in de categorie: "Wat ik vind moet opgelost worden" vallen en ze het niet willen accepteren dat er software opgeleverd wordt die anders is dan zij willen (Maar wel is wat de klant wil volgens de specs)...

Daar kan de tester ook weinig aan doen. Wanneer een tester iets niet goed vindt dat niet gespecificeerd staat, moet gezorgd worden dat het wel gespecificeerd wordt.

Soms is het leven simpel.

quote:

Op woensdag 26 november 2008 19:14 schreef Alicey het volgende:

[..]

Je vak uitoefenen kan echter ook inhouden dat je in een team een bepaalde rol hebt. Die rol kan wisselen wanneer de samenstelling van het team verandert. Het is dan best prettig als iemand flexibel genoeg is om ook in de rol die het beste bij het team past te kunnen functioneren.

Blijft nog steeds wat anders dan een rol "spelen" wat mij betreft... Zolang issues relevant zijn, omdat ze niet voldoen aan specificaties, vind ik het ook niet mierenneuken (wel irritant, maar dat is wat anders en eigenlijk gewoon mijn probleem ).

quote:

Op woensdag 26 november 2008 19:17 schreef Alicey het volgende:

[..]

Daar kan de tester ook weinig aan doen. Wanneer een tester iets niet goed vindt dat niet gespecificeerd staat, moet gezorgd worden dat het wel gespecificeerd wordt.

Soms is het leven simpel.

Dat kan inderdaad ook, maar men hoeft echt niet te specificeren of een kleur zwart/blauw is in elke applicatie. Vaak hoeft dit alleen wanneer het een indicatie waarde heeft of de applicatie aan bedrijfs huisstijl moet voldoen (als het daaral in gespecificeerd staat). In die gevallen is een dergelijke issue natuurlijk prima.. Staat het in beide niet, is het totaal inrelevant en komt zoiets echt helemaal als laatste (en in vele gevallen dus helemaal niet). En hoeft het ook niet gespecificeerd te worden.

Ik zou zelf wel aan de slag willen als tester. Ik ben vrij onervaren maar er zullen ongetwijfeld meer bedrijven zijn die het niet erg vinden om je in snel tempo als tester op te leiden. De termen die hier langskomen ben ik wel bekend mee maar de meeste testtechnieken heb ik niet vaak gebruikt. Ik weet wel wat het ongeveer inhoud maar ik zeg niet tegen mij "Ug, maak eens even een GAT.", tenzij je een letterlijk gat ergens in wil.
Maar goed, misschien kan er hier iemand een bonus van z'n werkgever krijgen als diegene nieuwe collega's.

quote:

Op woensdag 26 november 2008 19:45 schreef existenz het volgende:

[..]

Dat kan inderdaad ook, maar men hoeft echt niet te specificeren of een kleur zwart/blauw is in elke applicatie.

Toch zijn er redenen om voor het een of het ander te kiezen en wanneer. Wanneer daar vragen over komen is het zaak die te beantwoorden. Met specificeren bedoel ik natuurlijk niet noodzakelijkerwijs dat er een document wordt opgesteld waar dat in staat, maar wel dat er bij onenigheid een knoop kan worden doorgehakt.

quote:

Vaak hoeft dit alleen wanneer het een indicatie waarde heeft of de applicatie aan bedrijfs huisstijl moet voldoen (als het daaral in gespecificeerd staat). In die gevallen is een dergelijke issue natuurlijk prima.. Staat het in beide niet, is het totaal inrelevant en komt zoiets echt helemaal als laatste (en in vele gevallen dus helemaal niet). En hoeft het ook niet gespecificeerd te worden.

Blauw is toch dermate afwijkend dat ik er vraagtekens bij zou zetten wanneer er niet gespecificeerd is dat het blauw moet zijn.

Bijna elke detacheerder biedt wel opleidingstrajecten daarvoor. Meeste Uni/HBO opleidingen is het test gedeelte uberhaubt een wassen neus, dus een achterstand zul je niet echt hebben..

quote:

Op woensdag 26 november 2008 19:42 schreef existenz het volgende:

[..]

Blijft nog steeds wat anders dan een rol "spelen" wat mij betreft... Zolang issues relevant zijn, omdat ze niet voldoen aan specificaties, vind ik het ook niet mierenneuken (wel irritant, maar dat is wat anders en eigenlijk gewoon mijn probleem ).

"Een rol spelen" is een prima manier van uitdrukken die weinig met spelletjes spelen te maken heeft. Hoe zou je het anders willen noemen?

quote:

Op woensdag 26 november 2008 19:54 schreef existenz het volgende:
Bijna elke detacheerder biedt wel opleidingstrajecten daarvoor. Meeste Uni/HBO opleidingen is het test gedeelte uberhaubt een wassen neus, dus een achterstand zul je niet echt hebben..

De markt zakt wel in op het moment, ik weet niet of veel bedrijven nog hapig zijn op onervaren mensen .

quote:

Op woensdag 26 november 2008 19:53 schreef Alicey het volgende:

[..]

Toch zijn er redenen om voor het een of het ander te kiezen en wanneer. Wanneer daar vragen over komen is het zaak die te beantwoorden. Met specificeren bedoel ik natuurlijk niet noodzakelijkerwijs dat er een document wordt opgesteld waar dat in staat, maar wel dat er bij onenigheid een knoop kan worden doorgehakt.
[..]

Blauw is toch dermate afwijkend dat ik er vraagtekens bij zou zetten wanneer er niet gespecificeerd is dat het blauw moet zijn.

Ja, maar ik heb al veel gevallen gehad waar de tester het vond omdat hij een blauwe auto reed en de vraag niet van de klant af kwam en ook niet eens waar het met de klant overlegt werd. Of hij vond blauw fijner lezen, want hij had een oog afwijking (Alleen de klant had het niet)... Een dergelijke iets, zet je inderdaad op een lijst met mogelijke aanpassingen/uitbreidingen en legt die met een urenschatting voor aan de klant.

quote:

Op woensdag 26 november 2008 19:54 schreef Alicey het volgende:

[..]

"Een rol spelen" is een prima manier van uitdrukken die weinig met spelletjes spelen te maken heeft. Hoe zou je het anders willen noemen?

Zullen we daar gewoon over ophouden? Mijn punt lijkt me wel duidelijk, hoe iemand het noemt, moet hij/zij zelf weten

quote:

Op woensdag 26 november 2008 13:43 schreef dyna18 het volgende:
Ik weet niets van een testnet evenement morgen.
http://www.testnet.org/Produktie/Evenementen/ThemaAvond.html
Ben je niet in de war met vorige maand ?

Nee, ik bedoelde de 14e nationale testdag, sorry

http://www.testdag.nl/

Weet iemand hier een goede manier om een tijdje in het buitenland te kunnen werken als tester? Op Monsterboard staan honderden internationale testvacatures, heeft iemand hier ervaring met het vinden van een leuke klus op die manier?

Zijn er misschien bedrijven in Nederland die veel klussen in het buitenland anbieden?

Überhaupt mensen hier met internationale testervaring?

Wij hebben wel wat internationale projecten gehad, maar dat loopt (helaas) een beetje op zijn einde. De grote bedrijven zitten vaak ook in het buitenland, maar voordat je daar in aanmerking komt ben je volgens mij ook 3 jaar verder

Het hangt heel erg af van de periode. Op dit moment hebben wij wel klussen in het buitenland lopen. Ik ben zelf net een half jaar bezig en een van degenen die tegelijkertijd met mij gestart is, zat binnen de 1e week bij een intake in Brussel. Die klus wordt nu aan mij aangeboden, dus internationale projecten zijn er wel.
Ik vraag me af of je het nu hebt over freelance klussen in het buitenland of iets anders.

Dus die 3 jaar verder is niet in alle gevallen nodig

Erlandi, heb jij geen PM aangezet of werkt het niet op hhet moment?

quote:

Op woensdag 26 november 2008 21:14 schreef FloggingMolly het volgende:
Weet iemand hier een goede manier om een tijdje in het buitenland te kunnen werken als tester? Op Monsterboard staan honderden internationale testvacatures, heeft iemand hier ervaring met het vinden van een leuke klus op die manier?

Zijn er misschien bedrijven in Nederland die veel klussen in het buitenland anbieden?

Überhaupt mensen hier met internationale testervaring?

Je kan overal werken in IT. De vraag is of jij beter of goedkoper bent als een Indier of een Oost Europeaan. Je zult dus in het algemeen minder verdienen. Tenzij je vanuit NL opdrachten doet want dan gaat het om SLA's en dus kwaliteit. Althans dat is het imago/kostprijs verhaal in W-Europa en N-Amerika.

quote:

Op woensdag 26 november 2008 20:47 schreef Knipoogje het volgende:

[..]

Nee, ik bedoelde de 14e nationale testdag, sorry

http://www.testdag.nl/

Wie is er naar toe geweest?

To capt_fab, Ik heb bij mijn weten pm niet uitgezet, als het standaard uitstaat zal dat wel het geval zijn. Wegens internetproblemen kan ik op dit moment moeilijk terugzoeken hoe ik dat moet veranderen (mijn vorige post is inderdaad ook al opgegeten ).. hmm volgens mij heb ik het zojuist aangezet .

bah, internet probleme op je werk en thuis maakt je niet blij. Zeker als je op een functie zit waar er niet te allen tijde testzaken zijn.

@ vorige pagina....

Even iets anders hoor... Graag jullie mening hierover.

TM wil graag dat de testgevallen zodanig opgesteld worden, dat iemand, die nog nooit getest heeft en ook niets weet van de applicatie en wat het zou moeten kunnen, de testgevallen uit moet kunnen voeren.


Collega tester heeft testgevallen opgesteld. Testgevallen zijn niet opzichzelfstaand: Men moet eerst andere handelingen doen, voordat aan het testgeval begonnen kan worden. Deze zijn niet beschreven in precondities oid. Goed, de testgevallen staan dan wel chronloogisch in het bestand, dus als je alles achter elkaar uitvoert, kom je er wel. Je loopt dan echter tegen de lamp als je op een ochtend verder wil gaan waar je de dag ervoor gebleven was (en het systeem kan niet aan blijven staan gedurende de nacht). Of als je losse testgevallen wil/moet (her)testen. Argument vóór: De tester in kwestie weet op een gegeven moment wel hoe het moet en heeft de 'aanloop-kennis' niet nodig. Argument tegen: Dan kan ie dus niet uitgevoerd worden door een nieuw persoon, bijvoorbeeld bij ziekte van de tester. Verder moet je in het geval van een defect ook beschrijven welke stappen er zijn gedaan vóór dit testgeval. Kan van belang zijn voor de bouwers.

Verder... de testgevallen van collega tester zijn gereviewd op verzoek van TM. Eerste reactie van collega tester was defensief: Mijn testgevallen hoeven niet gereviewd te worden. Dat doe ik zelf...
Oooookaaaaay.....

Maar goed, een paar van de vragen die gesteld waren op basis van zijn testgevallen:

Testgeval 1: Als waarde > 1000, dan gebeurt er dit.
Testgeval 2: Als waarde < 1000, dan gebeurt er dat.
Vraag: Wat als waarde = 1000?
Antwoord: Dat stond niet gespecificeerd.
....

Specificatie X: De maximale waarde die je in kunt voeren is 999
Bijbehorend testgeval: Je kunt 999 invoeren
Vraag: Wordt er niet getest of je ook 1000 kunt invoeren? (Of andere invalid values, zoals letters en tekens of zo)?
Antwoord: Ja, natuurlijk!
Vraag: Waar kan ik die testgevallen vinden?
Antwoord: Die heb ik niet beschreven.
Vraag: Waarom niet?
Antwoord: Er waren al zoveel testgevallen, ik wilde het aantal beperken. Daarnaast vind ik niet dat je deze allemaal specifiek moet beschrijven in een testgeval. Deze zitten allemaal in mijn hoofd. Als ik bij dit testgeval kom, dan weet ik zelf wel dat ik ook de andere waarden moet testen.
Vraag: Wat als niet jij, maar iemand anders deze testgevallen moet uitvoeren?
Antwoord: Iedere goede tester weet dit.

Dit gaat dus nergens over, want als iemand anders dit uitvoert, dan heeft ie de specs er niet bij. Dus hij weet niet of "Je kunt 999 invoeren" een grenswaarde is of niet, en of het een bovengrens of ondergrens is. Het enige wat je dan kunt testen is of je daadwerkelijk 999 kunt invoeren....


Wat denken jullie van bovenstaande?

Slecht gespect als je het mij vraagt...

"Iedere goede"-antwoorden zijn bullshit. Hee je code is extreem rommelig en niet uitbreidbaar. "Ja een goede programmeur kan er wel uitkomen"

Dat de betreffende tester een ontzettende trap onder z'n hol moet hebben.
Maar tegenvraag, gaat de TM ook de tijd en resources vrijmaken om gestructureerder te werken en alles op te schrijven? Of wordt er alleen geroepen 'we moeten gestructureerder werken' maar geen resources voor vrijgemaakt? Het gedrag van je collega tester kan ook onstaan zijn omdat vorige TM's het wel mooi vonden, iemand die zo weinig uren aan documentatie besteed. Er lopen teveel PM's en TM's rond die alleen maar kijken hoe het zo goedkoop mogelijk kan...

quote:

Op vrijdag 28 november 2008 13:33 schreef LadyXochi het volgende:
Wat denken jullie van bovenstaande?

Voor het eerste geval, dienen dit soort voorvereisten om een testgeval uit te kunnen voeren opgenomen te worden in de precondities.

Met betrekking tot de review blijkt helaas dat hij niet een zeer goede tester is (en dan druk ik mij nog zwak uit). Als hij Grenswaardenanalyse al niet beheerst, heb ik ook sterke twijfel over de rest van zijn werk.
Ik zou dit daarom voorleggen aan de TM en het hem verder laten uitzoeken. Doet hij er niets mee, dan zelf er ook verder niet druk om maken.

Allereerst: Bedankt voor jullie input. Ik wist eigenlijk al wat jullie gingen zeggen, maar het is toch wel fijn om te horen dat je niet de enige bent die het cappy vindt

quote:

Op vrijdag 28 november 2008 13:39 schreef soylent het volgende:
Slecht gespect als je het mij vraagt...

Ja, daar kan ik nog wel uren over doorgaan. Maar wanneer ik ergens aan begin, dan is het eerste wat ik doe de specs reviewen en dergelijke gaten, fouten en onduidelijkheden eruit halen. Daar heeft collega tester al in gefaald m.i. (In dit geval ben ik er na 3 maanden pas bijgezet).

quote:

Op vrijdag 28 november 2008 13:40 schreef Captain_Fabulous het volgende:
Maar tegenvraag, gaat de TM ook de tijd en resources vrijmaken om gestructureerder te werken en alles op te schrijven?

Ja, er zijn nu resources vrijgemaakt. O.a. ik. Ze hebben mij erbij gezet, omdat ze geen vertrouwen hadden in de kwaliteit van zijn werk. Maar als je zijn zooitje goed wil krijgen, kun je eigenlijk net zo goed opnieuw beginnen. Ik heb in ieder geval een aantal knelpunten boven water gehaald en nu weten ze (TM en PL) wel waar ze aan toe zijn met zijn deel. Eén van de onderdelen die nog gedaan moesten worden heb ik naar me toe getrokken onder het mom van: Dan kun je in ieder geval daarvan een betere kwaliteit garanderen

quote:

Op vrijdag 28 november 2008 13:40 schreef Captain_Fabulous het volgende:
Het gedrag van je collega tester kan ook onstaan zijn omdat vorige TM's het wel mooi vonden, iemand die zo weinig uren aan documentatie besteed.

Wat ik eigenlijk denk/vind is dat de TM de collega tester te lang zijn gang heeft laten gaan. Toen ik erbij werd gezet (en dat was initieel alleen maar omdat ze vonden dat ie er wel erg lang over deed), vroeg ik of TM al eens naar zijn testgevallen had gekeken. Dat was dus nog niet het geval. Met één oogopslag kon je zien dat de kwaliteit van wat hij had ver onder de maat was. Ieder testgeval had max. 5 regels (stappen en verwachtingen). Dit was volgens collega tester wederom, omdat het zoveel werk was en er waren zoveel testgevallen dat het heel veel tijd zou kosten om alles helemaal uit te schrijven, dat hij zelf maar had besloten om ieder testgeval maximaal 5 regels te laten omvatten!!! Enfin, als de TM initieel even had gekeken hoe collega tester te werk ging, had hij meteen kunnen zeggen dat: De testgevallen 1) helemaal uitgeschreven moeten worden, 2) los uitgevoerd moeten worden, en 3) ook door mensen zonder kennis van de applicatie uitgevoerd moeten kunnen worden (dus specifiek genoeg). Misschien een tip voor TMs hier, om af en toe eens wat werk te bekijken, om te zien of ze op het juiste pad zijn, en niet te wachten tot het einde van de analyse-periode.

quote:

Op vrijdag 28 november 2008 13:40 schreef Captain_Fabulous het volgende:
Er lopen teveel PM's en TM's rond die alleen maar kijken hoe het zo goedkoop mogelijk kan...

Dat is gelukkig bij onze TM niet het geval.

quote:

Op vrijdag 28 november 2008 13:44 schreef sigme het volgende:
1) Men zou niet werkelijk iemand van straat moeten kunnen plukken - je gebruikt niet voor niks professionele mensen

Daar ben ik het niet helemaal mee eens. Wel voor de testanalyse, maar voor de testuitvoer kun je best studentjes inzetten. Het enige wat ze moeten kunnen is de stappen doorlopen (en die moeten dus m.i. duidelijk genoeg zijn, dat was mijn punt), en in het geval van een bevinding kunnen omschrijven waar het fout is gegaan, wat ze toen deden, of het reproduceerbaar is, een screenshotje maken en wat meer dingen opschrijven, zoals releasenummers en meer van die dingen die je nodig hebt voor een goed bevindingenbeheer.

quote:

Op vrijdag 28 november 2008 13:44 schreef sigme het volgende:
[...] de teststrategie [...]

Ja, die was dus niet specifiek opgesteld. Dan moet ik inderdaad

quote:

Op vrijdag 28 november 2008 13:44 schreef sigme het volgende:
de TM overtuigen van de kortzichtigheid ervan

Haha, ja nee, oké

ik werk met senior testers / test coordinatoren die findings inschieten met: het werkt niet en met een heel globaal reproductie scenario en verwachte en werkelijke resultaat. Als je dan vraagt of het niet wat specifieker kan zeggen ze doodleuk dat het niet zo moeilijk is

Misschien ben ik teveel geschoold om gestructureerd te werken, maar ik vind het absoluut belachelijk dat het getolereerd wordt

quote:

Op zaterdag 29 november 2008 18:07 schreef Fugie het volgende:
ik werk met senior testers / test coordinatoren die findings inschieten met: het werkt niet en met een heel globaal reproductie scenario en verwachte en werkelijke resultaat. Als je dan vraagt of het niet wat specifieker kan zeggen ze doodleuk dat het niet zo moeilijk is

Misschien ben ik teveel geschoold om gestructureerd te werken, maar ik vind het absoluut belachelijk dat het getolereerd wordt

En als je vraagt of ze het even na willen doen terwijl je meekijkt?

Het kan heel lastig zijn/veel tijd kosten om iets helemaal tot in detail op te schrijven. Laten zien werkt dan veel beter.

quote:

Op zaterdag 29 november 2008 18:51 schreef FloggingMolly het volgende:

[..]

En als je vraagt of ze het even na willen doen terwijl je meekijkt?

Het kan heel lastig zijn/veel tijd kosten om iets helemaal tot in detail op te schrijven. Laten zien werkt dan veel beter.

het argument wordt gebruikt omdat ze er vanuit gaan dat iedereen wel weet 'hoe het moet' (dus genoeg ervaring heeft met de applicatie). Dat is in mijn ogen alleen geldig als je weet dat diegene na jou inderdaad die kennis heeft.

Meekijken is wel een optie maar als 3 partijen elke keer op een ander tijdstip moeten meekijken is het beter om het wat gedetailleerder op te schrijven. Zeker aangezien wij een bouwteam in rusland hebben waar je echt alles in detail moet uitleggen omdat het anders niet goed komt

quote:

Op zaterdag 29 november 2008 18:51 schreef FloggingMolly het volgende:

En als je vraagt of ze het even na willen doen terwijl je meekijkt?

Het kan heel lastig zijn/veel tijd kosten om iets helemaal tot in detail op te schrijven. Laten zien werkt dan veel beter.

Ik schiet het er ook globaal in. Als iets niet duidelijk is, dan vragen ze het maar even. Gebeurde me veel te vaak dat ik een heel uitgebreid rapport schreef waarbij de programmeur al bij 1 oogopslag wist waar de fout zat of dat ie gewoon op hold gaat ivm lage prio

Aan de andere kant, als consultants wat rapporteren, dan wil ik het zelf wel allemaal precies weten met klantdatabase/gegevens enzo, want het kost me veel te veel tijd om de situatie zelf te genereren. Ik wil het eerst gewoon effe zien en dan kan ik wel beginnen met het isoleren van de fout om het dan netjes op een gouden schaaltje aan de developer te kunnen geven.

Zo'n "edit" in het issuerapport toevoegen:

consultant: "het gaad fout als deze bwerking wil doen. Dan crashd de app"
En dan mijn edit: "het gaat alleen fout op het moment dat dit en dat vinkje aanstaat en die en die setting op die en die waarde."
Waarderen ze altijd zeer en is leuk speurwerk
_{En die taalfouten zitten er ook in. consultants hebben namelijk een hekel aan issues inkloppen en proberen dan altijd 400 aanslagen per minuut te halen zonder over spelling na te denken}

quote:

Op zaterdag 29 november 2008 18:07 schreef Fugie het volgende:
ik werk met senior testers / test coordinatoren die findings inschieten met: het werkt niet en met een heel globaal reproductie scenario en verwachte en werkelijke resultaat. Als je dan vraagt of het niet wat specifieker kan zeggen ze doodleuk dat het niet zo moeilijk is

Misschien ben ik teveel geschoold om gestructureerd te werken, maar ik vind het absoluut belachelijk dat het getolereerd wordt

Mee eens. En als ze het blijven doen nadat je het herhaaldelijk hebt aangegeven... Terug zetten met request for information? Is misschien wel kinderachtig, maar ik kan ook even niets beters verzinnen (zo vroeg op de zondagochtend)...

quote:

Op zaterdag 29 november 2008 23:42 schreef Knipoogje het volgende:
consultant: "het gaad fout als deze bwerking wil doen. Dan crashd de app"
En dan mijn edit: "het gaat alleen fout op het moment dat dit en dat vinkje aanstaat en die en die setting op die en die waarde."
Waarderen ze altijd zeer en is leuk speurwerk
_{En die taalfouten zitten er ook in. consultants hebben namelijk een hekel aan issues inkloppen en proberen dan altijd 400 aanslagen per minuut te halen zonder over spelling na te denken}

LOL

Maareuh, wat bedoel je met consultants? Ik ben ook consultant.... Een test consultant uiteraard, maar ik geoof dat jij iets anders bedoelt?