7 Steps to successful testing

1. Understand the roles
2. Identify software or medium to track defects
3. Set up the chosen medium and create instructions
4. Create test cases (for integration and system testing)
5. Create test scenarios (for user acceptance testing)
6. Execute testing phases
7. Gain business approval

Understand roles

You must figure ahead of time everyone who is going to assist you in testing. You cannot do this once the testing stage arrives.

• Is there a Quality Assurance team?
  • If yes, then what is their role?
• Who from the business will be testing and their availability?
  •  E.g. users, subject management experts, management team person/s, etc.
• Are there others from the Project Team that will be involved?
  • E.g. other BA’s, developers, system analysts, trainers (people who explain/teach the software being built), executive management (rarely)
• What testing phases will you be responsible for?
  • Define early in the project the roles of each one, including yourself, responsible for the when and what of testing. E.g who and to what extent (i.e. write, execute or review) will be doing the integration testing, system testing, user acceptance testing, etc.
• Who is doing the defect management?
  • Who is going to set up and who is going to work through it? It would usually be either the Business Analyst or the Quality Assurance team.

Identify software or medium to track defects

E.g

• Excel
• JIRA
• Pivotal Tracker
• HP ALM

Set up the chosen medium (software) and create instructions

• Set up the project and integrate the testing software/medium.
• Provide valid access based on the roles identified i.e. what user (BA, QA, developer, manager, etc)  can perform what function (read, write, modify, delete).
• Create a technical document about the testing software/medium for the internal use of the project team
  • What it is
  • What it means
  • How the user will utilize the software i.e. process to follow
• Create user instructions document
  • Defect logging (where to document, details to include, test the change)
  • Retesting

Create Test Cases

Perform the 4 step test-case creation:

The 4 Step Test Creation Guide

1. Understand the requirement you are testing
2. Write step-by-step instructions on how to verify it works
3. Add in expected outcomes to each step
4. Define prerequisites / pre-conditions

Create Test Scenarios

• It is a single general statement that gives a high-level test procedure.
• It could include multiple test cases.
• It allows the tester to interpret the action needed. It tells them what needs to be accomplished but not how it will be accomplished. They should be intuitively able to figure out the how-to steps.
• It helps adjust for unexpected user test paths and input.

Execute Testing Phases

Integration and System Testing

• Get  other tester/s up to speed.
  • Divide work based on identified roles and also coordinate the testing.
• Validate each test case
  • Document any defects or bugs you find.
  • Include notes, screenshots, and steps to recreate the issue (more the info the better it is for the developer and others to reproduce and understand the defect).
• Assign identified defects to necessary resources.
• Re-test defects as they are resolved
• Work through the full document again to ensure all test cases pass.
  • This is regression testing and can be optional in some cases. You can also delegate this task to another person to get more perspective.

User Acceptance Testing

• Demo the built software to the business users.
  • You don’t have to go in every detail, remember they are business users and not technical users.
  • Explain to them the general flow and explain basic functionality so that they can use the software.
• Review and explain the defect tracking software/medium.
  • Walkthrough the instructions you created.
  • Demo the defect tracking software.
• Explain the test scenarios, their role as testers and what they are expected to accomplish
  • what they will test, how they will test and log defects
• Provide a timeline for testing and create check-in points.
  • Set daily or weekly meetings based on project timeline to check on progress, resolve queries, validate results.
  • Enforce adherence to the timeline.
• Validate any defects that are entered
  • Don’t be a defect-forwarder.
  • Ensure it is valid defect/bug and can be reproduced by testing it yourself first
  • Understand the defect (e.g. is it a code error, configuration error, design error etc) so that you can explain it to the concerned person.
• Assign validated defects to necessary resources.
  • Developer, yourself, etc
• Ensure identified defects are resolved.
  • You should validate the bug is resolved.
  • The business user/s should validate the bug is resolved.
• Periodically discuss with Project Sponsor, and other key project team members, the state of the software and open defects.
  • Create a status report on
    • the number of defects being generated
    • the ratio of critical to minor defects
    • additional issues being identified
    • additional requirements being identified
  • If the resources are few and you have a strict timeline then request for additional resources.
  • If there is a project manager then explain the process to him/her else to the project sponsor directly.
• Identify what needs to be resolved before the go-live date and if feasible.
  • It is impossible to get every defect resolved before going live.
  • Identify the critical ones that “have” to be resolved.
  • Divide the defects into 3 categories and get an agreement based on it.
    • what needs to be fixed
    • what should be fixed
    • what can wait before going live

Final Testing

• Work through the full document again to ensure all test cases pass. This is regression testing and can be optional in some cases. You can also delegate this task to another person to get more perspective.

Gain Business Approval

It is not always feasible to resolve all defects before the go-live date so the business needs to be brought in to make the decision.

• You (or the PM) set up a Go-Live Decision meeting 2-3 days before the go-live date with the project team and the project sponsor.
• Review the state of the software and any open defects.
• Judge risk to launch with defects and make recommendations.
  • Based on the risk you can decide to launch as planned or delay launch date to fix specific defects.
  • Also remember, since you have just 2-3 days you cannot make too many additional adjustments as you many introduce new defects. So again if you “have” to make adjustments then postpone the launch date.
• Execute on the determined plan
  • Create a launch plan.
  • Decide on the final points to be completed before the software launch.
  • If the points are completed then you launch the software else postpone the launch.

The post is  based on my notes and understanding from this Testing Tutorial