Testing and Documentation
Testing and Documentation

This course covers section one of CSSLP Domain Five and looks at security quality assurance testing. You'll learn about important and foundational concepts on the process and execution of testing, topics regarding quality and product integrity, and various other considerations.

Learning Objectives

Obtain a solid understanding of the following topics:

  • Security testing use cases
  • Software quality assurance standards
  • Testing methodologies and documentation
  • Problem management
  • The impact of environmental factors on security

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.


We are going to need to produce documentation about the efforts that we're undertaking in our testing process. Because what we document, how we perform it and the results that we get, are of very great importance to our future efforts. So, we document what has been tested, what was found or what was not found, what the cause and effect of all the different things that we've tried were, and how, if it was, fixed.

Now, relative bug priorities are like anything else we encounter in a process like this. Not everything will have the same priority, and we can only have one 'number one' priority. But once we establish these, we also need to establish what action was taken with respect to the type of priority or the level of the priority. Obviously, we have to have levels because we need to have things put in an order, most important first, most damaging first, working our way down to least.

We're going to have to have contingencies or fallbacks to ensure that we have different routes to get to the solution, whatever that might be. And these need to be described because there will not be just one way to fix something. And we need to describe what those ways are and why we chose the one we did. Each scenario thus must be memorialized in our documentation to facilitate the necessary CMMI-type process improvement. It means, of course, we're going to have to have careful version control throughout, so that we can ensure that whatever was found and fixed, is not, at some future point, returned to a live state, and thus, once again becomes a problem.

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.