4. Verification Test Process (Static Testing)

In this section we will be looking at how Software Testing includes getting involved with the reviewing (verification) of documentation or code and providing feedback to ensure that quality is maintained from the very beginning, right to the very end of a SDLC (Project).

Table of contents

1.  What is Static Testing?
2.  Why do Static Tests?
3. What are we attempting to achieve by performing Static Testing?
4. Where do we do Static Testing?
5. How to perform the Static Tests
6. Summary
7. Test Yourself

1. What is Static Testing?

Whereas, Dynamic Testing tests the system while it is running (code is being executed), Static Testing involves reviewing work-products (the documents or code that have been produced in the whole of the Development Life Cycle). 

Once documents (e.g. Business Requirements, Functional Design, Integration Test, System Test etc) or the code has been produced, the static test (Document Reviews, Walkthroughs, Technical Reviews, Inspections etc) should be done as soon as possible to ensure their correctness.

back to table of contents

2. Why do Static Tests?

By reviewing each work-product (Requirements, Design, Code and even Test Plans) once it has been produced, then gaps in any of the documents and defects can be identified as early in the project as possible, therefore, saving both a lot of time and money!

It is a well known fact that it is much, much cheaper to fix defects (which includes errors in documentation) found earlier in the development life cycle, this is why it is important that all businesses should be performing this work!

Take a look at the following to see how much it costs for change to be made later in a project:

back to table of contents

3. What are we attempting to achieve by performing Static Testing?

By performing reviews, walkthroughs and inspections, we are trying to:

• Identify and correct errors (defects) or design gaps / mistakes in the Requirements document and Design documents
• Identify coding errors and code inefficiencies, usually done by a Developer’s peer  
• Identify errors or gaps in Test Plans, at a strategy, design and test case level
• Improve communication within the SDLC team, therefore, improving the understanding of what is being produced. As they say in IT…without communication…you’re dead in the water!
• And…ultimately, we are trying to save money! As stated above, the earlier we find defects / issues then the cost of development will be exponentially less!

back to table of contents

4. Where do we do Static Testing?

This type of testing can be applied to any work-product, but is mainly applied to:

• The Business Requirements Document
• Both Functional and Technical Designs
• The Code and Unit Tests
• Test Plans (Project Test Plan / Strategy, Integration, Functional and UAT Test Plans / Test Cases)
• Any guides (How to… etc)

back to table of contents

5. How to perform the Static Tests

Of all the companies I have worked at, there have only ever been 2 types of Static Testing processes, these being Reviews and Walkthroughs. You will come across other terms such as Technical Review, Inspection, Code Review etc. However, they are just reviews of either documents or code. Yes, the review can be more formal or a detailed (technical) review…but they are just reviews.

Reviews

• Usually done outside of a meeting
• The people on the SDLC Team (with the relevant skills to review the particular work-product) will be sent the document or code (or link to) to be reviewed. These reviews can be done in isolation or with other members of the team
• Checklists can be sent to reviewers with a list of what should be reviewed, how and what the objectives are for the review
• The reviewers will be looking for:
  • Defects
  • Gaps in the documents or code
  • New ideas to improve things
• Reviewers’ findings are returned to the Author / Coder
• This review process can be repeated until the document / code is then ready for release

Walkthroughs

• These are usually conducted as a meeting:
  • After the team has had a chance to review the work-product
  • With all the relevant SDLC members present
  • More formal than a review, with minutes being taken and perhaps with a checklist as to what is to be reviewed
• A walkthrough can be of a document or to demonstrate part of the newly coded system 
• Its function is the same as the Review Process, except that it is done in front of an audience, which can be very powerful when there is more than one set of eyes looking at it. It is still there to find defects, gaps or improvements

back to table of contents

6. Summary

In this section, you will have learned that :

So, what are we looking for from Reviews:

• You need to keep reviews as formal as possible. Do not let team members think of them as though they are just something they have to do to get a tick in the process box
  • Make sure objectives are set…and met!
  • Produce a checklist of objectives for each review as a priority
• That they are important…just as important as the Dynamic Testing we will be looking at in Section 5
• That it is very important to start the reviews as early as possible, this will save a lot of time and money! But more importantly…it will give the SDLC team a lot of confidence
• Allow enough time for reviewers to prepare and review
  • Follow up the review request as politely as you can if people are dragging their feet! 
• Management support. Without this, then reviews will be a struggle and they will lose their meaning
• There should be a clear emphasis within the SDLC Team that the Static Testing process is a no blame or shame culture…it is all about constructive criticism!

So, now we have looked at Static Testing, in the next section we will be looking at the real part of testing a system by executing it!

back to table of contents

7. Test Yourself

For this test, you will find that you only have 8 questions! The section was quite short, but I like to think it is concise enough to give you what you need!

Important to do well…

As with the other tests, once complete, check your answers, if you do not score that well (let’s say not getting at least 6 correct), please either go back over the tutorial’s section again, perhaps making more notes as you go, or re-do the test to ensure you have a good understanding. It is always important that you understand the section that you have read / learned before you move on 🙂 !

Click here to Test Yourself.

back to table of contents