Welcome to Unit A2 2: Testing the Solution
Welcome to your study guide for Testing the Solution! This chapter covers a vital part of your Unit A2 2: Implementing Solutions coursework portfolio in CCEA GCE Software Systems Development.
In Unit A2 2, you are building a fully working, object-oriented, database-driven software solution using C# / .NET and an SQL relational database in Visual Studio based on the CCEA pre-release case study. Did you know that Unit A2 2 makes up 50% of your A2 award and 30% of your total A Level? Producing high-quality testing documentation is essential to securing top marks in your portfolio.
Don't worry if formal testing feels a bit overwhelming at first. We will break down every requirement step-by-step so you can design, execute, and document your tests with confidence!
---1. The Purpose and Approach to Testing in A2 2
Testing is not just something you do at the very end when your project is finished. In your A2 2 portfolio, you must show evidence of:
• Iterative Testing: Testing individual methods, classes, and database operations as you write your code.
• Summative / System Testing: Testing the complete, integrated software solution against all functional and non-functional requirements outlined in the pre-release case study.
The goal of testing is to prove that your solution is robust, handles errors gracefully, maintains data integrity in SQL, and fulfills all user requirements without crashing.
Key Takeaway: Testing is a continuous, ongoing process throughout software development, not a rushed afterthought at the end of the project.
---2. The Standard CCEA Test Plan Structure
CCEA requires your test plan to be presented in a clear, structured table before testing begins. Your portfolio test table must include the following 8 standard columns:
1. Test ID / Number: A unique identifier for every single test case (e.g., TC01, TC02).
2. Requirement / Objective Reference: The specific functional requirement, user requirement, class, or method being verified (e.g., FR2.1 - Add New Customer).
3. Test Data / Input Values: The exact values or actions entered into the system.
4. Test Type / Category: The classification of the data (Valid, Extreme, or Invalid).
5. Expected Result: A precise, detailed statement of what the software should output, how the GUI should react, or what should happen in the SQL database.
6. Actual Result: What actually occurred when the test was run.
7. Pass / Fail / Action Taken: The status outcome. If a test fails, you must state the corrective action and code fix applied.
8. Evidence Reference: A cross-reference to your numbered, annotated screenshot showing the test in action (e.g., See Appendix Figure 4.1).
Example of a Quality Test Plan Row
• Test ID: TC04
• Requirement Ref: FR1.3 (Stock Quantity Entry)
• Test Data: -5
• Test Type: Invalid
• Expected Result: Error message "Stock quantity cannot be negative" appears in red text; record is not inserted into tblStock.
• Actual Result: Error message displayed as expected; database record count unchanged.
• Pass / Fail / Action Taken: Pass.
• Evidence Ref: Screenshot Fig 3.4
Key Takeaway: Always ensure every test case has an exact Expected Result and a clear link to visual Evidence in your portfolio.
---3. Test Data Classifications (The "VEI" Rule)
To thoroughly test your system, you must select test data from three distinct categories:
A. Valid (Normal) Data
• Definition: Data that falls squarely within acceptable boundaries and follows normal business rules.
• Purpose: Confirms that the system's "happy path" works properly under everyday conditions.
• Example: Entering an existing customer ID, a correctly formatted text string, or a valid price like \(£19.99\).
B. Extreme (Boundary / Edge) Data
• Definition: Data at the absolute minimum and maximum allowable limits of constraints.
• Purpose: Checks that boundary conditions in your validation logic (such as \(<\), \(>\), \(\le\), \(\ge\)) are coded correctly.
• Example: If a password must be between 8 and 20 characters, testing exactly 8 characters and exactly 20 characters.
C. Invalid (Erroneous) Data
• Definition: Data completely outside allowable domains, formats, or business rules.
• Purpose: Verifies that input validation controls and exception handlers stop illegal data from corrupting the database or crashing the program.
• Example: Entering letters into a numeric phone number field, entering negative quantities, or submitting a non-existent Foreign Key.
Analogy: The Theme Park Ride
Think of a rollercoaster with a height limit between 120 cm and 200 cm:
• Valid Data: 150 cm (allowed straight on).
• Extreme Data: Exactly 120 cm and 200 cm (tested right on the limit).
• Invalid Data: 110 cm (too short) or "banana" (wrong data type entirely!).
Key Takeaway: A balanced test plan requires a rich mix of Valid, Extreme, and Invalid test cases.
---4. Levels and Types of Testing in the A2 2 Portfolio
Your portfolio must demonstrate testing across multiple layers of your application architecture:
1. Unit / Method Testing
• Tests individual classes, methods, and algorithms in isolation.
• Focuses on verifying your custom data structures, search algorithms, sorting routines, and complex calculation methods before they are wired to the user interface.
2. Integration / Data Persistence Testing
• Verifies communication between your C# Object-Oriented code and your backend SQL relational database.
• Focuses on CRUD operations (Create, Read, Update, Delete).
• Verifies that SQL transactions commit properly, relational integrity rules (Primary and Foreign Keys) are enforced, and issues like SQL injection or null reference exceptions are avoided.
3. Validation and Exception Handling Testing
• Checks both front-end GUI input validation controls and code-level try-catch blocks.
• Ensures that runtime exceptions are caught gracefully and translated into meaningful error messages for the user.
• Essential exceptions to test include:
• SqlException: e.g., attempting to insert duplicate primary keys or violating foreign key constraints.
• FormatException: e.g., parsing invalid strings into integers or dates.
• NullReferenceException: e.g., attempting to access an uninstantiated object or missing record.
4. System / Functional Testing
• Verifies complete, end-to-end workflows across the whole application.
• Simulates real scenarios specified in the CCEA pre-release brief (e.g., creating a customer account, generating an invoice, updating stock levels, and producing a summary report all in one sequence).
5. User Acceptance Testing (UAT)
• Carried out against the original user requirements, ideally involving feedback from a client or target end-user.
• Evaluates Human-Computer Interaction (HCI) principles, screen navigation, readability, and overall usability to confirm the system is fit for purpose.
Key Takeaway: Show depth by testing isolated methods (Unit), database integration (CRUD/SQL), error trapping (Exceptions), full workflows (System), and usability (UAT).
---5. Common Pitfalls to Avoid (Examiner Feedback)
Be sure to avoid these frequent errors flagged in CCEA moderation reports:
• Retrospective Testing: Do not write your entire test table after coding is complete. A test log where every single test says "Pass" with zero bugs looks artificial. Real development involves encountering bugs, documenting them, fixing them, and re-testing!
• Vague Expected Results: Never write generic results such as "It works" or "Shows error". Always be explicit (e.g., "Label lblError displays 'Invalid Date Format' and the Save button remains disabled").
• Ignoring SQL Database Constraints: Do not just test GUI textboxes. Make sure to test database-level constraints, including PRIMARY KEY uniqueness violations, FOREIGN KEY reference rules, and NOT NULL field rejections.
• Missing or Unclear Visual Evidence: Every test execution must be backed up by a clear, high-resolution screenshot directly linked to the specific Test ID (e.g., TC01).
Quick Review Checklist
Before submitting your Testing the Solution documentation, make sure you can answer YES to all of the following:
• Did I include all 8 required columns in my test table?
• Have I tested Valid, Extreme, and Invalid data for each major input?
• Have I verified all CRUD database operations and try-catch exception blocks (e.g., SqlException, FormatException)?
• Did I clearly record any failed tests and the corrective actions taken?
• Are all screenshots clearly annotated and cross-referenced to their Test IDs?