Useful project's strategy documents - Test strategy

Useful strategy documents - part 3.

Next project's strategy document is test strategy. 

"It depends on" Have you ever heard it? Of course yes. The content of a test strategy document is one best example for this type of answer sentence. Why I am saying it? Think on it a little bit. You could be one of the best test manager, tester, testing software user, your are doing the best job during software testing and your project could'nt be a success story if your project hasn't got this informations well defined and approved(!) by the customer:

• Project scope
• Acceptance/goal criterias
• System requirements
• High level use cases
• Architectures (hardware/software or business/data/application/technology)

Why are they important for us? Because they are the elementary input information for a succesful testing. If you are lucky and your customer or your company already implemented one of the architecture frameworks (TOGAF, Zachman etc) and reached the planning step (for example in TOGAF the F. Migration Planning step) than they are already well documented and accesible before your implementation project started. If not it doesn't mean that they are not available, hopefully your project team already realized they necessarity and created them during the project's progress.

So first let's go through them, then I will try to mention a skeleten for the test strategy document.

Project scope

If your project scope well defined and accepted by all decision makers of your project, then you have got a good border for developing testing strategy. In this case probably you will not go in very big suprises, you won't forget to test any important part of the software. This border is good when you create the high level plan the necessary human, software resources, the schedule, the main scope etc.

If the project scope isn't well defined or not accepted by the decision maker then probably you could create very good test plans too, but it won't have a good and accepted base! In this case your test team could make the best, work day & night, engage all resources what project have, but the customer never will be satisfied, never accept the testing result, allways could ask more and more new functions - which should have tested too - so it could be a neverending story. So without a good project scope you could create a good testing strategy.

Acceptance/goal criterias

Elementary necessary information for testing strategy and all other test plan documents. If you didn't know how will the customer/key users accept the project's output, you couldn't prepare for, you couldn't create good test plans, test cases. If you didn't know how will the measurement happening, what they are measuring during the acceptance process, what key users viewpoints should be exactly satisfied then you will never know that you have already reached the goal or not.

So if these criterias already available and accepted by the key users then you should reflect them in the test strategy document too. You have to draw up how the testing steps will ensure that all acceptance and goal criterias will be satisfied, fulfilled.

System requirements

If you get enough time on project it's could be good for the quality of the test strategy document if you could wait for the design team to collect and define the main system requirements. Without them you could create the test strategy document, but these main requirement could be helpfully when you are planning the resources, the scheduling. You could focus on what functions, services will really necessary what will have just a marginal role. So you could concentrate all your test resources on the realy important tasks.

High level use cases

If you have waited for the main system requirements, probably you have time to wait for the high level use cases. Information coded into them could help to considering what and how many test cases will be necessary during the testing phases. What should do by the project developer team, what the test team and what will just do the key test users. If think on it, you could make a better plan for test resource management, you have a better chance to choose a much suitable test case handling/management solution or software.

Architectures

You could asked me? Architectures? Why and which one? Of cource I mean the TOGAF architectures on it. If your company or your customer already go through the ADM cycles and at least reached the 7th steps then your project will have all base and target architectures at all level, for all domain. You will get ready all requirements, schedules probably all well defined requirements against testing. (So you will know what and how should test, what will be the acceptance criterias, the key users already has an image, they are well trained, etc). Some times you will get from the companies or customers architecture team a skeleton document for the test strategy or they already created one for the project.

Skeleton of the document

From the above I hope you will understand why is to hard to exactly define a test strategy document. It's really depends on your actual situation, on the available input information, on the acceptance level of the project and so on and so on.

So what I think to had to contain a test strategy document is the belowed. It's not a big secret, but these are based on Oracle Unified Method Test Strategy documents. Of course with some modification.

1. Introduction
   As usual begin with the document control, introduction, dictionary other necessary pre chapter what your project or customer defined in their document template.
2. Define the testing principles
   If you define and get an approve for the testing principles, then you will get a very good base for all testing task, phases and of course for the whole test startegy document.
   Of course if your company's EA team already implemented all phase of an EA then you will get these principles from the EA documents.
3. Define the testing scope.
   This should be based on project scope and the requirements (if their are available). Define the task list (unit test, integration test, interface test, acceptance test etc.), the necessary test types within every test task (use cases, secirity, volume test etc.) and the planned interface list of the new system.
4. Now describe on high level all testing tasks that you have listed in the previous chapter.
   For example: Describe Unit testing; how will it implemented on the current project, which tools will be used, how will it support the testing principles.
   Define and create a high level process diagram to show how will these testing task create whole process, to show what step will follow the other one.
   I mention to approve this chapter before continue to develop the document or at least don't close the other chapters before the customer/ the project leaders not approve the scope chapter.
   By the way if your company already finished with F phase of TOGAF ADM, then it is easy to imagine that you will get all above chapter fully developed from the Enterprise Architecture team or from the domain architect who is responsible for implementation governance of your project.
5. Define all known constraints of the testing tasks. Collect all limits, time constraint, required system resources, business and techincal constraints.
6. Describe the acceptance criterias.
   If your customer or your project already developed this, you could copy paste it, if not this will be one of the hardest chapter to be developed. (mainly to get an acceptance from the customer for this chapter)
7. Describe what kind of test data will be necessary for a correct testing. Describe how it will be obtained and which test data will be necessary for which test enviroment, test task.
   In that case when your company already developed the TOGAF's data architecture then probably you could use the defined the base and the target data architectures as an input for this chapter.
8. Define and describe the testing enviroments
   Describe how many testing enviroment will be necessary, which envoriment will be used at which test phase, test task. Collect all information about the required platform, the server, the database, the application, versions of all softwares. Define a high level schedule for installation of the testing enviroments (when, which step has to be done to create enviroments for just in time)
9. Define and describe the testing tools
   If all above was developed now you have got all information in you hand to choose the best, the most adequate testing tools, which will be enough, support all test requirement and won't be to "big" for a succesful testing.
10. Describe the problem management, the risks and contigency plans.
    Create an extraction of your whole project's problem management, copy all information that needed for the testing. Nothing more.
11. Define and describe all critical success factors.
    Some example for factors:
1. Test script development must be based on system requirements and future business processes and business use cases.
2. Check that only valid and non-duplicated defects are processed.
3. Clear roles and responsibilities must be defined for the project in order to assure accountability, ownership, and quality.
12. Define and describe all testing metrics and measures
    Some ecample:
1. number of test iterations planned for each test task
2. percentage of completed unit and use case tests
3. batch nightly window response time
4. number of defects per test, period, iteration
5. etc.

So don't forget those above just a skeleten. If your company already has got a template for testing strategy use that. If not create it for yourself and send it to the project leader for an acceptence before develop all point of the document. (of course define which chapter will what contain, which should be accepted by the customer)

I hope it was helpful for your work, next post will speak about all remaining:

• going live procedure
• handover/takeover criterias
• acceptance/goal criterias