Software testing is a process that guarantees our software will work flawlessly in the end-user’s device. A responsible job perhaps. But, can you always be sure about it? Not finding a bug does not mean that bug does not exist in the software. It may or may not be that case and honestly, no one can predict this. Hence we give the names of production bugs and post-production bugs to those ones that seep beneath the armour shield of software testing. This only makes our assumptions stronger that 100% fail-proof software cannot be guaranteed.
So, can we just run the regression tests and data-driven tests and push the software ahead for production? Production bugs are often described as bugs that cost 100 times more money to us than normal pre-production bugs. The following graph is analyzed for a similar phenomenon by NIST.
All of this indicates that we should always thrive for the continuous betterment of the software testing process and methods for minimum bugs. If our testing is effective, we can bring down the hidden bugs and minimize the costs of SDLC. This post refers to a few points in the same direction and explores the areas that can be taken care of while optimizing our software testing processes.
Plan before testing
As tempting as it is to just jump and start writing test cases, we need to understand that testing is just like any other phase of software development or maybe any phase in any domain. It needs planning and distribution of methods so precise that when you set your hands to write some code, you have a clear vision around it.
Planning in testing is often accompanied by a document called a test plan document. This document creates a skeletal structure for testers to be clear in what they are going to do and how they are going to do it before pushing to production. It may include your objectives that shape your thinking in testing, strategy to follow, resources required, schedule for each phase and anything else that you may feel necessary.
It is important to remember that since each testing phase will require planning, testers should not copy the previous plans and start testing with the same. Each project is different in its own way and a wrong test plan can overturn your complete test outcomes. Test plan documents work as a reference frequently in the software testing process. The methods and goals described can help create test cases faster and software testing more efficient.
Communicate Communicate and Communicate
In my personal experience working with organisations, I have found how important communication is not only within teams but across them too. Although communication helps in a lot of factors, the main goal is to clarify your product inside out. You can never test your product efficiently if you do not know the functionalities and the goal it is trying to achieve in the market.
The primary thing to keep note of is to be always in touch with developers to know even the slightest of hidden features. What would happen if you start testing but without full knowledge and later come to know that exact feature had a bug in it that you never knew about.
Apart from the development team, it is also advisable to keep all the stakeholders and analysts in the loop to verify whether you are moving in the correct direction. What you may think is “it does not work” may be a planned feature for the future. Software testing becomes highly efficient with communication. It will also help you spend more time in testing rather than resolving issues and replying to emails. The result is fast delivery of applications.
Know your audience
Recently while going through various case studies, I encountered one interesting case. A Taiwan based user encountered an issue while making the payment through a web application. Her last name had only 2 alphabets while the application had criteria of a minimum of 3 letters before progressing towards transaction. Since it was a mandatory field she could not make payment on the application and also raised the issue on Twitter and LinkedIn.
This is an interesting case to follow. The feature works fine, the servers work fine, the code works fine but the app was not ready for this audience. Where your application is being accessed plays a major role in testing. Every geographical area provides unique challenges and making our test data accordingly will never let this happen. Since such bugs can seep into post-production, they will cost much more as the development part is also associated here. Not to mention the bad publicity the company has to go through on public mediums.
Choose a complete tool
The definition of a complete tool is different in different projects and for different testers. Some testers like to stay in their familiar programming language and aim for a tool that supports it. Some projects are based on real-time monitoring events and therefore aim to test them on real devices for better analysis.
While it may take a lot of time to experience different tools and settle down on one, let me guide you towards one tool that you can try and will possibly like as much as I do.
HeadSpin is a testing platform that is more inclined towards performance than “just rendering” the application on various screens. For this, the platform provides real devices located all around the world so that you are not getting inaccurate results from emulators and simulators. Along with smooth cross-browser testing and mobile app testing, Headspin comes with mobile automation testing for iOS and Android devices. Finally, when you are done, you get visually appealing and informative reports that are easily understandable by people not related to the project’s technicalities such as stakeholders.
For efficient software testing, a complete tool is a must. It can help you save a lot of time and deliver products faster than ever. Headspin can help you collaborate in an exciting and interactive environment made just for people who want to deliver quality software.
Use shift left testing if possible
The traditional SDLC methods start with planning, development, testing and then production. If we take into account the amount of testing done with respect to time in software development, we get the following graph:
The observation confirms that most of the testing processes are done in the later stage of development. With the “shift-left” term what we exactly mean is to shift this bell curve towards the left side. In technical terms, it means to start most of our testing in the initial states of software development.
Someone who is habitual of testing in the later stages may find it a bit strange. But shift-left testing is quickly picking up and helps in efficient software testing. It comes with the following advantages:
- Shift-left helps in finding the bugs early in the system. This reduces the costs at later stages.
- Early bugs are very easy to resolve and hence the overall time to delivery can be reduced.
- Early bugs can help reduce the pile-up that gives birth to complex and inter-dependent issues that takes more time and costs in development.
- Increases communication cycles between various departments in early phases.
- Widens the test coverage process.
The shift left model generates the following test graph
With that being said, it is to remember that shift-left testing is not always necessary. It depends on the project and scenarios that as a tester you need to figure out. If you can figure this out effectively, you will be able to test the software more efficiently.
Give a change to exploratory testing
When we perform automated testing or scripted testing, we are bound by certain rules, pre-requisites, protocols etc. This does not give a change to the tester for exploration of the software and bounds him with constraints. Exploratory testing is used for just that.
With exploratory testing, the tester is independent to test the software without knowing the answers beforehand as in automated testing. It allows the tester to discover new possibilities of software failure and can be used with automation in future versions.
Think like a user not like a tester
Testers are engineers and engineers tend to think technically in their work. However, when we think technically, we write our scripts with the same approach in the back of our minds. “Ah! Nobody would click this button, it’s clearly mentioned below as a note.” This is alright except for one thing – the majority of your users are not so technical.
When we think in ways like “this won’t happen”, we lose on software quality at this point. Whatever you see on the website, can be clicked, accessed and entered on the application. Even if the input box placeholder says “Minimum 8 characters”, you will find users entering fewer than that. If appropriate validations are not taken care of by the development team and the testers also pass it through, this could lead to serious problems in the future. Therefore, always think like a user in the testing phase.
Usability testing can open new ways
To increase the software quality and add another layer of software testing on the application, it is advisable to take help from people outside your organisation. If your application is going to be public for everyone rather than internal, it is better to hire a few users that can test your application as an end-user.
In this aspect, you can approach two types of users:
- Those who are from the same field that the application is about.
- Those who are from a different field than the application is about.
Both of these users can explore each angle from the end-user’s point of view and thereby helping you perform software testing more efficiently.
Document everything
Finally, to improve your software testing methods, start documenting everything that you have been doing, planning to do or is in the pipeline. Documentation may not feel to you appropriate as of now because as you are interacting with the app every day, you know everything. This is the reason a lot of the testers take documentation for granted. But conversely, documentation helps in improving software testing in many ways. The following can be served as a few examples:
- Documentation suffices everything at a single place for other teams.
- Software testing documentation helps in inter-team communication.
- Documentations can help new employees understand the ongoing process for an application very easily.
- Writing documentation can make your understanding even clearer.
- Documentations also serves very well as a reference for future projects.
What’s your method?
Software testing is not some textbook fixed method that can be followed and done in a straightforward way. Honestly, each project is different and poses unique challenges that are hard to predict. But that does not mean we can’t hunt down the hidden bugs and improve from our side. If we do our work effectively from all angles, we can achieve a high success rate and very few production bugs.
This post tried to explore nine such methods from diverse areas that can be used in each project. I hope it will help you improve your existing software testing methods and work as a reference in your next project. If you have any such ideas, do let us know in the comment section.
