Testing Software Complexity

Written By Dave Tavares

The McCabe Cyclomatic Complexity metric and control flow graphs are essential in determining the minimum tests required to cover logic combinations in code. These graphs provide a visual representation of the code's logical structure.

Test plans are broken down into test cases, each needing an expected result for validation during the test suite's execution. In unit testing, modules, which can be functions, routines, or files, are defined. White box testing involves directly testing code constructs, with different levels of testing complexity ranging from statement (weakest) to Multiple Condition Decision Coverage (MC/DC; most comprehensive testing).

Basis Path Testing, driven by McCabe Flow Graphs, identifies the minimum white box tests needed to cover logic. Each test case uniquely exercises a basis path, ensuring comprehensive test coverage. A 100% unit test coverage of basis paths ensures fail-safe code within the module.

Integration testing focuses on inter-module communication, uncovering issues, and potential dead code segments. Dead code arises when certain code segments are not executed, often due to duplication of logic tests. A 75% integration test coverage of basis paths guarantees fail-safe code across modules.

In summary, basis path tests ensure all statement tests are executed, highlighting the importance of thorough logic testing in software development.

Please refer to the attached PDF document for further details and a better-formatted document. Feel free to contact me via comments or email for any additional information.

If you would like to discuss in depth, please reach out.

Dave Tavares

Initially, I was a software developer for the Department of Defense (DoD) through defense contractors. I understood that the software could not fail because lives depended on it (extreme safety concerns). I quickly took steps to ensure that my software was highly reliable and easy to maintain.

Due to the quality of my software deliveries, I was promoted to software engineering leadership.

By request, I was responsible for leading a Quality Engineering (QE) team where the team was not meeting client expectations for a highly critical solution requiring the removal of as many bugs as possible before going live with accuracy and extreme stability (i.e., air traffic control). I had a leadership and hands-on role. Safety was paramount. We succeeded due to Cyclomatic Complexity path test coverage > 85%. I tracked the first ten years of this solution required for range control, and the software never failed and always worked as expected.

I then moved into high-tech industry testing (broadcast, health care, smart grid, IoT, semiconductor software design/software test tools, and autonomous driving, to mention a few).

During my QA/QE phase, my software quality engineering responsibilities at the contributor level included manual, automated, and comprehensive testing. I brought innovative practices to match the SDLC, CMM, and ISO 9001 target goals at the Quality Engineering Lead and Director levels, satisfying their customer base. I was responsible for setting processes, procedures, templates, and checklists for all phases and types of testing. Quality was improved, resulting in a maximum of 90% reduction in customer bugs. I was also a lead assessor for CMM and ISO 9001 during this time.

In my most recent role as the Staff Technical Program Manager, I moved into engineering hands-on training, driving engineering standards compliance and assisting engineers with compliant artifacts. I translated standards into system/software/firmware engineering processes, practices, and templates. Standards included ASPICE, ASIL, and applicable portions of ISO 26262

Finally, I have worked with agile, highly iterative, and waterfall models and assisted teams in migrating between different models.

Previous

Requirements Engineering