4 Things I Learned In My Thoughtworks Journey As QA

My journey as a Quality Analyst started a bit unexpectedly. In August 2015 when I came to Bangalore looking for Job in Software Industry, used to appear for the interviews only for a Development opportunity. To be honest, like every other Computer Science graduate out there, I was a bit skeptical about going ahead with Testing.

But one day I got the chance to appear in an interview for the role of Quality Assurance Engineer in Automation. I decided to give it a try just because they had asked for automation, since the only advice people around used to give is apart from Development if you want to go for something go for automation QA not manual.

So when I got selected as Automation QA, I took up the opportunity and from there started my journey as QA. For almost 3 years, I worked in an organization where I was working in a non-agile environment, having only the task to automate all the already drafted test cases by manual QA team. I did learn a lot there about how to design automation frameworks and how to integrate them with CI for better use of automation. But somewhere the complete picture of being a QA was never clear as there was no involvement of QA in other phases of SDLC.

Later after 3 years, I joined Thoughtworks as a Quality Analyst in 2018 where being a QA was not just confined to writing manual test scenarios or just doing automation. These last 3 years of my Thoughtworks journey have made me realize how important it is for a QA to be involved in all phases of the software development right from planning to development till deployment.

Here is a gist of my 4 important learnings for holistic quality assurance in a product cycle

Use a blend of manual and automated software testing

What does this mean?

If your current testing strategy is solely automated or manual, you might need to rethink it. A well-rounded QA strategy should include a blend of automated and manual testing. It should not be a ‘one or the other’ decision.

What actions should you take?

Automation testing can save time and money. By writing test cases for automation, you can run thousands of tests at once, verifying that the specific feature you are targeting works as expected.

But you cannot automate everything, there will always be unexpected and unknown possibilities in software development that need to be explored.Therefore, in such scenarios a level of creativity is required to identify ways in which software may not work.

To create a quality product, you need to implement a blend of manual and automated testing.

Exploratory Testing — What & Why?

What does this mean?

Exploratory testing is random or unstructured in nature and can reveal bugs that would go undiscovered during structured phase of testing .The aim is to find issues that have escaped other forms of testing. The expectation should be to document unexplored test scenarios and increase coverage.

Why is it important?

The main benefit of exploratory testing is that it requires a minimal amount of planning. Testers continuously decide for their next step of testing, and the decision depends upon the tester’s thought process. Exploratory testing is more productive than the scripted testing. It is used to identify real time bugs. Also, it is more often used to detect the bugs during UAT of the system. So, if we use exploratory testing early in the stage, then we can avoid many bugs.

Organizing Bug bashes within the team or outside the team can give us faster feedback coming from different mindsets exploring the application.

Create a culture of quality within your team

What does this mean?

A culture of quality is all about having an aligned vision, with shared responsibility for quality.

What actions should you take?

To build a quality product, you should always ensure quality at each level of product cycle, right from planning phase to development till Production.

To achieve this you need to have a successful strategy to testing that provides you to have test coverage at all phases of product development. One way of doing this is to use the Testing Pyramid.

Testing Pyramid — A pyramid of where all the different types of tests fits.

Having test coverage at various layers also improves the speed of the feedback loops, will encourage a faster product cycle

You can improve the rate of feedback as you move down the product cycle because you’ve built the right automation systems where necessary and the team has been involved right from the ideation stage.

Most people will recognise this as a “shift-left” approach to testing and QA — getting involved as early as possible. “Shift-left” however is only part of the answer to ensuring that you are aligning your QA with continuous integration and development.

Each of the people involved in the product development cycle have their own feedback loops which contribute to continuous integration. The developers, for instance, take product requirements and develop the code for it.

Quality — An Integral Part of Continuous Integration

What does this mean?

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

By integrating regularly, you can detect errors quickly, and locate them more easily.

What actions should you take?

Even though the CI process may seem very development centric, it’s vital for QA engineers to get an overall picture and adapt accordingly. As a QA, one should make sure the automated tests are a part of the deployment cycle of the application to keep a continuous check on the application quality.

Adding the automation test suite as part of pipeline to run for every check-in done by Developers will give the confidence to go ahead for the release and also helps in getting faster feedback for the features.

Thanks for reading the blog, if you liked it then give a clap and share among your friends and colleagues and Do share your feedback if you have any suggestions.🙂

Senior Quality Analyst @Thoughtworks