The first principles of ‘Testing’

By Gaurav Singh

I’ve been working as a tester throughout my career. I’ve always been intrigued by the unique breed of individuals testers typically are. We are called by so many different titles (QA, Quality engineer, tester, SDET… and so on) and we play so many different roles within a products’ life cycle — whether it’s being a coder, testing an app from different layers, product and systems thinker, agile coach etc.

Throughout this journey I have observed some practices, aspects/qualities which in my experience form the core of testing as a skill.

In this post I wanted to share my thoughts on what are some of the First principles in testing which every new budding/experienced tester should definitely be aware of or follow:

Testing is almost always exploratory in nature.

This is probably the most important thing to grasp, and at its heart, is the essence of testing. We can come up with elaborate test plans and thousands of automated scripts/cases, but some of the best scenarios and bugs in the app under test are usually identified when the tester is able to wear different thinking hats and explore the functionality from different contexts.

Always be curious and never agree when a developer says something will “work” just fine and does not need testing🤔

Know your product and its customers.

As a person working in quality, the common expectation from us is to typically wear your customers’ shoes and understand a user’s journey.

In this day and age, understanding how customers are using the app and collection and analysis of data to grasp what is of real value to the customer can be the difference between success vs losing customers to a competitor’s product. We should challenge ourselves to rise above just checking functionality, but rather to think about flows E2E from different perspectives to eventually maximize business impact.

Happy paths and test prioritization

Now this might be stating the obvious, but one of the important goals to strive for is to ensure your apps’ happy paths are never broken in production. Also, learn to prioritize the test cases based on the context in which it is being tested. We always need to have an intelligent suite of tests which can be run to get fast feedback about the health of the app before pushing it to customers.

Bug hunter?

No app is perfect and there are always bugs to be found if you are curious enough to dig through different layers of the stack (API, integration, network or database). Challenge yourself to really understand how the systems’ you test, work under the hood. What are the nuts and bolts, and most importantly, areas where testing is not being done. 😎

Understand different aspects of testing

A testers’ ability to come up with great test cases are mostly proportional to the amount of knowledge about the product, and how critically the individual thinks. As a quality coach, we should know at what different layers testing can be done.

Understanding how testing can be done at different levels like Functional (Blackbox, whitebox, UI, API), Unit/Component tests, Integration) Non Functional, (Security, Performance, Accessibility, Compliance, Usability) automatically enhances the chances of designing a more robust test plan.

Automate the boring repetitive stuff

Let’s admit it, no one likes the boring stuff. 🤷‍ Tests typically follow simple patterns at its core — like input, execute and assert. Unless you are a 🤖, one would NOT like to repeat the same cases on every new build that is churned in your CI (Continuous integration) pipelines. Hence the dumb advice:

Automate the repetitive stuff and let machines do the stuff they are good at.

Focus more on exploring unknowns in and using creativity or out of the box thinking is what ultimately adds most value to a product.

Don’t automate everything

Most managers and product stakeholders like to chase the ever elusive metric of 100% automation. However i urge you, do not fall into this trap. Automate areas where maximum value can be derived. As an example, try to cover most functional behaviors through API tests, instead of having an endless battery of failing UI tests.

Write Good documenting test cases

Just like cleaning code is important to ensure we don’t leave a mess behind for the person who comes after you. As a tester, it is quite important to ensure tests remain relevant and meaningful.

Shift left

Shift left and try to be part of the entire SDLC. You would be surprised how many times a tester can catch gaps in requirements analysis and help developers deliver a much more quality products by being involved early in the process.

Learn to code

Learn to code in at least a static and/or dynamic language. Learn the craft of programming and refactoring. Not only would you be able to automate stuff, this can potentially even help to shift in a grey box test role where you can understand gaps with dev code commits. Plus the most important reason for this is: It’s way more fun… 😉

And… That’s a wrap folks.

What do you think of the above? Do you have more thoughts to add? Let me know in the comments section below. If you found this useful, please do share it. And yes, we’re hiring. We’re always hiring. 200 empty seats for the taking 😝 Grab the chance to work with Southeast Asia’s hottest startup. 🔥. Check out gojek.jobs for more.