Archief - Software tester
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
chine
Legacy Member
Ik werk momenteel als tester ^^
iedereen haat ons omdat wij gelijk hebben :d
edit: mss wa antwoorden op de OP ^^
hangt er echt vanaf op welk niveau ge zit
int begin ist veel uitvoerend werk mor hoe meer ge u zelf engageert hoe meer ge kunt doen
Normaal gezien is er vraag naar een change of komt er een project.
analysten beginnen shit uit te denken. Sturen da naar china(outsourcing) en dan rkijgen wij da terug
tegelijk met de analyse beginnen wij wa de analisten maken te reviewen (iedereen kan fouten maken en fouten op dit punt rechtzetten is goedkoop
)
dan krijgen we de shizzle van china terug en loop ik door alle applicaties aan de hand van een vooropgesteld plan. Dit is vrij saai werk maar je ziet dat het echt iets uithaalt plus je leer alles kenne van de applicatie wat wel tof is als je in het dagelijkse leven er veel meei n contact komt
setup omgeving, datasetup, reviewen code, documenten, meetings etc...
da ist zowa
heb eerst 3 maand gewerkt als bouwer maar is ni echt iets voor mij
op deze moment bekijk ik code en zeg ik dat het ni goed is en die programmeer mag zien dat em da op tijd fixt ^^ en da ik het goedkeur :d
iedereen haat ons omdat wij gelijk hebben :d
edit: mss wa antwoorden op de OP ^^
hangt er echt vanaf op welk niveau ge zit
int begin ist veel uitvoerend werk mor hoe meer ge u zelf engageert hoe meer ge kunt doen
Normaal gezien is er vraag naar een change of komt er een project.
analysten beginnen shit uit te denken. Sturen da naar china(outsourcing) en dan rkijgen wij da terug
tegelijk met de analyse beginnen wij wa de analisten maken te reviewen (iedereen kan fouten maken en fouten op dit punt rechtzetten is goedkoop
)dan krijgen we de shizzle van china terug en loop ik door alle applicaties aan de hand van een vooropgesteld plan. Dit is vrij saai werk maar je ziet dat het echt iets uithaalt plus je leer alles kenne van de applicatie wat wel tof is als je in het dagelijkse leven er veel meei n contact komt
setup omgeving, datasetup, reviewen code, documenten, meetings etc...
da ist zowa
heb eerst 3 maand gewerkt als bouwer maar is ni echt iets voor mij
op deze moment bekijk ik code en zeg ik dat het ni goed is en die programmeer mag zien dat em da op tijd fixt ^^ en da ik het goedkeur :d
Mooncat
Legacy Member
Ik werk momenteel als software tester bij Fortis. De afdeling waarvoor ik werk is Retail Acceptance. Het komt er dus op neer dat ik tests doe voor projecten aangaande pc banking voor Fortis en Pacific, de agentschapsapplicatie.
Meestal krijg ik per kwartaal één project en daar werk ik dan een aantal maanden aan. Projecten waar ik al voor heb getest zijn Mifid (market information for financial instruments directive) dat bv. test of dat iedere belegger een beleggersprofiel heeft als hij orders doet op de beurs, i-sales (vernieuwde pc banking site van Fortis), regressietesten voor het domein sparen en beleggen, ...
Het voordeel van te werken bij Fortis is dat je heel wat kennis opsteekt van financiële producten die je in het echte leven ook kunt gebruiken. Dat zal bij een pharmaceutische onderneming al veel minder het geval zijn natuurlijk.
In het begin zal je vooral uitvoerend werk moeten doen, maar normaal gezien krijg je al gauw meer verantwoordelijkheden zoals testen schrijven, analyses reviewen, meetings houden, defect management opvolgen, taken verdelen, ... Als je een paar jaar ervaring hebt, houd je je ook meer bezig met het management zoals statistieken, testplan schrijven, teststrategie uitdokteren, resources schatten, ...
Software testing is nog relatief jong, maar je kan er wel een aantal richtingen mee uit. Bij de technische kant kan je gaan voor test automatisatie met behulp van tools zoals Quick Test Professional of je toeleggen op vakgebieden zoals datawarehouse of security. Functioneel kan je doorgroeien naar expertgebieden zoals SAP, test manager worden of test consultant. Voor die laatste twee functies moet je bij voorkeur wel +5 jaar ervaring hebben.
Meestal krijg ik per kwartaal één project en daar werk ik dan een aantal maanden aan. Projecten waar ik al voor heb getest zijn Mifid (market information for financial instruments directive) dat bv. test of dat iedere belegger een beleggersprofiel heeft als hij orders doet op de beurs, i-sales (vernieuwde pc banking site van Fortis), regressietesten voor het domein sparen en beleggen, ...
Het voordeel van te werken bij Fortis is dat je heel wat kennis opsteekt van financiële producten die je in het echte leven ook kunt gebruiken. Dat zal bij een pharmaceutische onderneming al veel minder het geval zijn natuurlijk.
In het begin zal je vooral uitvoerend werk moeten doen, maar normaal gezien krijg je al gauw meer verantwoordelijkheden zoals testen schrijven, analyses reviewen, meetings houden, defect management opvolgen, taken verdelen, ... Als je een paar jaar ervaring hebt, houd je je ook meer bezig met het management zoals statistieken, testplan schrijven, teststrategie uitdokteren, resources schatten, ...
Software testing is nog relatief jong, maar je kan er wel een aantal richtingen mee uit. Bij de technische kant kan je gaan voor test automatisatie met behulp van tools zoals Quick Test Professional of je toeleggen op vakgebieden zoals datawarehouse of security. Functioneel kan je doorgroeien naar expertgebieden zoals SAP, test manager worden of test consultant. Voor die laatste twee functies moet je bij voorkeur wel +5 jaar ervaring hebben.
QplQyer
Legacy Member
Ik vraag mij altijd af bij die functies ... of daar tools zoals model checkers (SPIN, TCL, ...), theorem provers (VDM++,Isabelle/HOL,Coq,Perfect Developer...) enzo ooit gebruikt worden?
Lijkt me dat die "architects", om het met een duur woord te zeggen, beter al hun design formeel zouden beschrijven en laten checken door een model checker of een theorem prover, waarna de testers het ook gemakkelijker zouden hebben om een automatische test te laten genereren uit de specificaties.
Lijkt me dat die "architects", om het met een duur woord te zeggen, beter al hun design formeel zouden beschrijven en laten checken door een model checker of een theorem prover, waarna de testers het ook gemakkelijker zouden hebben om een automatische test te laten genereren uit de specificaties.
Mooncat
Legacy Member
Stimpy zei:jij werkt voor een bedrijf ergens op de woluwelaan mss?
Voorlopig nog wel ja
QplQyer zei:
In theorie is dit zeker perfect mogelijk. Meer uitleg hierover kan je hier en hier vinden.
Het probleem met testautomatisatie en testing in het algemeen, is dat het nog vrij jong is. Momenteel wordt er nog een groot verschil gemaakt tussen white box testing en black box testing. Het eerste wordt gedaan door mensen die verstand hebben van de code, voor het tweede heb je dat niet nodig.
Testautomatisatie gebeurt nu nog vrij elemantair met enkele tools voor het testen van security, dos attacks (stress testen), load balancing, ... De meest gekende zijn echter de capture & replay tools die data driven zijn. Dwz dat deze tools werken met een Excel sheet waarin de bekomen waarde wordt vergeleken met de verwachte waarde. Als dit niet klopt, wordt er een defect geregistreerd en stopt het programma (meestal, kan je instellen).
Testautomatisatie is momenteel dus enkel nuttig voor testen waar je een bepaalde waarde moet vergelijken en is dus erg nauw. Testen op het gebied van lay-out, usability, taal, inhoud, ... zullen nooit geautomatiseerd kunnen worden.
In de toekomst kan en zal testautomatisatie een belangrijke rol spelen, maar er zal dan een groter onderscheid moeten komen tussen black box en white box tester dan nu. Werken met modellen en state transition diagrams wordt nu nog zelden gedaan, maar kan bijvoorbeeld heel erg nuttig zijn voor het testen van embedded software.
Het probleem van testing is eigenlijk dat het nu wordt beschouwd als een aanhangsel in het ontwikkelingsproces en niet iets als een volwaardig onderdeel van de development life cycle. Wanneer die bewustwording er wel komt, kunnen bestaande methoden worden aangepast om testing te formaliseren en te integreren in development zoals nu al scrum en extreme programming wordt gebruikt in agile development.
QplQyer
Legacy Member
Wel ja, ik weet dat het in theorie zeker mogelijk is, maar vroeg mij vooral af in hoeverre die testing functies die je wel eens bij vacatures ziet wel iets inhouden van de zogenaamde "formele methoden". Aangezien ik daar vaak het profiel van prof. bachelor in de informatica zag passeren leek me dat kennis van dergelijke technieken niet echt nodig was en die technieken en tools dus zeker niet door testers werden gebruikt. Tenzij prof. bachelors dingen zien over model checking, specificaties, valideringen etc, maar voor zover ik weet heb ik dat toch nog nooit ergens in zo'n opleiding zien staan.Mooncat zei:
Maar mijn vraag daaromtrent is dus beantwoord door je uitgebreide reply, bedankt
.Afhankelijk van wat je testing noemt is het nu niet zo erg jong: model checking bv. bestaat al sinds de jaren '80. En dat is in principe een vorm van geautomiseerd testen.
Daar ben ik het niet met eens eigenlijk.
Op het gebied van lay-out kan zeker testautomatisatie komen: een bepaalde lay-out vorm die ongewenst is en die plots tevoorschijn komt kan gedetecteerd worden. Een vereiste is dat gekend is aan welke regels een goede lay-out moet voldoen. Hetzelfde geldt voor usability, het enige wat nodig is, zijn formele regels die zeggen wanneer iets usable is. Met behulp van vaaglogica kunnen we dan eventueel zeggen dat een programma voor 90% als usable kan worden beschouwd, wat dan eventueel voldoende zou zijn.
Aangezien usability en gewenste lay-out als redelijk algemene eisen kunnen worden gezien kan men dan zelfs heel gemakkelijk verschillende applicaties aan dezelfde regels onderwerpen, wat verhindert dat een specificatie zelf ook bij elke nieuwe applicatie moet worden gecontroleerd op fouten.
Taal kan gecontroleerd worden op spelling, syntax etc.
Dat is inderdaad een probleem. Alhoewel er reeds boeken zijn verschenen die tonen hoe formele methoden kunnen passen in bv. een "agile development" (ik heb iets tegen buzzwords) omgeving (de Software Engineering reeks van Bjorn Diner heeft daar een stuk over als ik mij niet vergis).
Zaken zoals Spec#, JML en Perfect Developer kunnen natuurlijk ook heel erg bijdragen.
Mooncat
Legacy Member
QplQyer zei:
Nu spreek ik voor m'n eigen werk, maar het probleem van usability en lay-out is dat het niet altijd exact is, wat het moeilijk maakt om die te formaliseren. Je moet echt op 1001 details letten waardoor het eigenlijk onbegonnen werk is om dat allemaal in regels te gieten en streef je je doel voorbij als je alles zou formaliseren. Het bespaart immers meer tijd om dit manueel te doen.
QplQyer
Legacy Member
Voor één welbepaald product schiet het zijn doel voorbij, maar op lange termijn niet. Het lijkt me dat lay-out en usability regels redelijk algemeen kunnen worden gehouden en transporteerbaar naar andere programma's.Mooncat zei:
Specifieke fine-tuning voor eventuele extra vereisten van een bepaald programma moet natuurlijk ook nog blijven gebeuren.
De inexactheid van de regels maakt vaaglogica bijvoorbeeld een ideale kandidaat om te gebruiken bij het formaliseren.
Menselijke controle blijft nog altijd nodig, maar het kan wel helpen als een machine al veel lay-out en usability schendingen kan oplossen.
[BAT] Hydra
Legacy Member
Een groot systeem of programma maken is niet iets dat volledig formeel beschreven kan worden. Goed programmeren en designen is een kunst, geen exacte wetenschap. Formele verificatie kan enkel efficient zijn tot op een bepaald niveau. Als jij een goede lay-out checker kan schrijven, compatibel met een veelgebruikte technologie en spreektaal, die een aanzienlijke meerwaarde heeft tov. van een mens dan ben jij mijn held!
chine
Legacy Member
QplQyer zei:
Wat ik dagelijks doe is functionele tests op webapplicatie's.
Daar kan je voor zover ik weet geen testautomatisatie doen?
De verschillende schermen waar de gebruiker moet doorlopen veranderen constant van lay out. De enige manier afaik om layout testen te automatiseren is dmv play and record tools. De effort die je daar insteekt gaat nooit het gewenste resultaat opleveren omdat alle grafische elementen van een webapplicatie constant veranderen.
Bedrijf waar ik zit heeft op 1 jaar tijd 4 keer van layout geswitched ^^.
QplQyer
Legacy Member
Ik heb nergens gezegd dat het volledig formeel beschreven moet worden. In een discussie over of "computer science" een "science" of een "art" is ga ik mij nu niet direct storten, maar laat ons zeggen dat het van beide heeft (en naar mijn mening dat het meer van een toegepaste wetenschap zou kunnen hebben, maar momenteel bijlange nog niet heeft).[BAT] Hydra;9781135 zei:
Moest ik tijd en geld hebben zou ik overigens best wel willen onderzoeken in hoeverre we lay-out kunnen specifiëren en automatisch testen. Lijkt me enorm interessant.
Ik weet niet of er nu al tools bestaan die dergelijke tests kunnen doen. Maar ik bedoelde dat het mij in principe perfect mogelijk lijkt om zoiets semi te automatiseren (zoals ik zei blijft menselijke controle wel nog altijd nuttig, maar een automatische test kan het werk verlichten van de tester en een groter vertrouwen in het systeem voortbrengen). Een programma blijft immers niets meer dan wat sourcecode, als je de sourcecode hebt kan je bepaald gedrag controleren (als je de sourcecode niet hebt is het inderdaad lastiger, dan zou je al muisklikken moeten gaan emuleren met een ander programma, alhoewel ook dat me wel mogelijk lijkt).
QplQyer
Legacy Member
Niemand zegt dat de omgeving niet meer mag veranderen. Mijns inziens zijn er universele constraints die men kan opleggen aan GUI's voor specifieke toepassingen die voor elke toepassing kunnen gebruikt worden. Daarnaast kan men bij verandering ook additionele constraints opleggen die erbij zijn gekomen door de veranderingen. De oude kan men dan eventueel verwijderen, of controleren of ze nog steeds voldaan zijn (in principe verschilt dat niet veel met het testen van het oud gedrag bij een update).chine zei:
chine
Legacy Member
QplQyer zei:
ja maar hoe check je of aan die constraints voldaan is dan ?
en wat zouden dan universele constraints zijn ?
plus wat doen je als je eerst door een flow moet voor je layout kan checken ? muisklikken emuleren zou tof zijn maar dan zit je weer met de zever als die knop verplaatste wordt of zo d:
QplQyer
Legacy Member
Het controleren kan via statische en/of dynamische analyse gebeuren.chine zei:
Er is geen wezenlijk verschil tussen een GUI of een ander deel van een programma: alles wordt opgebouwd met behulp van enkele datastructuren. En die datastructuren kan je controleren. Het is gelijk een muisklik, wat gebeurt er wanneer iemand op een knop klikt? Het besturingssysteem stuurt een Event naar het programma die zegt dat er op de muis is geklikt op die en die locatie. Wat een statische analyse van dat programma dan moet doen is controleren of voor elke Event die zo kan toekomen er geen ongewenste effecten kunnen gebeuren, i.e. stel dat je een functie hebt MouseClickEventHandler(x,y) die zulke zaken afhandelt, dan moet je statisch controleren of voor elke (x,y) waarde er geen ongewenst gedrag wordt vertoond. Kan automatisch als de semantiek van het gehele subsysteem beschreven staat (dat is nu natuurlijk nog totaal niet het geval). Natuurlijk zal het wel redelijk complex (en dus duur in termen van cpu-tijd) zijn om dat te controleren voor een normaal systeem, maar het is een extra hulpmiddel.
De complexiteit kan wel ingetoomd worden door componenten eerst apart te verifiëren.
Universele constraints zijn dingen zoals: een button mag niet bovenop een andere component getekend worden, op elk moment moet elke component zichtbaar zijn, etc.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.