Functionele fouten voorkomen

[kakanox]

Gezien het wel een erg lang verhaal wordt stel ik eerst even de vraag:

Weten jullie tools en/of methodieken om functionele fouten te controleren of voorkomen?

De reden voor deze vraag is als volgt:
De afgelopen jaren ben ik steeds "dieper" in ERP/CRM aan het werk gegaan. Mijn werk hierin is meestal vooral het vertalen van bedrijfsprocessen naar functionaliteit in de software. In sommige gevallen hoort daar echter ook het bouwen van een stuk maatwerk of een uitgebreide rapportage. Dit is - afhankelijk van de klant - soms Python, soms Java, toch wel vaak SQL, soms VB.net en soms komt QlikView, Pentaho of Crystal Reports voorbij.
Gisteren heb ik bijvoorbeeld een rapport gebouwd dat afwijkingen op machineplanningen (+ achterstanden op die planning) leest en op basis hiervan capaciteit uitrekent, zodat nauwkeurig bepaald kan worden wanneer er weer ruimte is in de productie van klant in kwestie. Het technische deel is zo nu en dan de kern van mijn probleem:

Situatie
Vanochtend testte ik mijn rapport en ontdekte hierbij dat er - volgens mij onterecht - één van de zeven dagen van een week in één specifieke week niet meegenomen werd in mijn berekening. Ik ben hierop door de code gaan spitten (deze is uiteraard netjes voorzien van een procesbeschrijving in comments, zodat ik weet waar ik zit) en had na het weergeven van enkele variabelen op specifieke momenten de volgens mij-bug eruit. Na een uur ombouwwerk bleek ik een workaround gebouwd te hebben voor inconsistentie in de gegevens (onderliggende planningsdatabase), dit moet dus niet

Ik heb dus wéér een uur weggegooid aan nodeloos werk omdat ik blijkbaar het overzicht niet houd; het lukt mijn brein niet om variabelen in mijn hoofd even te "vullen" en zo de code door te lopen om te kijken wat er onder bepaalde omstandigheden gebeurt. Ik ben niet de beste programmeur (of eigenlijk geen programmeur), maar hier moeten toch meer mensen last van hebben?

Wat heb ik al geprobeerd?
Ik heb al een aantal keer gegoogled en ook al diverse topics in de Devschuur door zitten spitten (waaronder de FAQ), maar ik vind vooral tools en methodieken die van toepassing zijn op puur technische missers (syntaxis, performance, inconsequentie). Waar ik tegenaan loop produceert geen foutmeldingen, ik loop echter wel het risico dat m'n klant incorrecte gegevens gepresenteerd krijgt en daarmee op de verkeerde manier z'n bedrijf gaat sturen.

