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


=============
Some concepts
=============

|logo-2-index|

.. rubric:: Why? & Concepts

* Why **Automatic Test Scripts**? Why a **framework**? Why the **Pathways**-framework?
* An overview of Pathways (bricks, TstVectors, ATS, ...)
* Pathways is for **testers**; but *programmers* can/must help
  :line-remark:`It’s a team effort`
* A bit of history

Automatic verification
======================

.. tip:: Testing is activity, an profession, but not a *goal in itself*.
..

  * We need a product *(a software programma)* that works, as we agreed. Or better: as we **aspect**.

  * Even when features are added, insights are changed and demands do change, it **should work**!

  --some customers

“Lean, Agile, Scrum”, effects on testing ...
--------------------------------------------

=====================================	==	============================================== 	=========================
Due iterative development 		➟ 	test-execution may become repetitious. 		*And so, very expensive*
As requirements do change 		➟ 	the test itself needs to be updated ‘a little’ 	*But quite often*
Programmers and testers sit in 1 team 	➟ 	they may/can/should help each-other! 			*This is an opportunity!*
=====================================	==	============================================== 	=========================

Benefits of Automatic Test Scripts
----------------------------------

.. sidebar:: The *new* tester

   A tester is not needed to detect flaws *afterwards*; (s)he is needed to **prevent failures** in the
   *first place*.

   So **thinking** about ‘sound’ test is essential; not the programming of an ATS.
   Typically, that is  less work then writing the same script in a Word-document.

* Cheap to execution.     	➟ Verification can be done **daily** 	➟ Signals when ‘*development is done*’
* Mostly shorter as ½ A4tje. 	➟ **Cheap** to write and maintain  	➟ Focus on ‘*good tests*’
* Store in **version controll** ➟ Expliciet, what is tested, when  	➟ No need for *lengthy documents*


ATS vs Python vs framework
==========================

A tester should focus on *designing* sound tests. Not on executing them, nor on programming them.

Each ATS should ‘read’ as a classical (manual) test-script
----------------------------------------------------------

#. First login
#. REPEAT

   #. Enter two numbers and the ‘plus’ symbol
   #. Read the result on the display
   #. Verify that value is the same a the pre-calculated one
      :line-remark:`Essential: not just a number, the expected one!`

#. *Log-off*
   :line-remark:`Only when all steps can be done (and ‘verify OK’), the test is OK`

Reuse ‘bricks’, focus on ‘domain’; hide technology
--------------------------------------------------

.. sidebar:: Requirements

   This kind of *lean*, *agile* and **‘KISS’** demands are used as requirements for Pathways.

   A framework that isn’t easy to use (by testers)


* To be able to make an :term:`ATS` that reads as above, a lot of “programming” en “technology”
  should be concealed (in the *framework*)
* As many steps contain details steps, that are needed *again-and-again*, those **“bricks”** should
  be reusable

Aside for ‘hiding’, the framework and the :term:`brick`\s also *centralize* details.
A change in the product (eg how to login) should not result in updating many ATS’sen. Only a
**one** (small) change, in the corresponding :term:`brick` (or a part of the framework) should be
needed!

Testers and developers
======================

:line-remark:`But feel free to use it elsewhere`
Pathways is primary meant for teams that *create working software*; so where ‘programmers’ and
‘testers’ work together. And it makes use of the skills of that team

Testers
--------

* All testers should be able to read/modify/understand the (python) test-scripts
* Most testers should be able to write *most of the* the (python) test-scripts
* Only some testers should be able to read/write some of the :term:`brick`\s; as this is more technical/complex

Programmers
-----------

* Typically, **do not** design/write the test-scripts; but can *assis* to code/program them
* Write/Modify those :term:`brick`\s the testers need
  :line-remark:`specially the test-API should be requested by testers!`
* Maintain the :term:`gate`, the (technical) interface between the framework and the product-under-test (:term:`PUT`)

Overview
========

.. image:: /img/exports/framework_concept.*
           :width: 40%
           :align: right

--- A global overview of the Pathways concept and parts

History
========