Subscribe by Email


Showing posts with label Work flow. Show all posts
Showing posts with label Work flow. Show all posts

Thursday, April 26, 2012

Explain Test plan, Test Strategy and Test Scenario?


The concept of software testing seems like an amalgam of similar terms, all mixed up in to each other. We all get confused sometimes between the different but similar sounding terms. 

For greater understanding of the software testing, one needs to know exactly what all the inclusive terms mean and how and where they are used or implemented. This piece of writing is dedicated to the cause of removal of such confusions. In this article we are going to clear three major concepts of software testing namely test plan, test strategy and test scenarios.

1. Test Plan

- It does the same as a normal plan would do i.e., detail out a systematic approach to the accomplishment of a certain task.
- For the test plan the task is the successful completion of a particular software testing. 
- A test plan gives a detailed approach of all the processes or activities to be undertaken during the testing.
- A test plan marks the work flow of the software testing mechanism. 
- A test plan states the strategy to be followed to make the software testing successful.
- It provides a means to check whether or not the software system or application meets all the requirements and specifications as mentioned by the client or the customer in the documentation. 
- The test plan is usually created by the testers.
- A typical test plan includes the following fields:
      (a)  Compliance test or design verification: performed on the product samples while the actual product is in development stage.
   (b)  Production test or manufacturing: performed during the assemblage process of the product for assuring quality and performance.       
      (c)  Commissioning test or acceptance: performed while the product is being installed.
      (d)  Repair test or servicing: performed during the product’s service life.
      (e)   Regression test: performed on an existing version of the product to ensure the working of the functionalities.
               
- The level of the design of the test plan depends on the complexity level of the software system or application. 
- For more complex systems high level test plans are created. 
- Apart from the above mentioned tests, a typical test plan must cover about the test methodologies, test coverage and test responsibilities. - It also states what all requirements are to be verified in the testing.

2. Test Strategy

- Test strategy forms an essential part of the test plan. 
- To put it simply we can say that the test strategy is nothing but a superficial sketch or outline of the actual test plan of the software development cycle. 
- A test strategy is developed just to inform the project developers about the approach that is to be followed during the testing. 
- The key components of a typical test strategy are objectives of the testing, test methods, test duration, resource requirements and test environment. 
- Test strategies give the description of the risk mitigation, tests to be carried out and not to forget the entry and exit criteria for the tests. 
- For each level of software testing, an individual test strategy is created.

3. Test Scenario

- Test scenarios form an essential component of the scenario testing. 
- These test scenarios provide a hypothetical measure to help the tester out of some complex problem encountered during the testing. 
The main characteristics of a typical scenario are its complexity, credibility, motivational story with a reasonable outcome. 
- The scenarios are usually lengthy as compared to the length of the test cases probably because of more number of steps are present in a test scenario. 2 or more scenarios together make up a scenario file. 


Monday, February 14, 2011

Interface Analysis - Task Analysis and Modeling

The goals of task analysis :

- what work will the user perform in specific circumstances?
The use case is developed to show how an end-user performs some specific work related task. The use case provides a basic description of one important task for the computer aided design systems. The software engineer extracts tasks, objects and overall flow of interaction.

- what tasks and sub tasks will be performed as the user does the work?
It is a mechanism for refining the tasks that are required for the software to accomplish some desired function. Task elaboration is quite useful, but it can also be dangerous. A human engineer must first define and classify tasks.One approach is stepwise elaboration. Each of these major tasks can be elaborated into subtasks. Design model should accommodate each of the task in a way that is consistent with user model and system perception.

- what specific problem domain objects will the user manipulate as work is performed?
The objects that are extracted from the information obtained from the user can be categorized into classes. Attributes of each class are defined, and an evaluation of the actions applied to each object gives a list of operations to designer. Although object elaboration is useful, it should not be used as a standalone approach.

- what is the sequence of work tasks-the workflow?
Workflow analysis allows a software engineer to understand how a work process is completed when several people and roles are involved. Work flow analysis is applied when a number of users, each playing different roles, makes use of a user interface, it is sometimes necessary to go beyond task analysis and object elaboration.

- what is the hierarchy of tasks?
Process of elaboration occurs once the interface is analyzed. Once workflow has been established, a task hierarchy can be defined for each user type. Hierarchy is derived by a stepwise elaboration of each task identified for the user.


Facebook activity