Specifying Test Procedures or scripts

-

After the test case creation the next step is to group the test cases in a sensible way for executing them and to specify the sequential steps that need to be done to run the test.
  • a set of simple tests that cover the breadth of the system may form a regression suite, or all of the tests that explore the working of a given functionality or feature in depth may be grouped to be run together.

Some test cases may need to be run in a particular sequence. 
  •  a test may create a new customer record, amend that newly created record and then delete it. These tests need to be run in the correct order, or they won't test what they are meant to test.

The document that describes the steps to be taken in running a set of tests (and specifies the executable order of the tests) is called a test procedure is often referred to as a test script. 

It could be called a manual test script for tests that are intended to be run manually rather than using a test execution tool. Test script is also used to describe the instructions to a test execution tool. 

An automation script is written in a programming language that the tool can interpret. The test procedures, or test scripts, are then formed into a test execution schedule that specifies which procedures are to be run first - a kind of super-script.

The test schedule would say when a given script should be run and by whom. The schedule could vary depending on newly perceived risks affecting the priority of a script that addresses that risk, for example.
The logical and technical dependencies between the scripts would also be taken into account when scheduling the scripts. For example, a regression script may always be the first to be run when a new release of the software arrives, as a smoke test or sanity check.

Returning to our example of the mobile phone company's marketing campaign, we may have some tests to set up customers of different types on the database. It may be sensible to run all of the setup for a group of tests first. 

Writing the test procedure is another opportunity to prioritize the tests, to ensure that the best testing is done in the time available. A good rule of thumb is 'Find the scary stuff first'. However the definition of what is 'scary' depends on the business, system or project.


Comments

Post a Comment

Popular posts from this blog

Types of Review

-
A single document may be the subject of more than one review. If more than one type of review is used, the  order may vary.  It is  apparent that none of the following types of review is the 'winner', but the different types serve different purposes at different stages in the life cycle of a document. The main review types:  Walkthrough Technical Review Inspection Walkthrough A walkthrough is characterized by the author of the document under review guiding the participants through  the document and his or her thought processes , to achieve a common understanding and to gather feedback. This is especially useful if people from outside the software discipline are present, who are not used to, or  cannot easily understand software development documents.  The content of the document is explained step by  step by the author, to reach consensus on changes or to gather information.  Within a walkthrough the author does most of the preparation. The participa
Read more

Phases of Formal Review

-
Phases of a formal review In contrast to informal reviews, formal reviews follow a formal process.  A typical formal review process consists of six main steps: Planning Kick-off Preparation Review meeting Rework Follow-up Planning The review process for a particular review  begins with a 'request for review'   by the author to the moderator (or inspection leader).  A moderator is often assigned to take care of the scheduling (dates, time, place and invitation) of the review. On a project level, the project planning needs to allow time for review and rework activities , thus providing engineers with time to thoroughly participate in reviews. For more formal reviews ,e.g. inspections, the moderator always performs an entry check and defines at this stage formal exit criteria. The entry check is carried out to ensure that the reviewers' time is not wasted on a document that is not ready for review.  A document containing too
Read more

Structure Based or Whitebox Testing Techniques

-
Image
Using structure-based techniques to measure coverage and design tests Structure-based techniques serve two purposes:  test coverage measurement structural test case  design.  They are often used first to assess the amount of testing performed by tests derived from  specification-based techniques, i.e. to assess coverage. They are then used to design additional tests with  the aim of increasing the test coverage. Structure-based test design techniques are a good way of generating additional test cases that are  different from existing tests. They can help ensure more breadth of testing, in the sense that test cases  that achieve 100% coverage in any measure will be exercising all parts of the software from the point of  view of the items being covered. What is test coverage? Test coverage measures in some specific way the amount of testing performed by a set of tests . Wherever we can  count things and can tell whether or not each of those things has been tested b
Read more