Among many test techniques that are out there in Software QA discipline, Pair Testing has been a long-standing technique used by Quality Engineers to track and verify issues. But due to how it’s practised and the time constraints, pair testing tends to be left out. Knowing when to use Pair testing will enable you to identify issues that need to be fixed and it will save time and resources.
As stated in the profesionalqa.com website, Pair testing refers to the technique which involves two members using a single workstation to test different aspects of a software application. Who’s going to be in the pair now? Well, that depends on the testing requirements. It can be two Quality Engineers, a BA and a Quality Engineer, a Developer, and a Quality Engineer, etc. The bottom line is that an exercise of pair testing should provide an effective output in test execution and finding defects compared to normal test execution. Hence, the question arises “How am I going to get the maximum out of it?”
To do this, here’s a list of criteria which can be followed to assess the capability of conducting Pair testing
Is it worth the effort to start things off?
Pair testing is effective when used to verify a complex or broad set of functionality in the application. If you’re going to test a feature that has very straight forward functionality there won’t be a big requirement to conduct pair testing. For example, user login for a goods delivery application is better tested by one person. But if there’s the feature to track delivered goods, that feature itself has the potential to do pair testing due to the different selection criteria a user will have to enter to get the desired result.
Is the time with you OR against you?
Though there may be content/features to pair test, it’s important to look at the time available to conduct pair testing before you decide to get started. Based on the time constraints of the project, it may not be feasible to allocate time to conduct a pair testing session since you have to give priority to individual test execution. We are utilizing another person’s time so it should be a responsible decision towards making it a productive pair test session. The ideal approach would be to talk to your project manager and come to a decision on going ahead with pair testing.
Choose the right person to Pair Test with
It takes two to tango but the performance depends on how good your partner is. If you’re to do pair testing, you need to make sure you’re doing it with the right person next to you. Because our goal is to make sure the feature is working according to the requirement. And depending on the situation the person whom you’re conducting pair testing has to change. If you’re to have a pair test session at the end of a sprint, doing it with one of the main developers would benefit in finding any issues. If you’re to test a part with more integrated components, perhaps doing it with your BA or your product manager would result in a better output on identifying issues.
Identify your observation criteria
Pair testing is not there only to detect bugs. You can use pair testing to Identify issues that may obstruct the intended user requirement. Identifying UX improvements can be done effectively with the use of pair testing. It helps the Quality Engineer to get a better understanding of aspects that he or she may haven’t looked at among all possible viewpoints of an application feature.
Defect verification? Pair Testing to the rescue!
When you have a list of defects to be verified, doing it in pair testing will save you some time and effort in communicating. This is most effective when the defect list is fixed for one or two developers because getting them paired up for the testing will allow you to verify your test inputs and possible edge cases for that defect. If the defect still exists, the developer is aware then and there. This saves time in reporting a reopened issue and perhaps it may be resolved at the moment itself saving time on another defect verification cycle.
Pair testing can help project teams utilize their time and resources in a collaborative manner to help build the quality of an application. But it’s the responsibility of the Quality Engineer to identify feasibility on how to use it with the support of other project team members. This in return, will ensure a significant improvement in the overall quality of the application.
When I joined the IT industry back in 2013, Software Quality assurance was a stable knowledge domain and the Job Description consisted of tasks, which provided opportunity and expectation of a good career as a QA engineer. Over the course of just 4 years’ time, Software QA has become a domain that is equally technical, challenging, and competitive.
It was writing a set of test cases and executing them manually in the beginning; now it’s an automated process at times thanks to some flexible automation frameworks and platforms. There are so much of theoretical and technical knowledge, which allows QA engineers to provide a better output in terms of the quality of the tested Software.
So with all these insights, practices and with the fact that it continues to grow, we come to one common thought: “What would the future be like for QA?”
With the new advancements and applications that comes to the present picture of reality, QA engineers have to adopt and come up with equally new methods to measure the quality of hardware and software applications. There are leading software QA bodies, which has gone the distance to predict what new trends and techniques might come into play in the future. Let’s take a couple of such predictions and allow me to provide you in with my own insight on the QA domain and where things are headed.
When conducting software testing, it becomes important for the Quality Engineers to be domain specific about the application they are testing for. Back then the focus was only on the business case and the requirements related for that particular application. But what about checking the good use of UI? Does it provide a Good UX? Is the application secure enough? Such questions arise with the expansion of these sub-domains. So let’s dwell on these points. For the purpose of this article, I’ll be focusing only on two domains for which I have been part of a focus group.
A lot of the new and emerging technologies have started to adopt APIs to make their applications and devices perform with greater effect. This makes it robust for the external communities to make good use of them if they are going open source. But all in all to provide the world an effective solution, The API should be of top level. Hence there will be a lot of focus on API testing. Handling complex requests and responses requires a good stable API and QA engineers will have to undertake the task of verifying the request- response validity within their test execution for the tested API. This will be the main focus while checking for the load of data, which the API can handle as well. At the same time, there will be the requirement for different test strategies to test different types of APIs (Eg: Web service APIs, Hardware APIs Library-bases APIs etc.). This will in return allow QA engineers to provide a better QA analysis, distinct to the type of API that’s been tested.
Application security has become a major concern as of recently due to the boom in online and cloud related technologies. The Open Web Application Security Project (OWASP) has identified the top 10 security risks for web applications. This in return provides an idea for what areas to look into when developing web/network applications. For the QA engineer, this provides the opportunity and a challenge to come up with ways to test for these vulnerabilities.
Adopting the mindset of an ethical hacker will be a requirement more than an advantage, if you are to specialize in security testing. Areas such as use of network protocols, data encryptions, and secured access points can become the prime focused areas for security testing as they hold the most important aspects in maintaining the security of an application. To be on the safe side, being aligned with OWASP top 10 threats would be the best move for security testing. Furthermore, the focus on cloud security could become another focused area since a lot of cloud based application development has started to increase. The future for security testing seems to have become an area for new knowledge, test strategies and tools in determining quality in web application security.
Just because the application you build has all the right features and serves the user requirement, it would not make it a good application IF there are performance related issues. As stated in guru99 the primary focused areas on testing for the performance testing are:
To cover these areas, there are test types such as load testing, stress testing, spike testing etc. Test execution based on these test types has become essential due to the heavy data loads and complex features built and will further evolve to provide a comprehensive test result on the performance of the application. The more complex it gets, the more impact on performance. And by the looks of it, it’s heading towards the complex end. Testing should focus more towards checking the overall performance of the application rather than checking at the component level.
At the moment, the number of tools, which provide support on performance testing will have to evolve further to provide features that can provide much detailed results due to the complexity of applications related to different technologies. Due to these events, there will be a lot of room for exploring for a Performance Test Engineer in the future and many ways to contribute in return to the QA community.
The UI and UX design for applications is considered to be a huge deal at the current context of software design. The right interface design and an equally effective user experience will make the application a success beyond expected since UI and UX targets the user’s mindset. Unlike back then, creating a UI fit for the stated requirements would not be enough. So how will a QA Engineer would get opportunities in this area in the future? On a broader level, they’ll have to make sure the right UI/UX concepts were used in creating the interface and provide feedback on the effectiveness of User Experience by using different techniques.
Applications under different UI\UX concepts such as Augmented Reality, Virtual Reality and Holographic Technologies will have their own methods to test the quality in UI/UX. Thus it would benefit everyone from target users to UI Engineers, when feedback provided would be specific to each technology the application based upon.
The future will have a strong connection between the QA Engineers and the Target Users since QA Engineers will have to spend more time in getting user feedback and relay it back for UI/UX Engineers to improve the design further. The importance of Accessibility level testing too would have to be looked into as a sub category when considering the differently abled people who would be using the application or the device
Test execution comes down to all the effort put by the QA Engineers to design and create test cases to be executed once the developers release their part at the end. But of course we always search for ways to get the job done with less time spent and Automation has been around to help us all on that.
Most of the regression level executions and other time consuming test executions are implemented onto automated test executions as it reduces the amount of time spent compared to manual testing. And furthermore different automation frameworks have been created in commercial and open source level.
With the introduction of different programming technologies, automation frameworks will have to evolve to test these applications. With many areas coming into the picture for the QA engineers to look into, time becomes a critical factor and automating test executions can help save time and bring focus towards other areas, which require manual effort to test the applications.
Automation IDE’s can become a key thing to look forward to in the future. Similar to the programming IDE’s we use today, the focus of Automation IDE’s would be to make it easy for the Automation Engineers to build automation test suits with the use of controls similar to Programming IDE’s but focused towards efficient test case creation.
As a result, on a different note, one might have the question whether all this would have a negative effect on the role of QA engineers. Will the whole process of manual testing go away? Would testing become another developer’s job thanks to automation? Well not exactly. Couple of reasons are:
Automation is done to reduce time on a long term basis.
It’s most suitable to apply automation for test executions, which would happen for a long period of time (Regression suits mostly)
It’s not practical to automate every test scenario due to the technological constraints brought about by different domains.
There are many other reasons to be spoken with support for manual testing, which can be the focus of an entirely different article. But the main take from this is that manual testing will continue to be part of Software Quality Assurance considering where everything is heading in the future.
Software Quality Assurance is seemingly becoming even more complex and interwoven with many other disciplines. The demand for high quality is at an all-time high and with the right set of skills, the QA Engineer will play a leading role going forward.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.