Complete RGPV exam-oriented notes on coding standards, programming practices, code review, verification and validation, testing principles, test levels, white-box and black-box techniques, regression testing, debugging and test documentation.
Coding is the process of converting a software design into executable source code using a programming language.
Objectives
Implement the approved software design correctly.
Produce readable, efficient and maintainable code.
Follow coding standards and security practices.
Make code easy to test and modify.
Reduce defects through reviews and static analysis.
Software Design
|
v
Select Language and Tools
|
v
Write Source Code
|
v
Code Review
|
v
Unit Testing
|
v
Integration
Major Coding Activities
Module implementation
Data structure and algorithm selection
Input validation and error handling
Code documentation
Code review and static analysis
Unit testing
Version control
2. Coding Standards and Guidelines 14 Marks
Coding standards are agreed rules for writing, formatting, documenting and organizing source code.
Important Standards
Use meaningful identifiers.
Follow consistent indentation and formatting.
Keep functions short and focused.
Avoid global variables where possible.
Use constants instead of unexplained literal values.
Validate all external inputs.
Handle errors explicitly.
Remove dead and duplicate code.
Follow secure coding practices.
Write useful comments for intent and complex logic.
Benefits
Improves readability and maintainability.
Simplifies team collaboration.
Reduces defects.
Makes reviews faster.
Supports automated quality tools.
Bad practice: Very long methods, meaningless names, repeated code, hidden side effects and empty exception handling.
3. Good Programming Practices 7 Marks
Use structured and modular programming.
Apply high cohesion and low coupling.
Prefer simple algorithms and clear control flow.
Check boundary and exceptional conditions.
Use reusable functions and components.
Apply defensive programming.
Write testable code.
Use source control with meaningful commits.
Refactor code regularly without changing behavior.
Measure performance before optimization.
Defensive Programming
Defensive programming anticipates incorrect inputs, invalid states and unexpected failures, and handles them safely.
4. Code Documentation 7 Marks
Internal Documentation
Meaningful names
Comments
Function headers
Assertions
Clear code structure
External Documentation
API documentation
Installation guide
Developer guide
Configuration guide
Release notes
Comments should explain why a decision was made. The code itself should clearly show what it does.
5. Code Review and Software Inspection 14 Marks
Code review is the systematic examination of source code to identify defects, improve quality and ensure compliance with standards.
Types
Informal review: Quick peer examination.
Walkthrough: Author explains the code to reviewers.
Technical review: Qualified team evaluates technical correctness.
Formal inspection: Structured review with roles, checklists and recorded defects.
Tool-assisted review: Static analysis and automated checks.
Formal Inspection Process
Planning
|
v
Overview
|
v
Individual Preparation
|
v
Inspection Meeting
|
v
Rework
|
v
Follow-up
Advantages
Finds defects before testing.
Reduces correction cost.
Improves coding consistency.
Transfers knowledge among team members.
Improves security and maintainability.
6. Verification and Validation 14 Marks
Verification
Verification checks whether the software is being built correctly according to specifications and design.
Question: Are we building the product right?
Validation
Validation checks whether the completed software satisfies actual user needs and intended use.
Question: Are we building the right product?
Basis
Verification
Validation
Focus
Correctness against specification
Fitness for user needs
Common methods
Reviews, inspections, static analysis
Execution and dynamic testing
Code execution
Not always required
Usually required
Performed during
All development phases
Testing and acceptance stages
7. Software Testing 14 Marks
Software testing is the process of executing and evaluating software to discover defects and determine whether it satisfies specified requirements.
Objectives
Detect defects.
Verify requirements.
Validate user expectations.
Assess reliability, security and performance.
Provide confidence before release.
Prevent defects from reaching users.
Test Planning
|
v
Test Case Design
|
v
Test Environment Setup
|
v
Test Execution
|
v
Defect Reporting
|
v
Retesting and Regression
|
v
Test Closure
Error, Fault and Failure
Error: Human mistake or incorrect internal state.
Fault/defect: Incorrect code, design or requirement.
Failure: Observable incorrect behavior during execution.
8. Principles of Software Testing 7 Marks
Testing shows the presence of defects, not their complete absence.
Exhaustive testing is impossible.
Testing should start early.
Defects tend to cluster in a small number of modules.
Repeated tests become less effective over time.
Testing depends on application context.
A defect-free system may still be useless if it does not satisfy user needs.
Every test should be traceable to a requirement.
Independent testing improves objectivity.
9. Levels of Software Testing 14 Marks
Acceptance Testing
▲
|
System Testing
▲
|
Integration Testing
▲
|
Unit Testing
Level
Focus
Typical Performer
Unit Testing
Individual module or function
Developer
Integration Testing
Interfaces between modules
Developer/Test team
System Testing
Complete integrated system
Independent test team
Acceptance Testing
User and business requirements
Customer/End user
10. Unit Testing 14 Marks
Unit testing verifies the smallest testable software component independently.
Areas Tested
Module interface
Local data structures
Independent paths
Boundary conditions
Error-handling paths
Test Harness Components
Driver: Calls the module under test.
Stub: Simulates a lower-level module called by the tested module.
Mock: Simulates a dependency and verifies interaction.
Advantages
Finds defects early.
Simplifies debugging.
Supports safe refactoring.
Improves module reliability.
11. Integration Testing 14 Marks
Integration testing verifies interfaces, data flow and interaction among combined modules.
Strategies
Big-Bang Integration
All modules are combined at once. It is simple but defect isolation is difficult.
Top-Down Integration
Integration begins with the main module and proceeds downward. Stubs simulate missing lower modules.
Bottom-Up Integration
Low-level modules are integrated first. Drivers simulate higher-level callers.
Sandwich/Hybrid Integration
Top-down and bottom-up approaches are used simultaneously.
Strategy
Main Advantage
Main Limitation
Big Bang
No temporary stubs/drivers
Difficult fault isolation
Top Down
Main control tested early
Needs stubs
Bottom Up
Utility modules tested early
Needs drivers
Sandwich
Parallel integration
More planning required
12. System Testing 14 Marks
System testing evaluates the complete integrated software in an environment close to actual operation.
Types
Functional testing: Tests complete functions against requirements.
Performance testing: Measures speed, throughput and resource use.
Load testing: Tests expected workload.
Stress testing: Tests beyond normal limits.
Security testing: Finds vulnerabilities and verifies protection.
Recovery testing: Checks recovery after failure.
Usability testing: Evaluates ease of use.
Compatibility testing: Tests devices, browsers and environments.
Installation testing: Verifies installation and removal.
13. Acceptance Testing 7 Marks
Acceptance testing determines whether the software is ready for delivery and acceptable to the customer or users.
Types
Alpha testing: Conducted at the developer's site under controlled conditions.
Beta testing: Conducted by selected users in real environments.
User Acceptance Testing: Business users verify agreed acceptance criteria.
Operational acceptance: Verifies backup, recovery, support and deployment readiness.
14. White-Box Testing 14 Marks
White-box testing designs test cases using knowledge of internal code structure, logic and control flow.
Techniques
Statement coverage
Branch or decision coverage
Condition coverage
Path coverage
Loop testing
Data-flow testing
Basis path testing
Statement Coverage = Executed Statements / Total Statements × 100
Branch Coverage = Executed Branches / Total Branches × 100
Advantages
Finds hidden logical errors.
Measures code coverage.
Detects unreachable code.
Tests loops and complex paths.
Limitations
Requires code knowledge.
All paths may be impossible to test.
May miss missing requirements.
15. Basis Path Testing and Cyclomatic Complexity 14 Marks
Basis path testing identifies a set of linearly independent paths through a program using its control-flow graph.
Cyclomatic Complexity
V(G) = E − N + 2P
E = number of edges, N = number of nodes, P = number of connected components, normally 1.
Alternative: V(G) = Number of Predicate Nodes + 1
If a control-flow graph contains 10 edges and 8 nodes:
V(G) = 10 − 8 + 2 = 4
Therefore, four independent paths should be tested.
Steps
Draw the control-flow graph.
Calculate cyclomatic complexity.
Identify independent paths.
Design test cases to execute every path.
16. Black-Box Testing 14 Marks
Black-box testing designs test cases from external requirements without considering internal code structure.
Techniques
Equivalence partitioning
Boundary value analysis
Decision table testing
Cause-effect graphing
State transition testing
Use-case testing
Error guessing
Advantages
Independent of implementation language.
Validates user-visible behavior.
Can be designed from specifications.
Detects missing and incorrect functions.
Limitations
Internal paths are not directly checked.
Test coverage may be difficult to measure.
Unclear requirements produce weak tests.
17. Equivalence Partitioning and Boundary Value Analysis 14 Marks
Equivalence Partitioning
Equivalence partitioning divides input data into valid and invalid classes expected to behave similarly. One representative value is selected from each class.
For an age field accepting 18 to 60:
Invalid class: age < 18
Valid class: 18 ≤ age ≤ 60
Invalid class: age > 60
Boundary Value Analysis
Boundary value analysis selects test data at and near the edges of input ranges because many defects occur at boundaries.
For range 18 to 60, useful boundary tests are:
17, 18, 19, 59, 60 and 61.
Decision Table Testing
Useful when system output depends on combinations of several conditions and business rules.
18. Regression, Smoke and Sanity Testing 7 Marks
Regression Testing
Regression testing re-executes existing tests after changes to ensure that previously working features still work.
Smoke Testing
A broad, shallow test of the most important functions to decide whether a build is stable enough for detailed testing.
Sanity Testing
A narrow, focused test that checks a specific change or defect correction.
Testing
Scope
Purpose
Regression
Broad or selected old functionality
Find side effects of changes
Smoke
Broad and shallow
Check build stability
Sanity
Narrow and deep
Check a specific change
19. Debugging 14 Marks
Debugging is the systematic process of locating, analyzing and correcting the cause of a software failure.
Failure Observed
|
v
Reproduce the Failure
|
v
Collect Information
|
v
Locate Root Cause
|
v
Correct the Defect
|
v
Retest
|
v
Regression Testing
Debugging Approaches
Brute force: Use logs, traces, dumps and print statements.
Backtracking: Trace backward from failure to source.
Cause elimination: Form and eliminate possible causes.
Program slicing: Examine statements affecting a variable or result.
Binary partitioning: Narrow the faulty area by dividing the search space.
Testing vs Debugging
Testing
Debugging
Reveals a failure
Finds and fixes its cause
Can be performed by testers
Usually performed by developers
Planned through test cases
Diagnostic and investigative
Does not necessarily modify code
Usually modifies code
20. Test Plan, Test Case and Defect Report 14 Marks
Test Plan Contents
Test objectives and scope
Features to be tested and excluded
Test strategy and levels
Environment and tools
Roles and responsibilities
Entry and exit criteria
Schedule and deliverables
Risks and assumptions
Test Case Fields
Test case ID and title
Requirement reference
Preconditions
Input data
Execution steps
Expected result
Actual result
Status and remarks
Defect Report Fields
Defect ID and summary
Environment and build
Steps to reproduce
Expected and actual results
Severity and priority
Evidence such as screenshot or log
Status, owner and resolution
21. Important Comparisons 14 Marks
White-Box vs Black-Box Testing
Basis
White Box
Black Box
Knowledge
Internal code knowledge required
Internal code knowledge not required
Focus
Logic, paths and structure
Inputs, outputs and requirements
Common level
Unit and integration
System and acceptance
Techniques
Coverage, basis path, loop testing
Equivalence, BVA, decision table
Alpha vs Beta Testing
Basis
Alpha
Beta
Location
Developer site
User environment
Control
Controlled
Real-world use
Participants
Internal team and selected users
External users
Timing
Before beta
Before final release
Unit 4 Quick Revision
Coding converts design into source code.
Coding standards improve readability, maintainability and teamwork.
Code reviews detect defects before dynamic testing.
Verification asks whether the product is built right.
Validation asks whether the right product is built.
Testing detects defects and provides confidence.
Unit testing checks individual components.
Integration testing checks module interfaces.
System testing checks the complete integrated system.
Acceptance testing checks customer readiness.
White-box testing examines internal logic.
Black-box testing examines input-output behavior.
Cyclomatic complexity gives the number of independent paths.
Regression testing checks side effects after changes.
Debugging identifies and removes root causes.
Important RGPV Exam Questions
Long Answer Questions
Explain the coding phase and objectives of good coding.
Discuss coding standards and good programming practices.
Explain code review and formal software inspection.
Differentiate verification and validation.
Define software testing and explain its objectives and principles.
Explain different levels of software testing.
Explain unit testing and test harness components.
Compare top-down, bottom-up, big-bang and sandwich integration testing.
Explain different types of system testing.
Differentiate alpha and beta testing.
Explain white-box testing techniques.
Explain basis path testing and cyclomatic complexity.
Explain black-box testing techniques.
Explain equivalence partitioning and boundary value analysis with examples.
Differentiate regression, smoke and sanity testing.
Define debugging and explain debugging approaches.
Differentiate testing and debugging.
Explain the contents of a test plan and test case.
Compare white-box and black-box testing.
Short Answer Questions
Define coding standard.
What is defensive programming?
Define software inspection.
What is verification?
What is validation?
Define unit testing.
What are stubs and drivers?
What is smoke testing?
Define regression testing.
What is statement coverage?
Define cyclomatic complexity.
What is equivalence partitioning?
What is boundary value analysis?
Define alpha and beta testing.
What is debugging?
Exam Tip: Testing answers should include definition, objective, diagram, techniques, advantages, limitations and a suitable example. Cyclomatic complexity numericals are especially important.
Download Study Resources
Unit 4 PDF
Printable Unit 4 notes will be available soon.
Coming Soon
Testing Diagrams
Exam-ready testing diagrams will be available soon.
Coming Soon
Important Questions
Expected Unit 4 questions will be available soon.
Coming Soon
Frequently Asked Questions
Verification checks whether the product is built according to specification, while validation checks whether it satisfies actual user needs.