This guide serves to introduce beginners in software testing to the concept, and where and when they can adopt the technique to maximize its benefits.

Pair testing buddies

Pair testing is generally done by a developer and a tester. However this isn’t the only way to do pair testing. A technical writer and a tester can be paired up to document how the software would be in the next release. A tester and the client can be paired up to recreate an error scenario that the client identified, and fix it. A solution architect and a tester can also be buddies in pair testing, which could lead to exploratory testing with respect to what if scenarios. A tester and a developer can team up to investigate odd bugs.

So basically, pair testing can be done with almost anybody in the project team, especially if it’s a Scrum project.

Where you can apply pair testing

In a Scrum project, pair testing can be done throughout the software development cycle – in one sprint or many. It can be a good learning experience for junior testers. If the business analyst needs to see how a particular feature works and identify possibilities for further enhancements, he can do pair testing.

A tester or developer who wants to investigate an odd bug or look into some issue with the application that’s becoming a problem for the client, can speed things up with pair testing. In addition, almost every task directly associated to testing done by a pair from the project team may fall under pair testing even if it’s noticed to be so.

Basics of doing pair testing

Pair testing can either happen spontaneously or it can be executed with a predefined approach. For the latter, testers should begin by defining the preparation for the tests they will be doing and then plan the execution. Both parties should agree upon a time period and actively make an effort to finish testing as planned.

Spontaneous pair testing can happen in many scenarios, a common example of which would be when a tester gets stuck while looking into a problem and seeks aid from a colleague. While the partnership works with different test data, shares ideas, and explores new aspects to test, they’d also find the cause of the problem that had been bugging the tester at the beginning. This can be considered as unplanned pair testing.

Another situation is when the tester explains how a feature would work to a colleague. The colleague might have questions that didn’t occur to the tester. This is also unplanned pair testing.

Conclusion

The bottomline is that pair testing is a beneficial practice for any software development company, provided they have replaced traditional development methodologies with Agile. Making an execution plan, setting up the test environment, and ensuring that your testing buddy bought into the concept of what it is that you are testing – this is how you do pair testing. Give it a go once and see how it can speed up application testing.

Image Designed by Freepik

The post Software Testing 101: The Concept of Pair Testing Explained appeared first on Software Development Company Dubai UAE - Verbat Technologies.

An experienced tester can find patterns among all that mess, and figure out an optimal solution that will help them reorganize the testing team without much confusion.

Here is a 4 step technique that testers can follow when they enter a new, messy testing environment to get things in order.

1. Preparing an Inventory of Test Devices

This is probably the best way to start. As a new member of the team, you will be presented with a bunch of testing devices. Why not start by preparing an inventory of all the test devices your team is going to use?

While categorizing and registering the devices in the inventory, make sure to consider a few factors like the operating system used by the devices, the types of devices, and how the devices can be managed. This will make it easier for you to categorize the devices, and make the whole document available to the team for reference.

2. Creating Repository for All the Scattered Resources

Scattered resources is often a common problem in many testing teams. There would be no order. These resources may include usernames and passwords that give testers the access to whatever they require for their job, procedures to get access to those resources, information about the tools and systems used for testing, and other reference materials.

A common repository for the testing team can bring order to this chaos. The repository can be accessed and edited appropriately by everyone in the testing team. It can be kept in a common drive, say Dropbox or Google Drive. Giving access to the entire team can also help you ensure that you didn’t miss anything that should have been in the repository. This can also help new members to catch up quickly, without having to personally interview other members.

3. Testing Charters and Time-boxed Testing

There are times when the tester has to establish a testing process and start testing right after. Many testers would take a different approach, by creating a new process from scratch. This might either work or make things more complicated.

The optimal approach is to go through the existing process to get an idea of the existing resources, and then modify the process. Modifying the existing plan can be challenging as there would most likely be repetitive or outdated scripts. Nevertheless, using the existing plan as reference can make things a lot easier for the tester, and ensure a smooth transition to a new, more efficient testing process.

From what you can gather from the existing process, you will be able to create an exploratory testing charter. Your coworkers can add their test ideas to the charter. The charter should basically make the objective of each test session clear to the team. After creating the charter, the team can start performing time-boxed test sessions. Each session and their results should be observed, documented, and kept in a central repository accessible to the entire team.

4. Creating a bug template

A bug template is something that can be of great help when everyone other than testers including the developers, analysts, and stakeholders report bugs in various ways. Some of these reports might just have the user’s observation, while others might be descriptive. If there is a bug template for the team to follow, it could be easier for both the developers and testers to locate the bugs and fix them.

The template should have fields that describes the bug, describes how the bug was found, where the bug was found, the device and OS that’d been used when the bug was found, screenshots and other information that could shed more light on the bug.

The bug reports can then be easily understood by the testing team who will also be able to reproduce the bugs easily.

Conclusion

These are techniques that are meant to bring order to the testing environment by modifying processes and revising testing plans. However, it’s vitally important to figure out at what point the disorder began. Changing the processes alone won’t cover every context related to software applications testing. There should be focus on the people involved as well. Ultimately, it’s a team effort, and the steps mentioned above only serves to provide an easier way to manage the chaos in a software testing environment while making things less challenging for the testing team.

The post Managing the Chaos in Software Testing Teams While Joining a New Project appeared first on Software Development Company Dubai UAE - Verbat Technologies.