Jumping to the exploratory test

Testing is included as a step of the software development life cycle(SDLC) and all of the testing phases. So, will leaving that much give you high quality? Apart from the acceptance criteria, there are many subjects that you can test in SDLC, and the most important of them is to do exploratory testing on your application from the perspective of the end user.

As a tester, you are all aware that one of your responsibilities is to reduce costs by starting the test as early as you can. And mostly, if any issue happens on the production side, you can feel the first point of contact and the person to blame is you. For this reason, sometimes you need to steal or have a mindset like business analysts, product owners, developers, or designers.

You tested the acceptance criteria to see if it was well implemented as mentioned in the ticket description. And you can think my job is done, but as a qualified engineer tester, your job is a never-ending process because you are not responsible only for the ticket. It’s your turn in the software development lifecycle, and now it’s time to test the developed feature with a comprehensive approach. Of course, you first checked if the actual result met the acceptance criteria and didn’t find any bugs.

Exploratory testing after the ticket testing

From a tester’s perspective, I am doing exploratory tests to increase product quality and be safer. In this context, ISTQB has made the following definition for the exploratory test. But I want to expand the subject a little more.

“An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.” the definition was made by ISTQB for the Exploratory Testing.

I want to mention a definition, ticket tester. What is a ticket tester? A ticket tester is a tester who only reads the ticket description and confirms the criteria. Think like that: a new button is added to the front end -sounds too easy to test, right? It should redirect to the new page. On the ticket description, acceptance criteria only ask if the redirection is working. But is it all? Absolutely no. Because, most probably, you are not working only on these simple domains; in fact, there can be a lot of dependencies on developing this button. As a quality engineer, you should think out of the box. Are you ready to go deeper?

With a designing test glance, execute exploratory testing

From a design perspective, there are a lot of dependencies that testers can not be aware of with the naked eye. The same button can be used in different places, and when a slight design change for the actual acceptance criteria can be reflected in various places as a design blocker. If there is good documentation and use of the design libraries like Figma or Storybook, it can be easier to find other dependencies that use different areas. However, sometimes these tools can be bypassed in the agile development life cycle. A tester is not a designer, just as a designer is not a tester. But as I mentioned before, QA steals many roles from the people on the development life cycle. It is time to start displaying a comprehensive approach with domain knowledge. Exploratory testing should begin at this time with sound domain knowledge. In the system that you have tested many times before, you should demonstrate your ability by diving deep into the relationships of new design changes with each other. You can create a mind map for this. It can be helpful for finding design bugs that use the same components in different areas.

Jumping from regression results to exploratory testing

Sometimes the automation testers think like a developer -sure, it is not a bad- and they only develop regression frameworks or refactor the test defects. They are losing their primary responsibility related to quality, and more than looking at the CTA, operability is needed to maintain the quality. Another dilemma for the testers is the responsibility of finding bugs, defects, or errors with the regression tests. Investigating regression results is a perfect time to increase the domain knowledge for both Manual and Automation testers and find some uncovered areas or catch bugs that freely walk on the product. For example, when a test automation engineer refactors something that needs fixing, you can do exploratory testing. This will increase your domain knowledge and help to find bugs. You need to always consider the gray areas for catching.

Last subject with the static tests Time to exploratory

So far, I have recommended an exploratory test by examining the design and regression reports. We can add these tests to the static tests that can be done on the document test. Although testing on documents may seem tedious, it will help to reduce costs by catching errors at an earlier stage. Another point of static testing is that it will give you a vital ability to carry you to the next step, the quality manager position.

Yes, it is time for exploratory testing. The aim of exploratory testing can be to find the actual results that differ from the expected results. But from my perspective, the essential aspect of exploratory testing is that I will achieve good domain knowledge when I spend time surfing on the domain or product. This is a precious accumulation that, with ease, reaches domain knowledge. Of course, you can understand it from documentation or some test cases on the domain, but it is like reading a soccer game book without touching the ball.

Time management is an essential key for exploratory testing. It would be best if you kept yourself in the vast domain, and it might create a document with exploratory testing. The product of Exploratory testing may be a bug, but if you do not encounter a bug, a well-prepared report as a product will be great. This report will be a good handbook for you to consult later or for those who will join the team later. It can sound crazy, but you need to follow some ways with exploratory testing. Exploratory testing is not driving a car with closed eyes.

Look at the big puzzle. You only have a little time to execute exploratory testing. With the sprint tickets, you can spread over the entire domain. Slowly you can understand the domain well and increase your bug-hunting ability. In my post, I have tried to explain that the exploratory test should not be random and that it is a particular test type for the team and you. This type of test for us will increase domain knowledge and enable you to find errors. It can take time, but after 2–3 months, you will become the most wanted and valuable person in the team.

As quality assurance engineers, you should remember that your role is devil’s advocate.

And it is time to do an exploratory test…

Follow on LinkedIn

And follow on Medium