Some time ago I wrote about the importance of using standards as a time saver. Since then I had a chance to apply this approach to several projects where I participated as a test expert.
So, below you can find a structure that helps to collect in one place all info you need to know about the state of test in a project. (I usually build a test plan as a single entry point for all the questions related to test by means of Atlassian Confluence, but I guess any other knowledge sharing system will do).
Also, I can guarantee that if you are able (have enough info, that is) to fill all the sections of my version of a test plan, then you do have your test process under control. So it can function as a checklist and and answer to a question where to start.
My version of a test plan consists of eight sections with subsections. Subsections may vary for each particular project, but I recommend sticking with the top-level ones.
IMPORTANT: Don't duplicate info, don't add info just to fill in sections, it is important that test plan is not just a formal piece of paper.
0. Goals and principles of the document
Very convenient section to unobtrusively state 2-3 most important things about the test plan and what it is for. Just make sure they are brief and catchy.
1. Test activities
1.1 Approach
Similar to what we said in goals, but the subject is somewhat narrowed down
1.2 Test Levels
Exactly what the name implies: for instance, integration test, e2e test, whatever test. You may ask if it makes sense to put scope here instead of having a separate subsection. The answer is sometimes is does, sometimes it doesn't, do whatever is best for your case in particular. Actually, once I just built a table out of all the subsections under Test Activites and it was really convenient
1.3 Test Aspects
Sometimes you need to add some additional classification to your test levels or to your tests in general. Here is a place where you can specify this info
1.4 Coverage & Code Quality
Some info about how you calculate coverage. If you do code quality measurements or you don't. Scope thing still applies
1.5 List of Activities
1.5.1 Exit/Entry Criteria
1.5.2 Item Pass/Fail Criteria
1.5.3 Suspension Criteria and Resumption Requirements
1.5.4 Scope
1.5.5 Phases and Lifecycles
1.5.6 Test Deliverables
1.5.7 Lifecycles
Simplest way to do this is to build a table listing all the activities you expect to cover (such as test design, test data design, test automation, code quality, environement management, technical debt etc) using subsection as columns (so you can explicitly point our what are entry/exit criteria for test execution are)
2. Test environment
2.1 Hardware/Software
2.2 Nodes by purpose or test levels
Section is good for keeping info as a knowledge base and making a formal statement at the same time
3. Test Tools
3.1 Technology Stack
3.2 Tools for Test Design
3.3 Tools for Test Execution and Analysis
3.4 Tools for Planning and Control
3.5 Tools Related to Environment Management
Tools in a broad sense. Whatever you use to do test and is not already classified as a separate section here. For instance, Tools for Test Design may contain ALM HP QC or Excel, or Java or appropriate Java libraries can be the tools of automation
4. Test Team
4.1 Team Structure vs Responsibilities
4.2 Matrix of Competence
4.3 Training Needs
Consider this section mandatory if you need to do estimations and to answer why something was not done on time. Matrix of Competence is extremely important
5. Communication
5.1 Communication routes
5.2 Documentation
5.3 Knowledge Sharing
5.4 Working with Stakeholders
Communication is the key. I'm seriously thinking of adding here a subsection on conflict analysis. If you do not understand what is meant by working with stakeholders, check out stakeholder management in PMBOK
6. Planning and Control
6.1 Planning, Control, Analysis and Reporting
6.2 Approaches
6.3 Schedules
6.4 Scope
Making whatever you do SMART. I have some favorite buzzwords that help me in my work, such as PDCA/Demming cycle, metrics, RAG status etc. This section is mainly to elaborate on them. Even if there is no 'manager' in your title, it makes sense to be able to plan and measure whatever you do
7. Risks Contingiecies Overheads
7.1 Risks Description
7.2 SWOT analysis
Once again, if you don't know what this is about, look up these things in PMBOK. I especially love SWOT analysis, SWOT is very good. You get a very clear view of your strength, weaknesses, opportunities and threats
8. Appendices
8.1 References
8.2 Glossary
Section for auxiliary materials, such as workflow diagrams etc
No comments:
Post a Comment