.. Copyright (C) 2015, ALbert Mietus, SoftwareBeterMaken.nl; Part of Pathways project

workshop: Doelgroep (FAQ)
*************************
:language: Dutch


Is de workshop (alleen) bedoeld voor “aankomend testers”?
=========================================================

* Nee; de doelgroep is veel breder: het concept kom uit Lean/Agile/Scrum (Geïntegreerd Agile)
  aanpak. Iedereen in zo’n ontwikkel/projectaanpak is nodig cq welkom.
* Vooral (ervaren) testers, om ervaring op te doen met moderne automatisch testen, zoals steeds
  meer gebruikt zal/gaat worden in Lean/Agile/Scrum ontwikkelingen.
* Ook programmeurs zijn wel welkom; zeker die (gaan) werken in een agile omgeving. Waar zij de
  testers moeten “ondersteunen” door het framework te bouwen/onderhouden/aanpassen
* Er zijn ook oefeningen, die (uitsluitend) gericht zijn op (die) programmeurs


Is *selenium* belangrijk voor ‘Pathways’? Of voor de workshop?
===============================================================

* Pathways is **onafhankelijk** van selenium; maar kan die tool als library gebruiken.
* De tester/gebruiker/workshop deelnemer hoef niets van selenium te weten!
* Voor een van de oefeningen wordt (onderwater) selenium gebruik; daarom moet dit (vooraf)
  geïnstalleerd worden.
* Andere oefeningen werken zonder die “library”.
* Of selenium (in het echt) gebruik wordt, is sterk afhankelijk van `PUT` (het product dat
  ontwikkeld/getest wordt)

* Voor “webapps” kan selenium gebruikt worden, of de browser aan te sturen; er zijn echter
  alternatieven


Hoeveel Python (kennis) is nodig?
=================================

* Ook de tester heeft (beperkt) kennis van Python nodig
* Elke ATS (de test) is geschreven in python. En wordt (meestal) geschreven door de tester
* Maar ATS’sen zijn kort een eenvoudig; ook voor niet programmeurs!
* Een ATS maakt gebruik van ‘bricks’; die zijn ook in Python geschreven; maar complexer en vaak
  door programmeurs gemaakt

Globaal zijn er 3 a 4  “lagen”, die een ander niveau van Python nodig hebben:

ATS:
        - Korte python scripts, die basis Python-vaardigheden  [PY1] vragen.
        - Vooral verstand van test(ontwerpen) is nodig
Bricks:
        - Iets complexer, soms complex. Meer (algemene) programmeerkennis nodig dan de meeste tester hebben.
        - Maar voor programmeurs met een beperkte Python opleiding goed te doen
Gate/config:
        - Meer Python & programmeer kennis nodig. Maar is slechts éénmalig nodig per PUT
        - Nauwelijks/geen kennis van testen nodig
Pathways/Framework:
        - Dit is de core; het ontwerpen & programmeurs hiervan vraag “veel” python en programmer
          kennis. Het meeste van deze 4 lagen.
        - Eigenlijk is dit is een “apart” project/product

In de workshop zijn de **testers** vooral bezig met de ATS-laag, en beperkt met de brick-laag.

Voor **programmeurs** ligt de nadruk op de bricks en gate/config lagen. Gezien het workshop gehalte
(en dus korte duur) is dat wel beperkt.


Waarom maakt ‘pathways’ testen (en product-ontwikkeling) efficiënter?
=====================================================================

Door het pathways-concept, kunnen de (alle) *testers* zich concentreren op het ontwerpen van de
test(en) ipv het uitvoeren. Bovendien kunnen ze dat lean (efficiënt) doen; omdat de nadruk op (met
name het ’schrijf’-deel) van traditionele tools/aanpakken minder is. Voor “eenvoudige” tests (ook
afhankelijk van test-ervaring) kan wellicht meteen de ATS geschreven worden. Voor lastigere zaken
is die traditionele kennis/aanpak natuurlijk nodig. Maar vaak is de documentatie (& tool) druk
minder.

Zo wordt is het ‘nooit (zeg nooit nooit) verplicht’ om MS-Visio (of soortgelijk) om een
stroom-diagram te tekenen. Vaak/soms is dat ‘waste’ en dus niet ‘lean’.

De flow ligt vast in de ATS; en dus kan die “flow” direct in het ATS “geprogrammeerd” worden.
|BR|
Al is een kladje als voorbereiding, soms wel handig. Dat kan op papier of whiteboard. Maar
uitwerken is niet nodig; het resultaat (de ATS) is (lees: moet!) duidelijk genoeg zijn.

Ook (vooral) het *programmeer*-deel van een project wordt efficiënter. Omdat de testen snel
(parallel; of soms eerder dan het ontwikkelwerk) beschikbaar zijn, heeft de programmeur een soort
van valnet. Door het veelvuldig uitvoeren van alle testen, weet hij snel of hij geen bestaande
features “kapot” gemaakt heeft. Maar ook in hoeverre de nieuwe features al werken. (STTD: Test
Driven Development, of Systeem niveau)