Skip to content

Instantly share code, notes, and snippets.

@jovaneyck

jovaneyck/notes.md

Last active January 18, 2018 11:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jovaneyck/3ecf08ff94d43a87742b7f0d64b0f0e1 to your computer and use it in GitHub Desktop.
Save jovaneyck/3ecf08ff94d43a87742b7f0d64b0f0e1 to your computer and use it in GitHub Desktop.
Download ZIP
Kennis & Pasta - Test pyramid
Raw
notes.md

Points to discuss

  • What is a "unit test"? What is an "integration test"? "integrated test"? "microtest"?
  • WHY unit test?
  • ROI, economy of tests, brown-field contexts
  • Test pyramid as a bug filter analogy
  • Who writes the tests?
  • When to start writing tests?
  • introducing automation in an organisation
  • Segue to hexagonal, integrated tests, double-loop TDD (SDS example)
  • Tooling
  • Defining a testing approach
  • Defining a (unit) testing approach
  • Pyramid & legacy code
  • CD pipeline

Q&A

  • Hoe herken je de nadelen als er niet aan UT gedaan wordt
    • "fixed" duikt na een tijd weer op
    • opleveren gaat trager en trager naarmate het product evolueert
  • Welke typische gevolgen kunnen vermeden worden door aan UT te doen
  • wat is een goed begin voor UT?
    • Start small, maar overdrijf: "Vanaf nu wordt ELKE bug gecovered met een unit test alvorens te fixen"
    • Greenfield: start off right
    • Low-hanging fruits
    • High-risk areas
  • Hoe maken we dit nu daadwerkelijk concreet qua implementatie? Zoals gisteren gezegd is ons al meerdere keren dit high level plaatje uitgelegd. Gisteren werd er dan zoiets gezegd als "maar je moet helemaal niet de technische kennis hebben om dit effectief te gaan implementeren". Ben hier om eerlijk te zijn toch niet helemaal akkoord mee. Ik vind dat we iets meer low level moeten weten hoe we dit nu ook effectief in de praktijk gaan uitrollen wanneer we zo straffe praat gaan verkopen. "If you talk the talk, you gotta walk the walk.". Wil natuurlijk niet zeggen dat iedereen van 0 tot einde dit moet kunnen implementeren, maar een eerste implementatie stap zelf kunnen ondernemen als eventuele proof-of-concept lijkt mij wel waardevol. Anders moet je al direct zeggen "ja uh ik kan dat niet maar bij ons in de firma is er wel iemand die dat hier gaat kunnen doen hoor".
  • Hoe omgaan met change resistance in de organisatie? Argenta is bijvoorbeeld een organisatie waar op meerdere levels veel resistance gaat zijn (directiecomité, release management, testing, development teams, project managers, algemene cultuur, ...).
  • Hoe begin je met dit aan te brengen bij de klant? Ik zit hier bijvoorbeeld op het 6de verdiep geïsoleerd in een team van 8 mensen die weinig raakvlak hebben met de bredere organisatie. Binnen het domein testing is er een testforum maar dat is nu ook niet echt het medium om daar even de grote change profeet te gaan uithangen. Ik zie gewoon niet echt een opportunity om hier zo een change te kunnen opstarten.
  • Denk dat het belangrijk is dit ook dieper in praktijk te kaderen. Had gisteren een vraag gesteld over de investering nodig en het rendement op die unit testen in plaats van GUI, want ik vond dat het rendement nogal rooskleurig voorgesteld werd tov de investering, zelfs na de verdere uitleg van Stijn en Joeri. Het was pas nadat jij zei "ja op legacy code moet je dat niet doen" dat ik mee was. Ik stelde het mij namelijk continu voor als change binnen test automation op legacy applications.
  • Daarop volgend: wat is een goed moment om hier in te stappen? Op Argenta zitten we nu al voorbij 80% development voor die nieuwe platformen die de legacy vervangen. Is de boot daar dan al gemist?
  • Voordeel API vs GUI
  • Welke tools
  • REST vs SOAP
  • Testdiepte?
  • ik neem aan dat de requirements er anders uit zien voor API vs Funct testen
  • Hoe bepaal je de testaanpak voor API/WS testing?
  • Hoe bepaal je evenwicht tussen API en GUI testing (al dan niet manueel)?
  • Legacy applicaties vs nieuwe ontwikkeling (andere aanpak)?
  • opbouw unit testen? Hoe aanpak bepalen vanuit testing?

Links

Books

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment