Five practical ways to get better at software testing

Can you teach me Software Testing?

It is one of the simplest questions to answer and the toughest to execute. Let us find out why. There is no one governing authority in the field of software testing. Everyone has their own way of defining and performing software testing. Some think of software testing as a pure play-act of verification, and validation against documented requirements, and few others treat it as an investigative journey filled with exploration and experimentation. The end goal is ideally to get quality-related information to the stakeholders so that they can make informed decisions.

Software testing will remain an essential aspect of software development, and the demand for skilled software testers will keep increasing daily to ensure that the software performs as intended and meets the end user’s expectations. Hence, software testers must acquire new skills and get insights on the latest trends that can be acquired through software testing YouTube channels.

With the landscape now clear, let us explore how the majority of the folks make it hard to teach software testing to the interested.

Understanding the Users

Testing is done on products  —  to be used by people and developed by people. The focus, sadly, is limited to the products and that hurts. Software testing doesn’t start or end with the product alone. Unless you also focus on the customers, the people who are involved in designing and building the product, you will lose out on valuable dimensions of software testing. How many people emphasize on customers and teams as much as they focus on the product? Think about it.

Every product is intended to solve a problem. If the problem is not solved, the product and project are wasted. Imagine knowing about the product in detail without knowing about the context. Sadly, it happens with many trainers and learners. Learn about the context too. Understand who uses the product. To help end users, it helps to know about them — their motives, likes, dislikes, behavior patterns, biases, current way of solving problems, and more.

Talk to the other Stakeholders

Spend a day or two with the customer support teams of your products. You will discover how hard some of the features are for the users. You may also get a chance to observe trends in how the same problem is faced by many customers. What seemed straightforward to you might not be obvious for everyone. Also, understand how people have their own ways of using the product and sometimes might get used to a bug that they get irritated when you fix the bug (true story 😀 )

Sales and marketing teams are also good sources of information about the product. See how they sell the features of the product. Understand the claims made by these teams. Are the sales scripts updated? Are they using the product the right way — the intended way? Be prepared for surprises! Note down the questions asked by the customers too. They become your test ideas or feature requests for next sprints.

Discuss with the Programmers

Also, focus on who builds the product. Their intentions, patterns, limitations, pressures, past records and fatigue. When you know a lot about the way products are built, it is easier to predict and tie the loose ends quickly, saving time and focusing on bigger issues. There are many tradeoffs made by programmers on a day-to-day basis. Most of them are not documented. Talk to the programmers to understand what difficulties they face — not necessarily in a formal meeting space. Ask them about the riskiest code, well-tested code and in general — what are they worried about the most. Get the information and continue to apply the testing lens even on that information. Test it out.

The Map is not the Territory

Many focus on testing as a pass/fail, algorithmic, testcase-driven, automated coverage-driven scripting problem only to be surprised by the real world, emotion-driven, user-centric usage patterns combined with innumerable combinations and real-life scenarios. When was the last time you read the user guide of a product or followed step-by-step instructions to discover a new product? Have you seen a kid enjoy the discovery process?

Testing is supposed to be on similar lines with a little more (but not rigid enough) structure in the process. As much as you would like to confirm that certain things are working as expected, be sure to equally explore the possibilities of what if and what would happen when you deviate from the script. Your role as a tester is to get the information — does the product do what it is supposed to do, does the product NOT do anything odd that harms the reputation of the product/company, is there anything that is a RED flag and needs to be highlighted?

Get better at Reporting and Storytelling

Investigation is hard, especially when it’s done in a totally random manner, with no attention to context and done without knowledge of systems at play. And even when good evidence is presented in a poor manner, you have very few takers. So, in addition to getting the information from multiple stakeholders, using the product, investigating the issues, it is time to get better at reporting and storytelling. We can learn a lot from news reporters — how to convey most of the information in a coherent manner without repeating ourselves.

To Summarize:

1. Pay attention to users
2. Work with the programmers and other stakeholders
3. Testing is more than pass/fail. Focus on— is there a problem here?
4. Know the systems and interactions.
5. Pay attention to context and get better at reporting, story telling on what you discover.