“Good food depends almost entirely on the right ingredients”
Testing processes and activities that add value in delivering quality products to clients require some really good ingredients. At Leapfrog, we follow the best QA practices which help us create quality products. If you want to know our secret, you are at the right place.
There are various steps we follow as secret ingredients to deliver a quality product, out of which, the following are the most common for almost every project.
- Understand the stakeholder’s goal and align it to your own
- Define test strategy
- Plan as a journey
- Execute the plan
- Test as a team
- Evolve, adapt and assure
Understand the stakeholder’s goals and align it to your own
For a QA, stakeholders are the people who are directly or indirectly affected by their tests and the ensuing results. While defining a test strategy, we are responsible for identifying the people or organizations that will benefit from the test deliverables we create. It is used to answer a simple set of questions from which we benefit in the later stages:
- In-scope/ out-scope of the test plan
- Priority features
- Use of reports generated by us
- What information and deliverables are required
- Roadmap of our tests
Define test strategy
Not all projects are of the same nature. We deliver a product at the end but the project nature may vary by then. This results in a change in the test strategy based on the current situation and context. Yet, the thought process for every project remains the same. There are various approaches we use in Leapfrog to structure the test strategy. Some of them are:
- Stakeholders’ Objectives (Goal and risk management plan decisions, confidence, assessment, scope)
- Design Thinking (empathize, define, ideate, prototype, test)
There may be certain projects where designated QAs are not involved. Such situations arise due to the client’s decision or the scurvy nature of the project. In such cases, we use the Shift- Left approach. In this approach, developers take responsibility and ownership of their testing from the early stage of development. Project Manager or Team Lead, with the help of developers, and sometimes involving the end users/ clients suggest the scenarios or examples that challenge the User Story or Acceptance Criteria to think through the edge cases before writing any code.
Plan as a journey
Test planning is similar to project planning but on a smaller scale. A QA creates a test plan considering the broad range of activities that are required to be delivered. Such activities include the dependencies, development time, probable risks, resources as well as testing time. Planning is a continuous process, and not merely a deliverable. All the activities mentioned are fallible. We can anticipate some untoward things happening but can’t predict their likelihood or impact in our plan and estimates. These activities go hand in hand, or one after another as the project development journey continues.
- Test Activities: exploration, test design, feedback, reporting, logging
- Test Logistics: create a test environment, prepare test data, create automation scripts
Execute the plan
Some key components which impact test execution are:
- People (the team)
- Test Cases/ Data
- System Under Test
The first three aspects are under the control of QA, whereas the latter is not. Moreover, we have some secrets that are being used while executing the plan,
- Partial/ Incremental Delivery: In cases where the whole system is not ready to be tested, partially completed features can undergo tests with a promise that the later release would contain the remaining functionality. Note that ‘Testing time lost due to partial or late deliveries cannot be negotiated by working harder.’
- Categorizing Incidents as priority and severity.
Test as a team
Using Shift-Left Approach: As mentioned earlier, this approach helps to involve QAs at an earlier stage of development. This helps to counter questions about the Acceptance Criteria, approaches for developing a feature, and writing user stories. It also helps to move around the business goals using BDD approaches.
Testing is an activity, not a role: The process triggered by the shift-left approach clears out that testing is not a role anymore. The developers use unit and component level testing to give quality work and are held accountable for it.
The role of QA is not just testing: Since the QAs are involved from the beginning of the project, they provide/ accept feedback to users, product owners, developers, PMs for any features in Sprint level, Epic Level, or Project Levels.
Evolve, adapt and assure
Even though all ingredients are readily available to cook up a dish, it can not be perfect in one go. Likewise, we should keep on experimenting, adapting to the nature of the project, and molding our strategy accordingly. Coaching others also gives new ideas and knowledge to both mentors and mentees.
Not every project needs to follow all these steps to smoothly manage its testing process. We have listed some generic as well as tried and tested steps applicable to most projects, and they work well for us. You can adapt, modify and be creative. After all, this is what agile means.