| 🏠 Back to Exam Syllabus | 📺 RooCloud on YouTube | 🌐 RooCloud Practice Exams |
CISSP 15.3 - Testing Your Software (Part 1 of 2)
This episode of the ISC2 Certified Information Systems Security Professional (CISSP) exam prep series opens the software testing topic from Domain 6, exploring how to catch flaws in code before it ever ships. As the first of two parts, it looks at why software earns such careful scrutiny and the practices that stand between a developer’s shortcut and a production incident, from peer review to testing code both at rest and while it runs.
What this episode covers
- Why software deserves testing — powerful, privileged code that must expect the unexpected through exception handling.
- Code review — a second set of trained eyes that clears code or sends it back with fixes.
- Formal inspection — the six-stage, strict-criteria review reserved for code where a flaw could be catastrophic.
- Static testing — checking source or compiled code without running it to catch flaws like memory overflows early.
- Dynamic testing — evaluating an application while it runs, using synthetic transactions with known expected results.
- Benchmarks and extra tools — baselines for performance, plus interactive testing and runtime self-protection.
- Ethical disclosure — telling a vendor privately first, then going public if a real flaw is never fixed.
Watch the full episode above for the worked examples and detailed explanations of each concept.
Frequently Asked Questions
Why does software deserve such careful testing?
Because it holds enormous power over everything else. Applications often run with privileged access, handle sensitive data, and lean on databases full of secrets, so when they fail the business can grind to a halt. There is a core design principle here: software should never assume users behave well. It should expect the unexpected and handle bad input gracefully, a discipline called exception handling.
How does peer review harden your code?
By putting a second set of trained eyes on it before it ships. In a code review, developers other than the author examine the work for defects, and the review either clears the code for production or sends it back with fixes. The most rigorous version, a formal inspection, follows six defined stages from planning through follow-up, each with strict entry and exit criteria, so reserve that heavy ceremony for code where a flaw could be catastrophic.
What is the difference between static and dynamic testing?
Static testing checks software without ever running it, inspecting the source code or the compiled application with automated tools that hunt for common flaws like memory overflows, so it can run early and often inside development. Dynamic testing is the opposite, checking software while it runs in a live runtime environment, which is often your only option for code you did not write yourself.
What extra testing tools sit alongside static and dynamic testing?
Two round out the picture. Interactive testing analyzes an application’s behavior in real time as it runs, watching its traffic, its components, and its back-end connections all at once. Self-protection is different, running right on the server and intercepting the calls flowing into and out of the application, validating those requests as they happen. One watches to learn, the other steps in to defend.
What do you owe a vendor when you find their flaw?
A responsible, private heads-up before the world hears about it. Ethical disclosure says you tell that vendor first, giving them a fair chance to build a fix and a reasonable amount of time to act. If they never do, you may responsibly go public so other professionals can protect themselves. It is the courtesy of knocking before you shout, balanced against the duty to warn everyone else.
📚 Master the ISC2 CISSP Exam!
Ready to test your knowledge? Access chapter-specific Multiple Choice Questions (MCQs) and full-length practice exams for the ISC2 CISSP certification at RooCloud.com. Solve the chapter-wise questions to reinforce this lesson before moving to the next episode.
Reference: This article is based on concepts discussed in CISSP 15.3 - Testing Your Software (Part 1 of 2).