Project Management Testing Phase Quiz

Software Testing and Quality Assurance (SEng4051)

• Course offered by the Department of Software Engineering, School of Computing and Informatics at Mizan-Tepi University.

Chapter Two: Software Testing

• Introduction:

  • Software developers spend 50% of their time on finding and fixing bugs.
  • Professional programmers introduce 1-3 bugs per 100 lines of code.
  • Annual global cost of software debugging is $312 billion.
  • Software bugs cost the U.S. economy an estimated $59.5 billion annually.
  • Improved testing can eliminate $22.2 billion in costs.

• What is software testing?

  • Checking if actual results match expected results.
  • Ensuring defect-free software.
  • Verifying and validating whether software applications function as expected.
  • Aims to find defects and enhance product quality.
  • Identifying errors, gaps, or missing requirements that conflict with actual needs.
  • Can be done manually or using automated tools.

• Why software testing is required?

  • Even well-designed software will contain defects during development.
  • Zero-defect software creation is not possible.
  • Testing is vital to find as many problems as possible.
  • Focus on fixing the most critical problems due to time constraints.

• Who does the software testing?

  • Often debate on whether developers should test.
  • Developers are often blind to their own mistakes.
  • Testers provide an unbiased perspective, focusing on specifications.
  • Testers are better equipped to identify areas developers might overlook.
  • Independent testers are crucial for effective testing.
  • Buddy/Pair testing is common where developers test each other's work.
  • Clearly defined testing teams for specific testing types (usability, performance, security) are necessary.
  • Outsourcing is sometimes a method for additional testing resources.

• What should be tested?

  • Testers should have a solid understanding of project requirements.
  • GUI, security, usability, code, efficiency, and modularity should be evaluated.

• When is software testing done?

  • Earlier testing saves development time, money, and effort.
  • Conducting testing too late can be costly due to difficulty in rectifying defects.
  • Dividing development into stages, testing each stage individually, allows for better control and quicker resolution to issues..

• Software testing process

  • A cyclical process that needs to be planned and executed.
  • Analysis of the product requirements, followed by planing the test, and determining the deliverables that support the project.
  • Creating, designing, and documenting the test cases.
  • The test environment is set up and the actual test execution phase.
  • Closing out the test in a report that evaluates the test coverage, and identifying areas to improve for future applications.

• 1.Requirement Analysis:

  • Understanding application purpose, user count, and how the software will aid the client. -Gathering comprehensive information on the software.

• 2. Software test planning:

  • Documentation of software testing requirements in an organized manner.
  • The test plan acts as a blueprint for conducting software testing, monitored and controlled by the test manager.
  • Including test tasks (what), strategy (how), approach (how), objectives (why), resources, schedule, estimations, and deliverables (outputs).

• 3. Develop test strategy:

  • Defining project testing objectives and methods, including effort and costs.
  • This section outlines steps that should be followed during the test.

• 2.1. Define testing scope

  • Clearly defining the system components that should be included (in scope) and excluded (out of scope).
  • Importance of clearly defined scope to all stakeholders..
  • Considering factors like precise customer requirements, budget constraints, and test team skills.

• 2.2. Identify testing type: -Defining specific testing types essential to identify product bugs and achieve the common goal of comprehensive testing. -Understanding priorities and costs associated with various testing types.

• 2.3. Document risk and mitigation:

  • Identifying potential risks (e.g., team member skill gaps, tight deadlines, poor management).
  • Outline approaches to mitigate those risks.

• 2.4. Create test logistics:

  • Defining who performs testing (testers or developers).
  • Setting the schedule of the test.

• 3. Define Test Objectives:

  • Listing features to be tested (functional and non-functional).
  • Defining target/goal for testing based on the features listed.

• 4. Define Test Criteria:

  • Setting guidelines for test procedures, with two categories:
  • suspension criteria—to control testing in cases of issues.
  • exit criteria—marks successful testing completion of a phase.
  • Describing examples.

• 5. Resource Planning:

  • Summary of resources (human, physical, financial).
  • Using resources to create accurate schedules and estimations.

• 6. Planning Test Environment:

  • Setting up hardware and software to replicate user environment.
  • Gathering information about the application to be tested, including its maximum user connections and hardware/software requirements..

• 7.Schedule & Estimation:

  • Breaking down project into tasks.
  • Estimating effort required for each task.

• 8. Determine Test Deliverables:

  • List of documents, tools, and other components required.
  • Deliverables are categorized as provided before, during, and after testing.

• Outline of a Test Plan: Format details to cover with each section.

  • Introduction, test items, features not to be tested, test approach, criteria, environmental needs, staffing/training, and risks.

• Brief Description:

  • Provides a unique identifier for the test plan.
  • Has a brief introduction to the project, objectives, and specific items.
  • Includes a description of the software under test and features to test.

• 3. Test Design

  • Creating and writing test artifacts (e.g., test cases).
  • Tasks include identifying test basis, developing test scenarios, identifying/describing test cases, developing a test suite, and identifying/structuring test scripts.

• 3.1.Test Basis

  • Identifying the sources used for test scenarios, including application itself, specifications like SRS, and BRS.

• 3.2.Test Scenarios

  • Describing functionality that can be tested.

• 3.3. Test Cases:

  • Defining actions/conditions performed on the software to verify expected functionality.

• Format of a Standard Login Test Case:

  • Structure for creating and running a test case.

• Good Test Case Characteristics:

  • Simplicity and Transparency
  • End User perspective
  • Avoiding redundant test cases
  • Ensuring proper coverage.

• Test Suites, Scripts, and Data: Test data is documented data for testing software.

  • Positive and negative test data

• 4. Test Environment

  • Configuring hardware and software needed for testing.
  • Replicating end-user environments.

• 5. Test Execution

  • Executing test cases.
  • Marking cases as passed, failed, blocked, or not run.
  • Reporting defects to development.

• 6. Test Reporting and closure:

  • Discussing testing and identifying areas of improvement.
  • Evaluating cycle completion based on factors like coverage, quality, cost, and time.
  • Analyzing defect reports and distribution by type/severity.