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.
With the landscape now clear, let us explore how the majority of the folks make it hard to teach software testing to the interested.
Test your website or web app online for iOS browser compatibility. Perform seamless cross browser testing on the latest iPhone Simulator. Try for free!
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.
Upload your app for testing within seconds using the LambdaTest cloud and perform mobile app testing right away. Find bugs early on, improve performance, quality, user experience and make the most of mobile app test on LambdaTest.
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?
Try an online Selenium testing Grid to run your browser automation testing scripts. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free! __
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:
Pay attention to users
Work with the programmers and other stakeholders
Testing is more than pass/fail. Focus on — is there a problem here?
Know the systems and interactions.
Pay attention to context and get better at reporting, story telling on what you discover.