This is part one of a two-part series. Achieving excellence in continuous testing is not just about mastering all the new tools, programming languages, and frameworks. It involves developing a deep understanding of the product you are testing. What follows are some tips that can help.
I think a lot about what it takes to be a good tester. When I look at industry trends, I observe that the software test community is obsessed with the tools, programming languages, applications, frameworks, and processes.
There is a mad rush. Everyone wants to learn everything. Did we forget that tools, applications, frameworks, etc. are merely an aid that helps us do our tasks better and faster?
We all love to learn a new skill that is in demand for a continuous testing role so that we can keep ourselves up-to-date. We feel good about learning something new, and it also adds to our skills that we can put in the tools and applications section of our resume.
But, are we losing our focus on the very basic principles which are essential for our growth in our professional lives? Are we compromising somewhere? Can we do something better?
Product Expertise Is the Secret to Success
Of course, we all must keep learning all the time. But in our day-to-day rush, we sometimes don’t put much attention into learning about the software product we’re assigned to test. Why?
Because, just like anything, we’re more driven by market pressures than by values. The typical thought process is that “what the product does” won’t be asked in a job interview and knowing what the product does won't be relevant in our daily lives once we leave our current company.
So why waste time learning about the software product? Many testers think, especially those who are new to the industry, that they only need a basic knowledge of the product and instead focus on acquiring popular new skills.
We may be very good in the field of testing, finding defects, and writing use cases and test cases. We may also be process-oriented, and good in programming with excellent automation skills, but if we don’t know the software product that we are testing well and if we don’t know what business needs it serves, we are fooling ourselves.
The secret to success is not knowing everything the industry demands, but being good at one thing – the software product. In my experience, the people who know the software product well are more trusted and respected in the company and have higher chances of career growth than others.
How should you go about it?
When we say knowing the software product well is a key thing, what does that mean? It is a big subject in itself, and if you are serious about it, it may take several months to have that level of command over it. I will dissect that further for you here so that by the end of this article, you are better equipped and hit the right areas after you come to your desk for work.
Begin with the End in Mind
It’s often said to “begin with the end in mind”, and this saying applies here. We must broaden our perspective from a technical (positive test score) to a business (value provided to the customer) context. We should also consider answers to the following questions:
- How do my customers use our product?
- What value do they gain from using it?
- What revenue impact do our app and the functionality being tested have on our company?
- Will this new product version improve revenue or protect revenue?
- Is there any similar product in the market, and what extra and good features does it have that could improve customer usage and adoption?
Know the Ins and Outs of the Product
As test engineers, we focus on our key areas of work, which are limited to one set of features. This focus takes us away from looking at the product from the customer needs that drive features and the system perspective overall, and hence our ability to comprehend the product is limited. We aren’t aware of the critical features the product has. We build and test more effectively if we learn both critical and non-critical features and that makes us more aware of what effect a code change will have elsewhere – a win-win situation for both developers and testers.
Master the Product’s Architecture
As already pointed out in the previous point, a system-level understanding is of paramount importance while building a product. With that in mind, it’s important to thoroughly understand the technical architecture of the software product, understand how each microservice and component interact, how the data flows, why a particular technology was used versus others available in the market, etc. This top-down approach provides a broader picture of the system and how a change in design and technology will have a ripple effect on other components inside the product.
Take a Bottoms-up Approach
Do you know which components (or microservices) in your product give the customer the intended function? Do you know the functionality of those components? Are they loosely or tightly coupled? Can I build a driver to pass input to one and bypass another? This bottom-up approach starts from individual components and helps you understand how integration produces the overall solution for the customer.
Learn from Breaking Things
No software product can be 100% defect-free. No matter the coverage of our testing efforts, some defects will remain in the product forever. Often the business cost to fix some defects doesn’t justify fixing them; hence they get filed as known issues.
It’s often said that to learn a product, learn what it does in error conditions –provide out-of-range values, throttle its input with large values, remove underlying files from the file system, or change its configuration beyond recognition. Though many of these use cases wouldn’t occur too often in the real world, going through this exercise will help you better predict what a user may have done to bring up a particular error state.
Bend but Don't Break
Do you know how your product would behave when the CPU or memory reaches more than 90%? What will happen when database connections reach the maximum? Is the system able to handle it? Is it able to recover? How long does it take to recover after a failover? Does it send notifications on failure?
While functional features are important to understand, it goes beyond saying that understanding the non-functional features and the system’s behavior in such conditions can provide you a commanding understanding of the product. Have you ever come across a defect that helped you understand the limitations of your product?
I recently faced this when one component in the product I was testing was incrementally adding to the database connections every time I visited that through the UI, and over time, it reached the maximum. Of course, it made the application inaccessible and so had to be resolved. However, my learning here was that even when I moved to another UI component and left it idle, the connections were not getting auto-released due to inactivity.
Part two of this post will continue to discuss tips that can help you gain a deeper understanding of the product you are testing.
In the meantime, learn more about continuous testing at Broadcom Software Academy.