About Chris Schotanus
Chris is a senior management consultant on test policy and strategy, test organisations, structured testing, test management, automated test execution and test process improvement. He has 40 years of IT experience, over 25 years of which on testing. Chris advises on testing in agile/iterative environments, IT governance, requirements management, IT process improvement.
Testing in a Service Based Environment, Staged Acceptance
Testing in a services based IT environment demands for a different approach to testing and acceptance. Although, from an end user focus, the system runs as one monolithic thing, the system actually consist of a number of individual operating, exchangeable services. All these services have a (business) owner who defines the specifications of these services. And one service may potentially be uses by many other services. When one of the services is amended (eg. because of the need of one of the users), the changes may impact the other users. This may lead to a lot of testing by all services that are connected to the changed service. The tester will have to find out which services should be tested and to what extent.
In this presentation I will elaborate on:
– The need for “Generic Test Agreements”
The presentation is based on theoretical knowledge and real life experience
Acceptance of Individual (micro)services
Ownership and Responsibility of Services
Optimization of the Test Process
Specification by Example: from User Requirements to Test Cases
Specification by Example (SbE) is not primarily about testing. It is a technique that supports clarification of user requirements and, at the same time, leads to test cases that can be used to verify and validate the product. Specification by Example, is a relatively easy yet powerful approach to (agile) software development. It supports the process in many ways and during various phases of software delivery: requirements elicitation, functional design, test design, test execution and acceptance.Because of the joint effort during refinement, it becomes quite clear what the business requirements areand how these requirements should be implemented. There is no misunderstanding regarding the acceptance criteria. SbE reduces the effort needed for acceptance testing by the business since the team can execute the majority of the acceptance tests. Duringthe actual software development, it becomes possible to continuously determine the quality of the system (both technically and functionally), which enables a continuous integration and delivery process. The result of this approach is an improved design, shorter test process and fewer failures (either design or code) in the production environment. This is when iterative waterfall development really becomes agile.