S2L3 - Code Review and Security Testing (Review Types and Process (Online…
S2L3 - Code Review and Security Testing
Developers other than one who wrote it, review code for defects.
May be approved to production or sent back to original dev for rework of issues found
Bug, Fault, Problem, Issue
Requirement not satisfied
S/W incomplete, incorrect, missing
Review Types and Process
Monitor Quality level during development process
It is performed after completion of software or milestone
Semi Inspection Process
Performed when one of more components of software completed
Used to improve quality of SW and improve learning curve of junior developer. Sit with code writer to find defects
Formal Inspection Process
Schedules meetings, prepared participants, defined agenda, results into a documented output
Meetings over coffee, regular team meetings
Inspection of any document that is deemed complete and ready for use
Plan Inspection by Moderator
Overview, communicate, educate and circulate info about the software
Preparation, all participants perform individually review materials to detect defects
Inspection, paraphrases design, identify and note problems without solving
Rework, all errors/problems addresses
Follow-up, moderator ensures all errors have been corrected. If more than 5% rework, re-inspected by same team
Planning -> Overview -> Preparation -> Inspection -> Rework -> Follow Up
Involved early in documentation and development and throughout SDLC
Well documented track record in reduction in rework costs and defects
Plays major role in training junior staff and transferring expertise
Why rarely used?
Disappointment & frustration
Benefits are intangible
Test Coverage Analysis
Unfortunately impossible to completely test any piece of software. Too many ways app may fail.
Test Coverage Analysis estimates degree of testing conducted against new sw.
Number of test done/total number of use case
Highly subjective calculation. Accurately needs identifying all possible use cases which is difficult
Misuse Case Testing
Attempt to exploit known vulnerability use cases with manual and/or automated attack techniques
Examination & evaluation of sw security and related documentation w/o executing software
Use automated tools to detect sw common flaws
Involved interaction & evaluation of sw security while it runs.
Dynamic testing on production environment should be careful to avoid unintended interruption of service.
use of SYNTHETIC TRANSACTIONS to verify system performance. Scripted transactions with known results
Automated sw testing technique that involves providing invalid, unexpected or random data as inputs to limits and detect flaws.
Modules developed seperately. Handoffs between these use well defined interfaces so that team work independenty
Assess performance of module against interface specs to ensure they work properly when all dev efforts are complete
Types of Interfaces
Exist in some app that manipulate machinery, logic controllers, objects physical world
Pay attention to consequences if failure
UI (User Interface)
such as GUI and CLI provide interaction
Interface tests should include reviews of UI to verify function properly
API (App Programming Interface)
offer standardised way for modules to interact and may be exposed outside through web services.
Test to ensure enforce security requirements.