Testing in the software development lifecycle in Testing Fundamentals - Framework Patterns

Framework Mode - Testing in the software development lifecycle

Folder Structure of a Testing Project

  project-root/
  ├── requirements/          # Documents describing what the software should do
  ├── design/                # Design documents and architecture diagrams
  ├── src/                   # Source code of the application
  ├── tests/                 # Test cases and test scripts
  │   ├── unit/              # Unit tests for small code parts
  │   ├── integration/       # Tests for combined parts
  │   ├── system/            # Tests for the whole system
  │   └── acceptance/        # Tests to check if requirements are met
  ├── test-data/             # Data used for testing
  ├── docs/                  # Testing plans, reports, and manuals
  └── ci-cd/                 # Scripts for continuous integration and deployment
  

Test Framework Layers in the Development Lifecycle

• Requirement Analysis Layer: Understand what to test based on requirements.
• Test Planning Layer: Decide what tests to create and when to run them.
• Test Design Layer: Write test cases and prepare test data.
• Test Implementation Layer: Develop automated tests or prepare manual test scripts.
• Test Execution Layer: Run tests and record results.
• Defect Tracking Layer: Report and track bugs found during testing.
• Test Reporting Layer: Summarize test results for the team and stakeholders.

Configuration Patterns for Testing in SDLC

• Environment Setup: Use separate environments for development, testing, and production to avoid conflicts.
• Test Data Management: Maintain clean and reusable test data sets for consistent testing.
• Version Control: Keep test scripts and configurations under version control to track changes.
• Parameterization: Use configuration files or environment variables to switch browsers, URLs, or credentials easily.
• Scheduling: Automate test runs at specific times or after code changes using CI/CD tools.

Test Reporting and CI/CD Integration

• Test Reports: Generate clear reports showing passed, failed, and skipped tests with details.
• Dashboards: Use dashboards to visualize test trends over time for better decision making.
• Alerts: Configure notifications (email, chat) for test failures to quickly inform the team.
• CI/CD Integration: Integrate tests into pipelines so tests run automatically on code commits or merges.
• Traceability: Link test results back to requirements and defects for full visibility.

Best Practices for Testing in the Software Development Lifecycle

1. Start Testing Early: Begin testing activities as soon as requirements are available to catch issues sooner.
2. Automate Repetitive Tests: Use automation for regression and frequent tests to save time and reduce errors.
3. Maintain Clear Documentation: Keep test plans, cases, and results well documented for team understanding and audits.
4. Collaborate Across Teams: Encourage communication between developers, testers, and business analysts for better quality.
5. Continuously Improve: Review and update tests and processes regularly based on feedback and defects found.

Self Check Question

Where in this folder structure would you add a new test case that verifies a new feature described in the requirements?

Answer: In the tests/acceptance/ folder, because acceptance tests verify that new features meet the requirements.

Key Result

Testing is integrated throughout the software development lifecycle to ensure quality from requirements to delivery.

Practice

1. Which phase in the software development lifecycle is primarily responsible for planning how testing will be done?

easy

A. Deployment

B. Coding

C. Requirement Analysis

D. Maintenance

Solution

1. Step 1: Understand the role of Requirement Analysis

   This phase gathers and analyzes what the software should do, including defining test requirements.

2. Step 2: Identify testing planning activities

   Planning how to test is done early, during Requirement Analysis, to ensure tests cover all needs.

3. Final Answer:

   Requirement Analysis -> Option C

4. Quick Check:

   Testing plan starts in Requirement Analysis [OK]

Hint: Testing plans start with requirements, not coding [OK]

Common Mistakes:

• Confusing coding phase with testing planning
• Thinking deployment includes test planning
• Assuming maintenance is for initial test planning

2. Which of the following is the correct syntax to describe a test case in a test plan document?

easy

A. Test Case ID: TC001\nDescription: Verify login functionality\nExpected Result: User logs in successfully

B. Test Case: Verify login\nResult: Success\nID: 001

C. ID: 001\nTest: Login check\nOutcome: Pass

D. Case Test 1\nCheck login\nExpected: true

Solution

1. Step 1: Identify standard test case format

   Standard test cases include clear ID, description, and expected result fields.

2. Step 2: Compare options to standard format

   Test Case ID: TC001\nDescription: Verify login functionality\nExpected Result: User logs in successfully matches the clear, structured format; others are incomplete or unclear.

3. Final Answer:

   Test Case ID: TC001\nDescription: Verify login functionality\nExpected Result: User logs in successfully -> Option A

4. Quick Check:

   Clear ID, description, expected result = Test Case ID: TC001\nDescription: Verify login functionality\nExpected Result: User logs in successfully [OK]

Hint: Look for clear ID, description, expected result format [OK]

Common Mistakes:

• Using unclear or incomplete test case fields
• Mixing field names or order
• Omitting expected results

3. Consider this code snippet representing a simple test function in Python:

def test_addition():
    result = 2 + 3
    assert result == 5
    print('Test passed')

What will be the output when this test runs?

medium

A. SyntaxError

B. Test passed

C. No output

D. AssertionError

Solution

1. Step 1: Analyze the test function logic

   The function adds 2 + 3, stores 5 in result, then asserts result equals 5, which is true.

2. Step 2: Determine output after assertion

   Since assertion passes, the print statement runs, outputting 'Test passed'.

3. Final Answer:

   Test passed -> Option B

4. Quick Check:

   Assertion true means print runs [OK]

Hint: If assert condition is true, print runs [OK]

Common Mistakes:

• Thinking assertion always raises error
• Expecting no output from print
• Confusing syntax with runtime error

4. A tester wrote this test script snippet:

def test_divide():
    result = 10 / 0
    assert result == 0

What is the main problem with this test?

medium

A. Test function name is incorrect

B. Assertion should check for 10, not 0

C. Missing print statement

D. Division by zero causes runtime error

Solution

1. Step 1: Identify the operation causing error

   Dividing 10 by 0 causes a ZeroDivisionError at runtime.

2. Step 2: Understand impact on test execution

   Because of the error, assertion is never reached and test fails with exception.

3. Final Answer:

   Division by zero causes runtime error -> Option D

4. Quick Check:

   Division by zero = runtime error [OK]

Hint: Division by zero always causes error [OK]

Common Mistakes:

• Ignoring runtime error and focusing on assertion
• Thinking assertion is wrong instead
• Assuming print statement needed

5. In a software project, testing is integrated throughout the lifecycle. Which testing type is best suited to catch issues caused by changes in code after deployment?

hard

A. Regression Testing

B. Unit Testing

C. Acceptance Testing

D. Smoke Testing

Solution

1. Step 1: Understand testing types and their purpose

   Unit Testing checks small code parts; Acceptance Testing checks user needs; Smoke Testing checks basic functionality.

2. Step 2: Identify testing for post-deployment changes

   Regression Testing reruns tests to ensure new changes don't break existing features after deployment.

3. Final Answer:

   Regression Testing -> Option A

4. Quick Check:

   Regression Testing catches post-change issues [OK]

Hint: Regression Testing checks after code changes [OK]

Common Mistakes:

• Confusing unit testing with regression testing
• Thinking acceptance testing covers code changes
• Assuming smoke testing is for detailed checks