Hoe werk ik nu?
Mijn werkwijze is (bij de uitgebreidere klussen) momenteel als volgt:
- eerst schrijf ik het probleem/de klantvraag uit (als m'n klant dat niet al gedaan heeft);
- daarna probeer ik in een soort flowchart helder te krijgen welke stappen ik een stuk maatwerk of een rapport wil laten maken;
- vervolgens zoek ik uit welke gegevens ik wil presenteren (zodat ik weet welke tabellen in de db of db's ik nodig heb);
- dan bouw ik een model om de data te verzamelen indien nodig;
- hier bouw ik vervolgens de query/queries in;
- op basis hiervan probeer ik de mogelijke uitersten te beredeneren en vul deze in als testdata;
- daarop bouw ik aan de hand van m'n flowchart een stuk maatwerk of rapport;
- hierna volgt uiteraard een aantal tests op basis van mijn eigen data en de klantdata.

Wat zoek ik?
Software waarmee ik een functioneel ontwerp wat "dieper" door kan kijken dan een (vrij in te vullen) flowchart, methodieken die te gebruiken zijn om fouten te voorkomen, dingen die bijv. een softwaretester in z'n standaardhandelingen heeft zitten maar waar ik nog lang niet aan gedacht heb, boeken over dit onderwerp en alle andere tips die me zouden kunnen helpen.

[ Voor 8% gewijzigd door kakanox op 09-01-2013 10:10 . Reden: wat duidelijker, typo's ]

[Hydra]

Wat jij beschrijft is gewoon een technische fout hoor, daar is niks 'functioneels' aan. Anywho, met Test Driven Development voorkom je veel fouten door eerst je test te schrijven (wat gaat er in, en wat zou eruit moeten komen) en daarop je software te maken. Je slaat dan eigenlijk 2 vliegen in 1 klap: je hebt meteen je unit test (is m.i. een must maar wordt vaak door 'tijdsdruk' achteraf niet meer gedaan) en je hebt (nog belangrijker) vooraf precies nagedacht over wat de uitvoer voor een functie zou moeten zijn.

Datzelfde zou je kunnen doen voor bijvoorbeeld SQL uitvoer: leg eerst vast wat de in/uitvoer moet zijn, en schrijf dan de SQL query. De uitvoer daarvan kun je dan toetsen aan de test die je vastgelegd hebt.

Dit neemt overigens niet weg dat bugs, ook de vervelende die geen foutmelding geven, altijd voor zullen blijven komen. Het is onmogelijk deze volledig uit te bannen.

Er bestaat overigens geen software die zo slim is dat hij een 'functioneel' ontwerp door kan kijken. De vertalen van functioneel naar technisch is mensenwerk en zal dat voorlopig nog wel ff blijven.

[kakanox]

Ah kijk, Test Driven Development, da's een term die ik nog niet tegen was gekomen. Zeer nuttig voer voor Google

Ik had overigens niet verwacht iets te vinden waarmee ik het ontwerp echt "unattended" kan bekijken, maar wel een tool waarmee ik m'n eigen werk beter kan bewaken. Ik beeld if-statements bijvoorbeeld vaak uit in mijn flowcharts. Als ik nu een flowchart zou kunnen maken die eist dat ik alle mogelijke uitkomsten afvang dicht ik alweer een mogelijk gat.

Waarom ik het geen technische fout wilde noemen is omdat ik een uur heb zitten bouwen door een denkfout van mezelf, maar misschien is dat inderdaad toch incorrect.

[ Voor 17% gewijzigd door kakanox op 09-01-2013 10:54 . Reden: meer info ]

[Hydra]

Tja, de meeste software devs gaan gewoon niet elk stuk software op die manier in flowcharts gieten. Dat is nuttig om business processen te visualiseren maar 'gewone' software programmeer je uit je hoofd gewoon omdat het niet lastig is. Alleen moeilijke algorithmen schrijf je ff uit op een papiertje en je maakt test-cases voor de in-uitvoer.

[Douweegbertje]

Even kort door de bocht lees ik dat je eigenlijk vrij weinig op papier zet.
Je maakt wel flowcharts, maar aan de hand van wat?
Mijn ervaring is, dat bij de grotere projecten het handig is om een groot gedeelde op papier te zetten.
In feite van A tot Z, dus handelingen, processen, database structuur, etc

Dit kost even wat tijd, ja dat klopt. Maar in feite zou je dan al *niets* meer over het hoofd zien wat uiteindelijk tijd opleverd.

Ik denk dus dat je al goed af bent met één standaard.
Waarom zou een standaard iets als UML, Prince2 etc etc. niet afdoende zijn?

[kakanox]

douweegbertje schreef op woensdag 09 januari 2013 @ 11:11:Ik denk dus dat je al goed af bent met één standaard.
Waarom zou een standaard iets als UML, Prince2 etc etc. niet afdoende zijn?

Dat zal je me niet horen zeggen. Heb er simpelweg geen ervaring mee. Hierin worden dus ook dit soort zaken besproken? Ook daar ga ik eens even naar zoeken.

[Hydra]

kakanox schreef op woensdag 09 januari 2013 @ 12:18:
[...]
Dat zal je me niet horen zeggen. Heb er simpelweg geen ervaring mee. Hierin worden dus ook dit soort zaken besproken? Ook daar ga ik eens even naar zoeken.

Prince2 is een projectmanagementmethodiek dus wat dat hier te zoeken heeft volg ik niet zo. UML draait om het ontwerpen van software en dat is ook hier je issue niet.

[Speedmaster]

Ik neem aan dat je het principe "garbage in garbage out" kent?
Probleem is vaak dat bestaande ERPs/DBs gevuld zijn met "foutieve" waarde, althans voor jouw query uitvraag.
Dit komt vaak door verschillende werkwijze bij invoer.
Wil je een sluitende uitvraag hebben dan zal je eerst de bestaande waarde's na moeten lopen en zonodig aanpassen indien mogelijk.
Daarnaast zou ook gekeken moeten worden naar een validatie op invoervelden waardoor je het probleem van foutieve waarde kan beperken.
Voordeel is dat jouw uiteindelijke query minder complex zal zijn en sneller een resultaat zal tonen.

En uiteindelijk bespaar jij tijd....

[Zoijar]

kakanox schreef op woensdag 09 januari 2013 @ 10:51:
Waarom ik het geen technische fout wilde noemen is omdat ik een uur heb zitten bouwen door een denkfout van mezelf, maar misschien is dat inderdaad toch incorrect.

Ik zit wel eens dagen om te bouwen door een denkfout; dat je achteraf denkt, "huh, dat kan helemaal niet zo". Ik zie niet hoe je je software helemaal van te voren compleet bug vrij op kan schrijven. Maar dat heb ik altijd al een probleem met ontwerpen gevonden, de mooiste ontwerpen moeten na uitwerking in de praktijk toch net even anders.

[Hydra]

Zoijar schreef op woensdag 09 januari 2013 @ 13:33:
Ik zit wel eens dagen om te bouwen door een denkfout; dat je achteraf denkt, "huh, dat kan helemaal niet zo". Ik zie niet hoe je je software helemaal van te voren compleet bug vrij op kan schrijven. Maar dat heb ik altijd al een probleem met ontwerpen gevonden, de mooiste ontwerpen moeten na uitwerking in de praktijk toch net even anders.

Of gewoon:
Klant: "Ik ging er vanuit dat..."
Jij: <kijkt glazig>

Zo ging het bij mij meestal.

[Woy]

Hydra schreef op woensdag 09 januari 2013 @ 13:37:
[...]


Of gewoon:
Klant: "Ik ging er vanuit dat..."
Jij: <kijkt glazig>

Zo ging het bij mij meestal.

Daarom is het ook zo belangrijk om vaak deelopleveringen te hebben, en te zorgen dat de klant betrokken is bij de ontwikkeling, en niet pas achteraf het complete pakket moet beoordelen. Hoe eerder je een dergelijke situatie hebt, des te minder effort kost het om nog aanpassingen te doen

[jbdeiman]

Test gedreven ontwikkeling (TestDriven Development) is dan echt wel een goede bezigheid voor je. Als je met scenario's gaat werken (SpecFlow is daar een bekend voorbeeld van) waarmee je testen krijgt die je kan vullen met deelstappen, dan ga je automatisch stapsgewijs je code bouwen.

In jou geval heb je bijvoorbeeld een bepaalde input. Om daar mee verder te kunnen werken moet het eerst omgezet worden naar een andere set, zodat het beter te gebruiken is in je code. Door dit principe goed uit te denken en alleen dit principe eerst te bouwen / testen (*unittesten*) kan je op elk stuk van je code controleren wat er met de input gebeurt.
Stel nu dat je 10 stappen nodig hebt om van sitatie 1 (beginsituatie) naar de eindsituatie te komen:
1. Data ophalen (testen of je alles krijgt)
2. Data omzetten in begrijpelijke brokken (testen of de data behalve de vorm nog wel dezelfde gegevens bevat)
enz..
Tot je bij stap 10 bent.

Door op een dergelijke manier te werken kan je stapje voor stapje nagaan of hetgeen je aan het bouwen bent nog doet wat het moet doen tot op dat punt. Op die manier kan je (alleen wanneer je een goede testset hebt en weet wat er na elk stapje uit moet komen!) eventuele fouten eerder ontdekken en oplossen voordat je de gegevens doorgeeft aan de volgende stap uit je chart.

[Hydra]

Woy schreef op woensdag 09 januari 2013 @ 15:31:
[...]

Daarom is het ook zo belangrijk om vaak deelopleveringen te hebben, en te zorgen dat de klant betrokken is bij de ontwikkeling, en niet pas achteraf het complete pakket moet beoordelen. Hoe eerder je een dergelijke situatie hebt, des te minder effort kost het om nog aanpassingen te doen

Joh, vertel mij wat. Maar dit ging om deelopleveringen van een week waar een klant dan een maand na oplevering nog een keer mee aan kwam kakken bijvoorbeeld. Wel af en toe ff diep moeten zuchten

[Woy]

Hydra schreef op woensdag 09 januari 2013 @ 16:01:
[...]


Joh, vertel mij wat. Maar dit ging om deelopleveringen van een week waar een klant dan een maand na oplevering nog een keer mee aan kwam kakken bijvoorbeeld. Wel af en toe ff diep moeten zuchten

Ik weet ook hoe het vaak gaat, maar dat betekent gewoon niet genoeg commitment van de klant. Vaak komen ze alleen even snel kijken of het er leuk uitziet, maar kijken ze niet kritisch of het wel is wat ze willen.

Het blijft altijd een lastig traject natuurlijk, want je moet ook wel wat inbeeldingsvermogen hebben om je voor te stellen hoe een compleet product er uit ziet als je alleen een gedeelte van de functionaliteit voorgeschoteld krijgt.

[Kama]

Google eens naar het opstellen van software requirements (requirement management). Er zijn verschillende methodes om requirements van een te bouwen product te vast te stellen (=requirement elicitation). Let hierbij op de requirements dus geen software-specificaties of design zijn. Requirements is juist de ondubbelzinnige functionele "vraag"/doel die de voor het systeem geldt. Bijv. "Als er een gat in de planning ontstaat moet dit worden opgevuld door de eerstvolgende order, gesorteerd op leveringsdatum".

Requirements kun je hierarchisch opstellen, dus je begint met een high-level "business requirement", wat je weer verder gaat detailleren naar functionele requirements, die je weer verder specificeert etc.

Op de requirements kun je ook weer (functionele) tests baseren (requirement based testing) die verfieren dat de requirements inderdaad geimplementeerd zijn en je kunt er zelfs je design meer reviewen op compleetheid.

Het vinden van de requirements is typisch het werk van een business consultant. Dus niet van een ontwikkelaar. Requirements stellen je in staat om aan de klant te laten zien / met de klant samen overeen te komen wat de exacte formulering van het probleem is en wat de "constraints" zijn. Vaak al een hele klus op zich.

De ontwikkelaar moet met de requirements een functionele/technisch design maken (het functionele "antwoord"). Kan dezelfde persoon zijn, maar het zijn wel 2 verschillende rollen.

[ Voor 3% gewijzigd door Kama op 11-01-2013 15:37 ]

[PdeBie]

Woy schreef op woensdag 09 januari 2013 @ 16:57:
[...]

Ik weet ook hoe het vaak gaat, maar dat betekent gewoon niet genoeg commitment van de klant. Vaak komen ze alleen even snel kijken of het er leuk uitziet, maar kijken ze niet kritisch of het wel is wat ze willen.

Eens, maar het zit hem ook echt in de wijze waarop je het aan hem presenteert en hoe je je vragen stelt.
Laat de klant zelf eens klikken in een demo, dat levert vaak hele nuttige info op.
Al is het maar een reactie als 'hey, als ik hier klik dan doet hij .....'. Dat kan opmerkingen en vragen achteraf schelen.

[EnnaN]

Gewoon. testen.

Test-driven development heeft er van mijn part niets mee te maken, das meer een ontwikkel-methode. Of je nou gewoon goede unit-tests maakt, of test-driven je boel maakt, uiteindleijk gaat het er om dat je de werking checkt door je tests.

Je unit-test test of je alle dagen meenement, jouw code doet dat niet -> rode waarschwuing, iedereen blij

[Kama]

EnnaN schreef op vrijdag 11 januari 2013 @ 16:04:
Gewoon. testen.

Je unit-test test of je alle dagen meenement, jouw code doet dat niet -> rode waarschwuing, iedereen blij

Helaas is testen niet altijd zo gewoon... Je moet namelijk wel goed weten wat de gewenste uitkomst is. Als jij denkt A en de klant denkt B en jij test alles op A, dan is het toch nog fout...

Dus leg goed vast wat de klant verwacht voordat je begint. De klant moet zich daarbij het liefst beperken tot de formulering van zijn functionele verwachting en niet al in termen van "hoe het systeem moet gaan werken"... Daar zijn systeemontwikkelaars veel beter in... (Zie mijn post hierboven over requirements).

[ Voor 4% gewijzigd door Kama op 11-01-2013 16:17 ]

[Hydra]

Woy schreef op woensdag 09 januari 2013 @ 16:57:
[...]

Ik weet ook hoe het vaak gaat, maar dat betekent gewoon niet genoeg commitment van de klant. Vaak komen ze alleen even snel kijken of het er leuk uitziet, maar kijken ze niet kritisch of het wel is wat ze willen.

Mwa, commitment. Het probleem in deze was gewoon dat de functionele mensen die dit in de schoenen geschoven kregen ook nog hun 'normale' taken hadden. Bovendien waren ze verantwoordelijk voor de functionaliteit van zowel onze applicatie als die van een andere leverancier en die projecten liepen ook nog eens parallel. Het was geen kwestie van willen. Voor de dame in kwestie was dit ook nog eens het eerste integratieproject en ze had niet helemaal door dat dergelijke aannames voor vervelende verassingen kunnen zorgen, die misser leidde er wel toe dat de deadline (en de release) een week verschoven moest worden.

Natuurlijk was het als projectmanager voor een groot deel ook mijn verantwoordelijkheid, maar deze had ik echt niet aan zien komen omdat het voor mij juist zo enorm obvious was. Oftewel: nooit aannemen dat een klant het begrijpt zelfs als ze zeggen het wel te begrijpen