Testing Checklist

Are you going to start on a new project for testing? Dont forget to check this

Testing Checklist in each and every step of your Project life cycle. List is mostly

equivalent to Test plan, it will cover all quality assurance and testing standards.

Testing Checklist:

1 Create System and Acceptance Tests [ ]

2 Start Acceptance test Creation [ ]

3 Identify test team [ ]

4 Create Workplan [ ]

5 Create test Approach [ ]

6 Link Acceptance Criteria and Requirements to form the basis of

acceptance test [ ]

7 Use subset of system test cases to form requirements portion of

acceptance test [ ]

8 Create scripts for use by the customer to demonstrate that the system meets

requirements [ ]

9 Create test schedule. Include people and all other resources. [ ]

10 Conduct Acceptance Test [ ]

11 Start System Test Creation [ ]

12 Identify test team members [ ]

13 Create Workplan [ ]

14 Determine resource requirements [ ]

15 Identify productivity tools for testing [ ]

16 Determine data requirements [ ]

17 Reach agreement with data center [ ]

18 Create test Approach [ ]

19 Identify any facilities that are needed [ ]

20 Obtain and review existing test material [ ]

21 Create inventory of test items [ ]

22 Identify Design states, conditions, processes, and procedures [ ]

23 Determine the need for Code based (white box) testing. Identify conditions. [ ]

24 Identify all functional requirements [ ]

25 End inventory creation [ ]

26 Start test case creation [ ]

27 Create test cases based on inventory of test items [ ]

28 Identify logical groups of business function for new sysyem [ ]

29 Divide test cases into functional groups traced to test item inventory [ ] 1.30 Design

data sets to correspond to test cases [ ]

31 End test case creation [ ]

32 Review business functions, test cases, and data sets with users [ ]

33 Get signoff on test design from Project leader and QA [ ]

34 End Test Design [ ]

35 Begin test Preparation [ ]

36 Obtain test support resources [ ]

37 Outline expected results for each test case [ ]

38 Obtain test data. Validate and trace to test cases [ ]

39 Prepare detailed test scripts for each test case [ ]

40 Prepare & document environmental set up procedures. Include back up and

recovery plans [ ]

41 End Test Preparation phase [ ]

42 Conduct System Test [ ]

43 Execute test scripts [ ]

44 Compare actual result to expected [ ]

45 Document discrepancies and create problem report [ ]

46 Prepare maintenance phase input [ ]

47 Re-execute test group after problem repairs [ ]

48 Create final test report, include known bugs list [ ]

49 Obtain formal signoff [ ]

*************************************************************************************

How to test software requirements specification

(SRS)?

Do you know Most of the bugs in software are due to incomplete or inaccurate

functional requirements? The software code, doesnt matter how well its written, cant

do anything if there are ambiguities in requirements.

Its better to catch the requirement ambiguities and fix them in early development life cycle.

Cost of fixing the bug after completion of development or product release is too high. So

its important to have requirement analysis and catch these incorrect requirements before

design specifications and project implementation phases of SDLC.

How to measure functional software requirement specification (SRS) documents?

Well, we need to define some standard tests to measure the requirements. Once each

requirement is passed through these tests you can evaluate and freeze the functional

requirements.

Lets take an example. You are working on a web based application. Requirement is as

follows:

Web application should be able to serve the user queries as early as possible

How will you freeze the requirement in this case?

What will be your requirement satisfaction criteria? To get the answer, ask this question to

stakeholders: How much response time is ok for you?

If they say, we will accept the response if its within 2 seconds, then this is your

requirement measure. Freeze this requirement and carry the same procedure for next

requirement.

We just learned how to measure the requirements and freeze those in design,

implementation and testing phases.

Now lets take other example. I was working on a web based project. Client (stakeholders)

specified the project requirements for initial phase of the project development. My manager

circulated all the requirements in the team for review. When we started discussion on these

requirements, we were just shocked! Everyone was having his or her own conception about

the requirements. We found lot of ambiguities in the terms specified in requirement

documents, which later on sent to client for review/clarification.

Client used many ambiguous terms, which were having many different meanings, making it

difficult to analyze the exact meaning. The next version of the requirement doc from client

was clear enough to freeze for design phase.

From this example we learned Requirements should be clear and consistent

Next criteria for testing the requirements specification is Discover missing

requirements

Many times project designers dont get clear idea about specific modules and they simply

assume some requirements while design phase. Any requirement should not be based on

assumptions. Requirements should be complete, covering each and every aspect of the

system under development.

Specifications should state both type of requirements i.e. what system should do and what

should not.

Generally I use my own method to uncover the unspecified requirements. When I read

the software requirements specification document (SRS), I note down my own

understanding of the requirements that are specified, plus other requirements SRS

document should supposed to cover. This helps me to ask the questions about unspecified

requirements making it clearer.

For checking the requirements completeness, divide requirements in three sections, Must

implement requirements, requirements those are not specified but are assumed and third

type is imagination type of requirements. Check if all type of requirements are addressed

before software design phase.

************************************************************************************