Automated Testplans in High Tech Environment (English version)

Published 7 december 2016 | English version | By Gerben de la Rambelje
Author: Eric Spaargaren  ● erics70@kpnmail.nl

Writing test plans, a new development?

The last few years we used to write test plans according to a certain format in which Tmap and ISTQB mainly was used as standard. Currently test plans are written in a document with a nicely conduced format. But it seems like there will be a change into writing test plans in a more innovative way. At the  moment parts of a test plan are for example:

·         Introduction and test approach

·         In scope and out of scope

·         Test techniques

·         System tests

·         Automated tests and test tools

·         Layout test cases and test execution

A test plan can be written with different purposes. For example for the internal customers or the external customer. This makes a big difference. When writing a test plan for the internal customers only a few reviews of the document are needed. Because the test plan will be used  by the internal staff of a certain department. But when you write a test plan for external usage or for customer clients things will be very different. The customer will read this document so they will be much more critical. More review rounds will be needed and more changes and more perseverance will be needed. When an external test plan will be published the test plan must be written very precisely.

A few differences between writing an internal test plan and an external test plan:

Internal usage:

·         Ready within 2 or 3 weeks.

·         Three review rounds

·         The employees are the target audience.

·         The test plan will be used as working material.

External usage:

·         Within two or three months a document in concept

·         Many review rounds could be needed.

·         The updates of the layout of the document could change a lot during writing.

·         The document shouldn’t have any mistakes or errors, the document must be an error-free document.

The test plans are currently mostly written on a hands-on way but there will be a change into that subject. The new innovation is that new technologies will be used to write test plans in a more automated script according towards the ‘CamelCase’ structure. Camel Case is a notation way to manage and to have a test case more readable and it could be handy to use this notation way for setting up a program script within the automated test tool. There are two variants of Camel Case:

1.     Upper Camel Case (example notation way: Processing Check Trail)

2.     Lower Camel Case (example notation way: processing Check Trail)

The development of automated test plans.

As I wrote previously there are two ways of writing a test plan. In the format of a document or with the usage of an automated test tool. The latest example has been a new development since 2016. The standard model of a test plan will not disappear but this format will be useless in the future because organisations want to work in a faster way. The advantage of the usage of automated test tools is that the script can be used directly to program automated tests for the developers. The developers can use these automated scripts written in the right format directly to program software. Normally the activities of writing a test plan consists of test elements like test scope, test strategy, test purposes, test organization and finding management. Currently the logical test scripts are much more essential. The working activities of a senior tester seems to be subdued to change. In previous times  a senior tester was involved in writing the test plan, test script and test execution. The tester uses the test scripts to execute the tests with the software patch, which has been delivered. The new development is that the testers will work in a more virtual test environment with the usage of test tooling. These test tools will be used for writing test plans and test specifications with the usage of delivered strategic functional business requirements.

The test developers will build test scripts for the usage of test execution. Hereby it is essential that the automated test scripts will be checked on correctness. The development of the automated tests will be done by the test developers. The test designers will be less connected with the real software which will be delivered by the developers. This seems to be a dangerous development of the “test designer’, which will design the test scripts on a logical level. Terms like “Tampered software” will be applicable here because the test designer has no grip on the software anymore which has been planned to be developed. The test designer is much more active with the design of the test plan and/or specifications than with the validation of the delivered software. The test plan will be written based on the delivered functional requirement.

The shifts of working activities.

During previous activities of the senior tester like writing test specifications, he was also busy with testing the developed software. Currently the test assignments are changing and senior testers are  working more in a virtual test environment where the test design will take place. The senior tester will get more requirements from the clients within the company based on a strategic and tactical level. Therefore it seems that the tester will do more types of activities as a business analyst. In the mean time the input information for the mind-set of the tester will be more important. Searching for more information to create test scripts is even more physical concerning the first deployment will be an important challenge to work out  because documentation or information could be a lack in an organisation. The senior tester is currently working in a high-tech environment and can build a bridge between business and IT.

When test scenarios are written in a layout as a test plan they will be delivered to the software developers (also testers). These test scenario’s will be converted in automated test scripts. Finally the senior tester is in the completion phase and the maintenance phase concerning the test design and it could be possible that a new review will be done with new comments and or improvements. The test designer will develop automated test scripts and has even more questions for the senior tester. The test developer gives the senior tester a ‘link’, with which he or she can read the automated test scripts in a other test environment. The results of the test execution can be read in this specific test environment as well.

Scrum/Agile

When there is work to be done with the Scrum/Agile methodology a test plan is not really required anymore. This could be a way of thinking. But even with writing automated test plans this should be the case in a Scrum/Agile environment. Because when writing an automated test plan in an automated test environment an iteration within the working process could be very handy. And an automated test plan could also be very handy during some delivery moments of testing software.

Validation of the test plan.

Writing a test plan will take some time because a test plan is some kind of book with information  in which review rounds were needed. When writing a test plan changes are necessary because of the text, the contents of the document etc, etc. Review is validation. At the end of the review process the test plan will be ready for internal usage. It can be read by the employees of the company or by the customers of the company. Writing a document or a test plan could take even one full year. Writing an automated test plan in a virtual environment and/or repository in which other people can login are new developments. Meanwhile validation can be done via one type of methodology and will progress in a faster way.

The developments for the test profession till 2020 and further.

·         The senior tester will work in a high-tech test environment.

·         The senior tester is:

o    a test designer

o    a software developer designing automated test scripts.

·         Work will be done via the standard of the test design tool.

·         The development of automated test scripts will be executed by software developers (testers).

·         The senior tester has less grip on the delivered software.

·         The software developer (tester) has more grip on the delivered software.

·         To write a test plan as work process will stay but the innovation will continue by writing test plans in an automated high-tech test environment.