Business Analyst Vs Testing

Discovering the unexpected is more important than confirming the known.

Business Analyst must Ensure the project meets the needs of the business from a business perspective. Ensure the business users can successfully perform business tasks and receive the expected outcomes from the system per the business requirements.

  • Serve in a consulting role regarding business requirements for the purpose of creating test scenarios and test cases; assist in defect root cause analysis from a requirements perspective.
  • Serve as requirements change request manager to analyze, document and process requirements change requests during QA/UAT testing.

BA may need to follow the Client’s Test Strategy during the Testing Phase: 

The scope of testing must clearly identify what items are in scope for testing and explicitly state which items are out of scope for testing. Based on the project scope, risks, priorities, dependencies, impacts, etc. This is a critical deliverable for the project, as much confusion arises on projects related to what will/will not be tested, and what is/is not required from a testing perspective.

And here comes the Test Plan: – The test plan should identify which items (per the documented scope of testing) should be tested, in what way, in what order, etc. to assure the quality of the finished product.

Define Entrance Criteria: – This is a checklist that defines everything that is needed to begin testing (test region set-up, test data, tester’s access to region, etc.

Test Schedule

  • Tasks: – Specific testing tasks that will be performed
  • Resources: – Specific people who will be performing each task
  • Timeframes: – Planned start date, duration and end dates for each task

Requirements Traceability Matrix helps Testers to be on Track and ensure all requirements have successful outcome.

  • The Requirements Traceability Matrix (RTM) is begun by the Business Analyst after the business requirements have been finalized. The requirements are listed in the RTM, including the requirement ID, requirement statement, and expected outcome/acceptance criteria. The RTM is updated downstream in the SDLC to include any functional (technical/system) requirements, design artifacts, and test cases that are used to implement and test the requirements.
  • The goal of the RTM is to provide traceability of requirements from elicitation, through development and testing in order to ensure all requirements have been fully implemented and tested in order to ensure that the system and the overall project meets its goals as well as the needs of the business.

Test scenarios & Test Cases

  • Test scenarios identify the specific conditions that must be tested based on the requirements that are implemented for the project
  • Test cases are the specific, executable tests that are carried out to test each scenario. There can be multiple test cases for each scenario to ensure a complete test.

Defect tracking log

  • The defect tracking log is a log that tracks identified defects in the system based on the observed outcome from the executed test cases (failures). This log is used to document defects and track the status of defect resolution efforts between the test team and the development team

Exit Criteria

  • Test Metrics Report/Final Results Document (for each testing cycle)
  • There will be multiple testing cycles during the testing phase
  • There must be a Test Metrics Report/Final Results Document completed for each testing cycle

Sign-off/approval upon satisfactory completion

Share this article

Contact info

About us


Join the network: We are Business Folks, analyzing IT projects.
We use cookies to improve our website. By continuing to use this website, you are giving consent to cookies being used. More details…