Working as a Team with QF-Test - Dos and Don'ts

Sure, a team of testers can handle extensive test projects faster and better than a single person. But some things that may seem simple at first actually can become much more difficult when working in a team.

Probably every team knows the dreaded merge conflict that arises when several people have made changes to a file at the same time that contradict each other.

Resolving such conflicts is time-consuming and error-prone, so it pays to do what you can to avoid them in the first place.

And even if you don't run into a conflict, two commits may still do the same thing in different ways, which is another way to unnecessarily complicate your project.

During the development of QF-Test, we too racked our brains on how to avoid such conflicts and built some useful tools for that directly into QF-Test. So here come some of the Dos and Don'ts of teamwork with QF-Test.

1. Don't Reinvent the Wheel

When you first start implementing your test suites, you will come across many small tasks that need to be done. But you don't have to reinvent all these things! QF-Test comes with the standard library qfs.qft, which bundles many frequently needed functions. You need to compare two numbers? qfs.check.compareTwoNumbers is your friend! Need to interact with an external database? qfs.database.executeStatement takes the boilerplate code off your hands! Send an email? qfs.utils.email.sendEmail! Reset browser cookies? qfs.browser.settings.deleteCookies! We could list many more examples, but you should just browse our library yourself.

And if you do need to invent something that's missing from qfs.qft: Start your own standard library! Collect your basic procedures in a common file and keep your team informed about new developments.

2. Don't Put Everything in One File

The number one cause of hairy merge conflicts is simultaneous editing of a file by multiple people. You will also experience this during test development with QF-Test when working in a team on a large .qft file.

Our recommendation is therefore to split up larger test suites. In our years of working with clients with test projects of varying sizes, the following basic split has proven effective:

1. One file with all basic procedures

2. One file with all windows and components

3. Individual files with test cases and procedures as needed

In order for a test suite to access components or procedures from another file, that file must be listed in the details of the "Test suite" node under "Include Files" (ideally as a relative path).

3. Import Instead of Copy

When you split your test-suites apart, you may be tempted to simply drag and drop or "Ctrl-X, Ctrl-V" your procedures and components from one suite to another. The better way is to use the import functionality from the target suite under "File" › "Import...". Now QF-Test will take care of updating all internal references correctly.

Ideally, you also create new tests this way: Start developing the new test in a completely independent temporary test-suite. After finalizing the test, import the individual parts (test cases, components, and procedures) into the corresponding existing test suites. This way, you can conveniently use, for example, the recording functionality of QF-Test without worrying about messing up your global component tree.

4. Use QF-Test Projects

When you start splitting up your suites, you will notice that QF-Test always tries to keep references to components or procedures in your suites up to date, even if the referenced object has been moved. For this to work smoothly, you should organize your files into a QF-Test Project.

To do this, select "File" › "New Project" and navigate to the root directory of your project. The .qpj file thus created represents your project, to which all files in the same directory and subdirectories belong. QF-Test will monitor the references in all files and automatically update them as needed.

As a bonus you will get a convenient overview of the files in your project in an additional sidebar in QF-Test whenever you open the associated .qpj file.

5. Talk to Each Other

Despite all efforts, no project management method or technical solution can replace the most important component of teamwork: Communication. For joint work to succeed, you need to be in regular conversation with your team members, be it at a regular standup or a random encounter at the coffee machine.

Clarify responsibilities and plan tasks so that no one gets in another's way.

Only if everyone knows approximately what the other members of the team are doing and planning can they adjust to each other and ensure, for example, that two people are not working on the same test case or even that one team member is reworking part of your test architecture while others are actively working with this architecture. Even the most sophisticated project strategy cannot protect you from such problems.

Is teamwork still giving you a headache? We recently did a video webinar about teamwork with QF-Test. You can find the full-length video recording of it here: