Softwaretesters verenigt u

Gisteren een pakket van 4 Gb getest.
Pakket haal je op vanaf een oplevershare en zet het op een USB stick.. wachten wachten wachten
Vanaf het stickje plaats ik het 4GB pakket op mijn test (productie) PC in de testomgeving, staat om security redenen niet in verbinding met het andere netwerk .. wachten wachten wachten
Vanaf mijn Productie pc kopieer ik het 4 GB pakket naar de distributieserver (SMS).. wachten wachten Distributie server stuurt het 4 Gb pakket naar de daadwerkelijke Test PC (dit is mijn eerste test, maar nog steeds wachten wachte wachten)

Ben je een halve dag verder.

quote:

Op vrijdag 19 september 2008 13:29 schreef octopussy het volgende:
een testerstopic

ik begin per 1 oktober als young professional Test en Quality consultant ( testengineer klinkt beter) ben heel erg benieuwd.

Zelf heb ik niet zoveel met titels. Ik noem mijzelf altijd gewoon tester.

*meldt!

Bezig met tescoordinatie binnen een overheidsinstelling op dit moment. Meeste lol in nieuwbouw en/of technische klussen. Ik heb erg weinig op met releases, beheer, wijzigingen, etc. (Jammer dat dat 70% van de markt is.. )

quote:

Op vrijdag 19 september 2008 13:46 schreef sigme het volgende:

en ik heb tweemaal meegemaakt dat de complete functionaliteit eruit gehaald is, zoals ik voorspeld had..

Krijg je dan ook je melding terug met de status "Opgelost"?

quote:

Op vrijdag 19 september 2008 20:33 schreef sigme het volgende:

[..]

Neuh, dit zijn meestal meldingen in de vorm van gemopper mijnerzijds ("Dit kan helemaal niet. Want .. en .. en .. . Of het gaat 3 weken werk worden en uiteindelijk zal het niet gaan werken", paniekvergaderingen, spreekverboden). En dan een zooi bevindingen, en dan na verdwijnen van de functionaliteit sluiten met status 'vervallen' oid.

Maar de volgende keer luisteren ze *iets* eerder .

Er wordt dan in ieder geval van geleerd.

quote:

Op vrijdag 19 september 2008 13:46 schreef sigme het volgende:

[..]

Ik vind documentatietesten vaak leuk, en je hebt humor nodig om met de personen wiens werk je bekritiseert om te gaan. Tenminste, als je je doel wil bereiken.

Dat vereist toch wel flinke sociale vaardigheden?

documentatietesten= lezen en tiepvauten en redenatiefouten eruit halen? Daar ben jij heel goed in.

quote:

En het is leuk, een soort spel, om te bedenken wat er fout zou kunnen gaan, wat voor gedachtekronkels een bouwer zou kunnen hebben, om van te voren een leuke test bedacht te hebben (dit gaan ze vast fout doen ), en dan gelijk te krijgen .

Dat lijkt me wel lollig, ja. Worden jullie niet als een lastig luis in de pels ervaren?

Spanningsveld?

quote:

Wat ik echt leuk vind -maar ook het meest stressvol- is van te voren van een stuk programmatuur te zeggen dat het niet zal gaan lukken. Dan wordt iedereen heel kwaad, voor elk probleem dat ik opwerp (in ontwerp en later in bouw) wordt steeds verbetener een omweg bedacht - en uiteindelijk lukt het niet. Heel flauw, maar zoiets kan echt maanden als een soort running gag/ doorlopende bevindingenbron slepen, en ik heb tweemaal meegemaakt dat de complete functionaliteit eruit gehaald is, zoals ik voorspeld had..
[..]

Dat lijkt mij inderdaad wel heel stressvol

quote:

Kijk, maar dat is de kunst. De probleemgebieden herkennen, vragen stellen, problemen lokaliseren. Niet eens in de code hoor, eerst in het ontwerp - en later zitten problemen in de programmatuur vaak in de stukken waar je gezeurd hebt over de documenatie.


Kan je met de applicatie in de hand terug naar de ontwerper: kijk nu eens wat de bouwer dacht dat jij bedoelde..
[..]

Detachering betekent dat niksen. Juist een detacheerbedrijf heeft bij voorkeur van die klussen die zich eindeloos uitstrekken en nooit tot voltooiing komen.

Detacheren bij ons is filerijden. Over stress gesproken. Jij woont wel heel gunstig in het Noorden wat dat betreft.

quote:

Op vrijdag 19 september 2008 13:52 schreef sigme het volgende:

[..]

Soms is er geen apparatuur om te testen en zijn er geen ontwerpen om te reviewen of te analyseren. En dan is er domweg niks te doen.

Op momenten dat er uitgevoerd wordt (dus je testgevallen op de applicatie loslaten) wil de te testten applicatie nog wel eens op zwart gaan - dagenlang als je pech hebt. Crash, of nieuwe oplevering, of een andere partij moet wat op de omgeving en mag niet gestoord worden.

En ik heb ook wel ergens gezeten waar voor de testuitvoer veel meer tijd was dan er nodig was. Altijd. Veel meer. Na twee uurtjes was je wel klaar, en dan lag de hele dag er nog. Twee jaar lang .

Ik hoef dan geen verslagen te schrijven hoor. Wat zou erin staan? 6 uur fok, 1 uur nieuwssites, 1 uur extra rookpauzes?

Hmmmm typisch, dat je wel test maar niet schriftelijk rapporteert? alles mondeling aan de bouwer?

quote:

Op donderdag 18 september 2008 18:46 schreef Buschetta het volgende:
vraagje aan de heren software testers

quote:

Op donderdag 18 september 2008 18:46 schreef Buschetta het volgende:
Als het de produktie 30% verhoogt is een crash dan acceptabel op 1 werkdag ?

Waarom vraag je dat aan de testers? Wij bepalen de acceptatiecriteria niet. Tenminste, dat zou niet moeten.

quote:

Op donderdag 18 september 2008 19:05 schreef sigme het volgende:

[..]

Mogen dames softwaretesters ook wat zeggen?

Als tester geef je geen antwoord op deze vraag: het management bepaalt of het acceptabel is. De tester meldt dat het kreng eenmaal per dag crasht _{(en dat dit een vertraging van het testen heeft veroorzaakt.)}

quote:

Op donderdag 18 september 2008 21:30 schreef mgerben het volgende:
Wat voor bevindingenadministratie gebruiken jullie?
Merk je dat bevindingen worden opgelost en dan weer bij jou worden teruggemeld?

Test Director en ClearQuest. Ik vond TD handiger werken, maar die werdt gesynct met CQ, omdat de bouwers met CQ werkten... ach ja...
Bevindingen worden niet zozeer bij me gemeld, maar ik ben de submitter en ik heb een query waarbij alle openstaande bevindingen waarvan ik de submitter of owner ben laat zien.

quote:

Op donderdag 18 september 2008 22:00 schreef Alicey het volgende:

[..]

Ik ben zelf geen tester, maar kan vertellen hoe het gaat binnen de organisatie waar ik werk.
[..]

Ontwikkelaars kunnen vervolgens bepalen wat er mee gebeurt, wat prioriteit heeft, wie wat onder zijn verantwoordelijkheid neemt etc.

[ Bericht 17% gewijzigd door LadyXochi op 19-09-2008 22:32:18 ]

quote:

Op vrijdag 19 september 2008 12:47 schreef EchtGaaf het volgende:

[..]

En je zou goed moeten kunnen communiceren en sociale vaardigheden hebben. En je zou stressbestendig moeten zijn... ..

https://sjobs.brassring.com/11043/asp/tg/cim_jobdetail.asp?jobId=115102&type=search&JobReqLang=82&recordstart=1&JobSiteId=5174&JobSiteInfo=115102_5174&GQId=0&partnerid=25005&siteid=5174

Nou dat kan ik dus wel vergeten.

Logica
Zitten best goede mensen tussen, maar wat die organisatie op het moment doet snap ik niet helemaal, CMG'ers waren trots op hun club, Logica mensen hebben het alleen maar over wat er niet meer deugt in die club lijkt het wel....

quote:

Op vrijdag 19 september 2008 22:20 schreef LadyXochi het volgende:

Wat gerapporteerd wordt aan het management na testrondes. Het is een vrij (kleine) platte organisatie, dus management valt te lezen als directie. Aangezien die doorgaans betere dingen te doen hebben dan testresultaten monitoren wordt die verantwoordelijkheid bij testers en ontwikkelaars gelegd (Van testers wordt ook een zekere verantwoordelijkheid verwacht door verificatie uit te voeren op wijzigingen van wat gemeld is. Bij die verificatie kan iets ook weer terug geschoven worden naar iemand anders of naar een andere afdeling).

Voor een grotere organisatie zou het een enge ontwikkeling zijn, maar in een kleine organisatie is het het meest efficiënt om het op die manier te doen.

quote:

Op vrijdag 19 september 2008 22:55 schreef Captain_Fabulous het volgende:

[..]

Logica
Zitten best goede mensen tussen, maar wat die organisatie op het moment doet snap ik niet helemaal, CMG'ers waren trots op hun club, Logica mensen hebben het alleen maar over wat er niet meer deugt in die club lijkt het wel....

Ik heb geen hoge dunk van de IT branche. Veel te grillig en verre van logisch. En zo conjunctuurgevoelig als de nete....

Net zoals de telecombranche. Vreselijke branche.

Nog een tester meldt zich, prachtig beroep en je hebt contact met alle afdelingen, als tester zijn je softskills ook van bijzonder belangrijke waarde om je vak goed uit te oefenen en verschillende talen binnen de organisatie te spreken. Je spreekt met de business, je spreekt met programmeurs, functioneel ontwerpers, acceptanten, heerlijk, een spin in het web, veel communiceren, heerlijke druk, werken in teamverband.

quote:

Op zaterdag 20 september 2008 05:07 schreef sigme het volgende:

[..]

Als er niks te testen is, is er niks te rapporteren. Op van die dagen dat er niks getest wordt, wordt er dus ook niks gerapporteerd.

OK, dat is duidelijk.

quote:

Op dagen dat er wel gewerkt wordt, wordt daarover wel min-of-meer bijgehouden wat de voortgang is. Wie heeft wat gereviewd / hoe ver staat dat / welk reviewcommentaar is al terug / is het al verwerkt / wie is met welke uitvoer bezig / hoe ver / bevindingen? / welke bevindingen staan nog open.

Testers zelf schrijven gewoonlijk geen verslagen: ze schrijven reviewcommentaar, bevindingen, analyses, logische & fysieke testgevallen en de resultaten. Steeds op het moment dat ze gedaan worden - er ligt nooit een stapel 'dingen die je al wel weet maar nog niet genoteerd hebt'.

Maar eigenlijk is het best sociaal werk. Test je in je eentje? En is het "samenwerken" hoofdzakelijk communicatie van bevindingen en opstellen van test protocollen etc. etc. ?

Ga je in je eentje naar een klus toe?

Ergo: volgens mij ben jij best een sociaal wezen dat van samenwerken houdt

quote:

Op zaterdag 20 september 2008 08:06 schreef SpankTheMonkey het volgende:
Je spreekt met de business, je spreekt met programmeurs, functioneel ontwerpers, acceptanten, heerlijk, een spin in het web, veel communiceren, heerlijke druk, werken in teamverband.

Is dit dan werk voor mensen met een HFA

Test Driven Development is tegenwoordig toch dè methodiek?

quote:

Op zondag 21 september 2008 14:12 schreef servus_universitas het volgende:
Test Driven Development is tegenwoordig toch dè methodiek?

<cynic mode>
Het is de methodiek die men zegt te gebruiken in veel gevallen. Dat zegt nog niets over hoeveel er werkelijk getest wordt. </cynic mode>

quote:

Op zondag 21 september 2008 14:08 schreef EchtGaaf het volgende:

[..]
En is het "samenwerken" hoofdzakelijk communicatie van bevindingen en opstellen van test protocollen etc. etc. ?

Een paar voorbeelden.

Samenwerken met de business analist, grafisch ontwerper, technisch ontwerper, etc.
Je krijgt van deze mensen een aantal documenten. Dit zijn requirements, specificaties, GUI design, etc. Je reviewt deze documenten en geeft de maker feedback. Ook stel je vragen over zaken die niet helemaal duidelijk zijn. Je wil controleren of je alles zo hebt geïnterpreteerd als de maker heeft bedoeld. Het is de bedoeling dat alles maar op één manier te interpreteren is, maar helaas is dat bijna nooit het geval. Dus moet je alles goed doornemen en d.m.v. interactie duidelijkheid scheppen. Ziehier alvast een goed punt om je communicatieve skills toe te passen.

