Some concepts

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 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

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

1. First login

2. REPEAT

   1. Enter two numbers and the ‘plus’ symbol

   2. Read the result on the display

   3. Verify that value is the same a the pre-calculated one Essential: not just a number, the expected one!

3. Log-off Only when all steps can be done (and ‘verify OK’), the test is OK

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

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 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 bricks 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 brick (or a part of the framework) should be needed!

Testers and developers

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 bricks; 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 bricks the testers need specially the test-API should be requested by testers!

• Maintain the gate, the (technical) interface between the framework and the product-under-test (PUT)

Overview

— A global overview of the Pathways concept and parts

History