Qualification Testing Hierachy
Start course

This course covers the first section of CSSLP Domain 6 and looks at the topic of software acceptance.

Learning Objectives

Obtain an understanding of the following topics:

  • Software qualification testing
  • Qualification testing plan
  • Qualification testing hierarchy

Intended Audience

This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.


Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.


Then we move on to the testing hierarchy. We have unit testing, and this aims to verify that each part of the software is working properly by isolating it and then performing tests on it to demonstrate that each individual component is correct in terms of fulfilling requirements and the desired functionality. Then we move on to another level of complexity, the integration testing, and this aims to test different parts of the systems in combination in order to assess that they work correctly together. By testing the units in groups, any faults in the way that they interact together can be identified and thus be corrected.

The next level of complexity is system-level testing. And this, of course, enables testers to ensure that the product meets business requirements as well as to determine that it runs smoothly within its operating environment. Our final level of complexity and the one just before the software is going to be released is acceptance testing. Now, the aim of this type of testing is to evaluate whether the system complies with the end-user requirements and if it is ready for deployment. Now, this would seem to be a bit obvious and to have been satisfied when it comes to system testing. But system testing, the level before final acceptance testing, is not not always done in the presence or at the behest of a customer. And so this one is the final, so to speak, showpiece to get the customer's involvement.

Now, one quick clarification. This should not be the first time that the customer has seen the software that is about to be delivered to them. They should have been involved on all significant occasions, every bit along the way as the software was being developed. This is just the final look before the release of how the whole thing looks and operates when it's been brought together. Now, the scope of the acceptance test should range from simply finding spelling mistakes and cosmetic errors to uncovering bugs that could cause a major error in the application. And this is because finally, everything has been brought together. And the next step, if we assume that everything goes perfectly, will be to productionalize the software. And here is where we get the final round of customer feedback before that happens.

Now, the question of assurance is one of major importance because it examines the concerns and the extent to which the design and functional specifications have been met. It also supports the process for the careful examination of the requirement's origination and the traceability matrices, including all change history. Over the course of the development project, it is undoubtedly so that the project will have changed many different times in many different ways. And we have to be able to backtrace everything so that we know where the origination was of any specific requirement or any specific change to make sure that what has been delivered is what was originally conceived, or that if it has been altered or adapted in any way, that we can trace it back to its origin. Again, the goal is to make sure that it still meets all customer requirements.

About the Author
Learning Paths

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.


Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.

Covered Topics