Have you ever come across the biggest challenge of setting up testing processes in your organization or you are in an organization where there is no testing process and you are in a dire need of one, but have no idea where to start from? An organization running with no testing processes defined is a person running on a treadmill with no pointers/targets defined. He has no clue when to stop and what or how much is been achieved. An organization with streamlined processes in hand helps organizations to grow and define quality parameters achieved or acquired across there services or products. So how do you introduce or invent testing processes in your organization.?

Before we kick into the details of how one can start, it’s important to understand all organizations have a different work ethics, culture and process. The testing process to be set up may vary accordingly. The major perspective to understand while laying down the testing processes is “Testing is not a silver bullet that would resolve all problems” neither does it mean “developers no longer need to perform testing as testers are their now” neither does it mean “testers are tornados that destroy everything you create”. Before anything else, you need to start working as a team-first where a “test friendly” environment is created and the team is aware that all of the people are working together to deliver a quality product on time and every time.

[arrow_forms id=’4331′]

Analyze your work culture and environment:

This is a stepping stone of setting up your testing process or shall I say the base foundation. It’s important to analyze how your organization works and is structured. Closely monitor the activities carried out from the start to the end of the project(s). Note down the bottlenecks of the project that impacts quality, for example, unplanned releases back to back or too many issues reported by stakeholders etc. Post writing down the bottlenecks, prioritize them based on their impact and start working towards them. Please note, setting up processes and their implementation is not a day activity, its a learn and grow process. It takes time to deliver the results you expect it too.

Introduce the testing cycle in the project(s)

Post the bottlenecks, the first thing one should ensure is to start the cycle of testing, no matter where your project is currently at, ensure you start testing(ofcourse I meant post you have a fair understanding of the project(requirements) you wish to test for). Let’s say you are in the mid of release and you have stories or requirements in hand that are ready to be delivered, just perform ad-hoc testing. What purpose will this serve? This will provide you visibility and clarity of the testing space you have in hand and to the team who will be acquainted of the fact that development won’t suffice for delivery and everything moving forward would be tested through. This would help in building up team collaboration among the team members.

Create your test plan and test strategy

Do not try to backtrack things at this stage as you enter testing. The main vision should be to ensure everything post-testing cycle is introduced should fall into places. Start working on the smaller chunks of things as in one bottleneck at one time. Create your test plan, to bring your releases on track. Communicate to team members as when will testing start, what is the testing scope, what are pre-requisites you would need to test. For example, all the requirements/stories to be delivered in a given release should be provided to the tester upfront. The development closure date for all those requirements should be shared in prior so that the QA can plan his testing activities. A test environment to be setup for the QA to test the deliverables etc. Similarly, define your test strategy and share it with your team. As in what forms of testing would be performed for example system testing, regression testing, smoke testing etc and what are outputs received and what cycle will be followed for a delivery of the requirement to the customer.
For details on how to build a test plan, you can refer my article  https://qavibes.blogspot.com/2018/06/all-about-test-plan.html

Define your testing outcomes and deliverables

No outcomes mean nothing achieved. Outcomes should be mapped in terms of each testing activity performed. For example, if system testing is performed across requirements, then outcome across requirement would either means bugs logged across requirements or closure of the requirement post-testing. Every activity should have a defined deliverable. For example, post system testing, a summary report highlighting the number of requirements tested, number of logged issues with severity should be shared with stakeholders. We should have defined parameters that highlight if desired outcomes are reached then one can enter to the next cycle of testing. For example, if the number of issues left for fixing can be deferred looking at the business criticality, then post its approval, testing team can kick-start regression before delivering the build to production. Similarly once the outcome for regression is positive and build is QA sign-off(deliverable), the team can push the build to production. Every outcome would help the team move to the next actionable plan with defined deliverables across each. This helps provide testing checks across software, making it more robust and structured, thereby ensuring a stable quality software.

Documenting and Tracking

In testing, documentation plays an important role. Once you have dived into the testing cycle with defined deliverables, it’s important to start documenting. Test Artefacts should be provided across requirements like smoke document, test scenarios, test cases, regression suite etc. Once those are documented, those should be timely updated. This documentation helps provide better test coverage across your requirements. Providing test cases at an early stage also help developer visualize the requirement in more depth and ensure their code handles the documented scenarios. Documentation also adds to the stability of the product as all previous functionalities are backed by documentation and helps spread awareness even among new joiners who wish to have better visibility of the software.
Tracking your requirements until they are ready to be shipped is also important. Tracking bugs across their bug cycle help ensure no major breakthrough in the application is present. Tracking all testing activities helps to raise alarming signals for the software under test and take constructive actions across them.

Reinventing the wheel

Once you know the basic testing processes are set up where you are aware of what follows after the other, it’s important to evolve your testing processes. Introducing tool support, testing metrics, standard documentation requirement, root cause analysis etc helps provide a deeper understanding of quality and make the team more focused on achieving it. As your testing processes get more skilled and streamlined, the quality bar of your product is automatically increased. Sometimes we get into the wrong track by focussing on areas that do not need attention at an early stage. For example, I have encountered people, who want to bring test tool into the organization as one of the starting points of introducing testing. We need to understand test tools helps increase the efficiency of our work and do not define a  testing process. Things like test tools help improvise your testing methodologies.

The testing process to be defined in an organization should be built on the base foundation of a vision that we need to achieve in terms of quality. All organizations may have different testing processes based on work ethics, culture, needs, budget and even constraints etc. While trying to build a testing process it’s important you dig into these areas and then start defining them. What goes by standard may not fit in the organization and needs to be altered accordingly. Processes defined should never become barriers in the company or team path and should just act as a catalyst to speed up the process and help deliver quality.

Closing the article with the below quotes:

“While we may understand the problem, it is critical for us to change our thinking, our practices, and continuously evolve to stay ahead of the problems we face.”— Mike Lyles

Author: Sadhvi Singh