Samenwerken met de ontwikkelaars.
Jij baseert je tests op de documenten die ik in de vorige alinea heb genoemd. Maar ook de ontwikkelaars gebruiken deze als basis om he applicatie mee te bouwen. Als je als tester al betrokken wordt bij de bouw, bijvoorbeeld door tussentijdse demootjes, de code te reviewen en te overleggen met de bouwers, kun je er al snel achter komen als zij iets bouwen op een andere manier dan jij verwacht. Als je dit contrateert, kun je kijken hoe er verschil is ontstaan in interpretaties en indien nodig worden de ontwerpers erbij gehaald om knopen door te hakken of meer duidelijkheid te geven.

Daarna krijg je uiteraard communicatie en samenwerking n.a.v. gevonden defects. Is het een fout in de applicatie, een testfout of zit de fout al in de documentatie (en is die in een vorige fase over het hoofd gezien)?

En vergeet ook niet de communicatie met de projectleider, die dan weer aan de stakeholder moet kunnen verkopen waarom er bijvoorbeeld meer test effort nodig is, of waarom je een No Go adviseert.

Zomaar even een aantal zaken die me te binnen schieten.

quote:

Op zondag 21 september 2008 21:31 schreef LadyXochi het volgende:

[..]

Een paar voorbeelden.

Samenwerken met de business analist, grafisch ontwerper, technisch ontwerper, etc.
Je krijgt van deze mensen een aantal documenten. Dit zijn requirements, specificaties, GUI design, etc. Je reviewt deze documenten en geeft de maker feedback. Ook stel je vragen over zaken die niet helemaal duidelijk zijn. Je wil controleren of je alles zo hebt geïnterpreteerd als de maker heeft bedoeld. Het is de bedoeling dat alles maar op één manier te interpreteren is, maar helaas is dat bijna nooit het geval. Dus moet je alles goed doornemen en d.m.v. interactie duidelijkheid scheppen. Ziehier alvast een goed punt om je communicatieve skills toe te passen.

Samenwerken met de ontwikkelaars.
Jij baseert je tests op de documenten die ik in de vorige alinea heb genoemd. Maar ook de ontwikkelaars gebruiken deze als basis om he applicatie mee te bouwen. Als je als tester al betrokken wordt bij de bouw, bijvoorbeeld door tussentijdse demootjes, de code te reviewen en te overleggen met de bouwers, kun je er al snel achter komen als zij iets bouwen op een andere manier dan jij verwacht. Als je dit contrateert, kun je kijken hoe er verschil is ontstaan in interpretaties en indien nodig worden de ontwerpers erbij gehaald om knopen door te hakken of meer duidelijkheid te geven.

Daarna krijg je uiteraard communicatie en samenwerking n.a.v. gevonden defects. Is het een fout in de applicatie, een testfout of zit de fout al in de documentatie (en is die in een vorige fase over het hoofd gezien)?

En vergeet ook niet de communicatie met de projectleider, die dan weer aan de stakeholder moet kunnen verkopen waarom er bijvoorbeeld meer test effort nodig is, of waarom je een No Go adviseert.

Zomaar even een aantal zaken die me te binnen schieten.

Het is dus een heel sociaal beroep ....

quote:

Op zondag 21 september 2008 14:12 schreef servus_universitas het volgende:
Test Driven Development is tegenwoordig toch dè methodiek?

Het kan ook de methodiek zijn die een ontwikkelaar zelf toepast bij het ontwikkelen van een geisoleerd stuk code. TDD is zeker niet allesomvattend.

ISTQB gehaald. 36 van de 40 goed.

quote:

Op zondag 21 september 2008 14:12 schreef servus_universitas het volgende:
Test Driven Development is tegenwoordig toch dè methodiek?

De meeste developers kennen het begrip nog steeds niet, de meeste projectleiders vinden het teveel geld kosten (op de long run zou het goedkoper moeten zijn) en eigenlijk heeft het niets met testers (of het testvak) te maken, maar alles met development (en de manier waarop ontwikkelaars hun code schrijven en testen).

Dat is de samenvatting