In the season 9 episode of The Simpsons “Lisa, the Skeptic” Moe questions Lisa asks her “If you’re so sure what it ain’t, how about telling us what it am”. In this blog telling you “what it am” is a central tenant of how we share our thoughts and ideas about web and mobile app testing.
Today, however, I’d like to take a bit of a different tactic because we always tell you what things are. Let’s take a look at what automated testing is not. Hopefully, this will give us a different perspective on how we view testing. It is always easier to describe what something is over describing what something is not. So Let’s dive in and I will show you what I mean.
Testing is not Optional
Full stop. You have to test your apps before releasing them. If you do not then your users will do it for you. This will come in the form of poor rankings on app stores. Accompanied, no doubt by some very upsetting and public comments at your expense. Small upside, they might be pretty funny, but that’s not what you want.
In 2020 it seems more difficult than ever to do without a process for app quality control. It begs for the necessity of an end-to-end development and testing process. Another reason why testing is not optional is because app testing gives your developers the ability to discover bugs, network, and performance issues earlier in the process.
It is equally important to note that functional testing not optional. Neither is network or performance testing. Sure your app might work flawlessly on a specific network and a specific device. Without fully expanding that testing to include different mobile networks, and monitoring of device vitals.
Another aspect of testing that makes it non-optional is that testing allows you to put yourself into the shoes of an end-user and make sure that the App’s UX is fantastic in both look and feel. The ability to test this way gives your testers the ability to feel what a user feels when interacting with your app and will help your teams predict if users will continue using your app or abandon it.
From the developer viewpoint, code is written to be prescriptive. Developers use whatever language they are coding in to describe the steps they want an app to take when completing tasks, in as exact language as possible. An implementation is about the best way to accomplish something at any given point. When developers commit that code to the larger development project they assume that the code will function as programmed. We know from experience however that this is not always the case.
That is why testing is so important. It takes the process of development from the prescriptive world and brings it to something that is more descriptive. testing is not optional because you need to test your code by examining what it does on a practical level. The way you do this is with tests that describe what your code does instead of describing how it does it.
Testing is not Responsible for Quality on its own
Your QA teams might be highly involved in testing an app. Testing is not the sole way that they ensure an app’s quality. Broadly speaking Quality Assurance combines methods and activities to make sure that web and mobile apps function as intended. While QA involves themselves in the process of working to identify correct and prevent bugs in an application they also interact with the management level of app development. This includes methodologies, development techniques, and analysis. Quality comes from more than testing alone. QA teams busy themselves with the process of software maintenance through the entire SDLC.
Testing teams evaluate the design, compatibility, function, and performance of web and mobile apps. QA teams on the other hand focus more on the production process. So it is not testing alone but rather a collaboration between the two with a combined focus on software quality. This collaboration is essential to make sure that the apps you release are both functional and perform with reliability.
The ideal way in which the relationship between Testing and QA should work is with QA staying a step ahead of the testers. Then when testers report each detail of their testing QA will be able to analyze it and actualize the changes. This should not put a false sense of superiority on QA teams. QA and testers are vital to each other, Testers need the guidance provided by QA and QA needs the actual results from Testers in order to provide actionable analysis.
Testing is not the tools used
It is a question we get often in our social channels. People reach out in order to ask us about careers in test automation. They ask us about learning Java and other languages. They ask about Selenium training, and they ask about what tools to use.
Testing is not only about the tools used in test execution. In fact, by focusing on specific tools or languages it means that testers are potentially limiting the value that they can bring to an organization or even to a client on a freelance basis.
Another point of this is that tools change. That which is popular today might not be popular tomorrow or in a year from now. This is especially relevant for larger organizations with siloed teams and specific software requirements. It is great to train your testers to master a specific tool but they might need to shift focus as tools change and develop.
The way to navigate this as an individual and a team is to focus on the principles and patterns that define different tools and languages. Many factors go into understanding if a specific tool or language is good for your project.
- The language used to build and deploy the app you are testing
- The types of tests that you are automating
- Skill and language levels of your testers
- What tools are used elsewhere in your company and which are under contract
So the tool does not matter. What matters are the foundations of these tools and languages. If you and your team study patterns and principles instead of the tools themselves your testing value and versatility will improve.
Testing is not always appreciated by all
It seems like the top managers in companies consistently underestimate web and mobile app testers. This is not a new development either. Where large companies like Amazon and Google place value on their testers even going so far as to call them Test Engineers smaller companies often axe their testers first when faced with some development challenges.
It is true that Automation Engineers do not write the code they are testing. They do write tests that determine the quality of the app. It is not that the code written by Automation Engineers is designed the way that software engineers do it but their automation tests impact the developers’ work as well as the app’s overall stability.
Automation engineers deserve more appreciation because they write smoke and regression tests while interacting with the latest code pushes from developers. Where developers are treated in some cases like rock stars testers are more like producers. They make sure that the developers’ work functions, performs and looks good.
What Testing is
As we can see from the examples listed above. Testing is necessary in order to release the best possible apps otherwise your users will test for you and that usually ends in poor reviews and abandonment. It is also true that testing is not responsible for QA alone. It takes a strong QA team to add value to any testing project. Testing is also more about the underlying concepts of development and release than focusing on the tools that ultimately do the job. Finally, testing should be appreciated by more business leaders and stakeholders as it is the testers’ work that makes the developers look good. For more make sure to check out our other blog posts.