Meet Our Two Friends, IEEE 730-2002 and IEEE 829-2008 Standards
(photo by lusi)
Whenever we see numbers mixed with letters such as the title of this blog post we know that we’re up to something heavy.
Be prepared, because this time we’ll talk about the IEEE standards for the Software Quality Assurance Plan (SQAP) and Test Plan.
Standard? What is it?
I tried to look for a formal definition of “standards” for what we’re talking about here, but I couldn’t find one that I see fits. So here’s my own definition of standards, in particular for the IEEE standards:
Standards are documents formulated based on known industry best practices to serve as guidelines.
Since the real thing worth more than a thousand words, go take a look at them:
As you might have guessed, the 2002 and 2008 in the name refer to the version year of the standard, because every several years a standard can get updated.
So what do you think of them? Aren’t they the best piece of literature you ever read? (you know I’m joking right?)
If you enjoy reading them, then you are indeed… special. 🙂
So Should We Follow Them? I Can’t Even Barely Understand The First Few Pages!
Good news for us, standards are not really to be followed precisely by organization, they are guidelines.
If you can’t understand these standards on the first read, don’t worry, read them several times and they will make sense.
Now, let’s get to know them better, we’ll start with the shorter one, the IEEE 730.
The IEEE 730-2002
Our first new friend, the IEEE 730 is the standard that defines the Software Quality Assurance Plan (SQAP).
Just as a recap, quality assurance is a set of practices that removes defects prior to testing, techniques to assure that quality is “built-in”.
The following is the outline of SQAP defined by IEEE 730:
1. Purpose
2. Reference documents
3. Management
4. Documentation
5. Standards, practices, conventions, and metrics
6. Software reviews
7. Test
8. Problem reporting and corrective action
9. Tools, techniques, and methodologies
10. Media control
11. Supplier control
12. Records collection, maintenance, and retention
13. Training
14. Risk management
15. Glossary
16. SQAP change procedure and history
The list above, looks quite exhaustive already, is not everything yet. For example, there are sub-items in the number 4, 5, and 6. For a complete outline and template that you can use or download, check the following links:
http://www.scribd.com/doc/82437888/SQA-Plan-Template-1
If you manage to read the outline (I should congratulate you if you really did), you’ll notice that the bulk of the standard is on section 6, the software reviews section. Again, quality assurance doesn’t deal much about testing, but more on the reviews, this because quality assurance is a collection of defect prevention practices.
The IEEE 829-2008
Unlike IEEE 730, our IEEE 829 friend is a longer standard, it’s more than a 118 pages long. But don’t panic, it’s because the whole standard consists of documents for tests, and the one that we’ll particularly look at this time is the first one, the Test Plan.
The following is the outline of SQAP defined by IEEE 829:
1. Test plan identifier
2. Introduction
3. Test items
4. Features to be tested
5. Features to not to be tested
6. Approach
7. Item pass/fail criteria
8. Suspension criteria and resumption requirements
9. Test deliverables
10. Testing tasks
11. Environmental needs
12. Responsibilities
13. Staffing and training needs
14. Schedule
15. Risks and contingencies
16. Additional sections
17. Approvals
Yes, you might expect that there are more sub-items under these list, and you can check them on the following links:
This time, the major part of the document falls on the item 6, the test approach. Because in test plan document we focus on the quality control part of the project, and this is done primarily by testing.
Finally, the conclusion
Thanks to IEEE, these standards that we’ve just read are available so software development team can customize them as necessary and use them to make a great methodical description of SQAP and Test Plan.
Again, not all items may be need to be incorporated in every situation. But at least, aware of their existence, we can determine when it is appropriate to have them.
A little bit side note:
From my few years work experience in the real world, I can say that, impressively, organizations actually create some of these documents for their software projects. These documents are usually not written by programmers nor testers, they’re mostly written by analysts (business or system analysts).
As software grows and change, the documents also need to keep updated. The most common thing that can happen to these documents is they no longer synchronized with the actual software after the software is released, and the software entered into maintenance phase. The analysts probably have moved to different project or even left the company, and now the documents, as glorious as they were, are left unchanged, no longer reflect the existing system.
I guess what I want to say is, creating these documents is indeed a tremendous job, but to keep them updated is another challenge.