Solo sailing isn’t easy. It’s usually done with a small sailing boat or yacht rather than a large one. Not many do it, for various reasons. First, many of us prefer company, to share the joy of sailing with. Second, as mentioned, it isn’t easy.
In some places, you can’t sail on your own on a yacht without a special permit. That’s how not easy it is – in the eyes of authorities :-)
You must be a very good and very experienced skipper, in order to sail solo. You must know how to operate everything, moving about the yacht without losing your direction, your sails setup (being adjusted to the wind and direction of the boat). You’ve got to be able to know how to make stops, where, and when, to allow yourself a rest, while making sure you don’t hit or get hit by anyone or anything.
Other than being experienced, professional, trained, and physically fit, the solo-skipper should also recognize whether they are mentally ready for the challenge, and do they have the right qualities for it (calmness, acceptance of the solitude period, behavior in emergency situations, etc.).
And when all that is checked, we can start preparing the boat itself for such an adventure. There’s much we can do, for example:
- Make sure we have all of the up-to-date electronic equipment to aid us
- Add mechanical and electric operation to anything that can be operated non-manually
- Move the controls (ropes, navigation system, radio) close to the helm
- Rearrange ropes, ready with various knots
There are other things we can do on the boat, and some for our personal ease of living on the boat alone, that will make our sailing easier and safer.
It is important to remember that while going out of – or into – the dock, we can ask for help from other skippers, or anyone incidentally there (with the right guidance, they’ll be helpful).
It is very similar to a situation of testing solo.
Software Testing Single handed
Testing solo isn’t fun. It is better to have a team of testers, working together on a testing project, helping each other to achieve the project’s goals.
We discussed in the past the benefits of teamwork, the advantages of a diverse team, and the better results achieved when working together with all of the other project groups.
But sometimes it isn’t possible. You find yourself on your own. It may be simply because it’s a very small company, with just a few developers and you as the only tester, it may be budget reasons, that left you alone (there’s always a chance, as we are witnessing these days, for difficult times), or it can be a side-project you were asked to attend to, while still working together with the rest of the testing team on the main project.
And the same as with sailing solo, we’re asked to prepare ourselves and our testing environment somewhat differently than we usually do.
Not necessarily left all alone
Same as the option to ask for help, while leaving or arriving at the dock, as mentioned above – even though you will be testing on your own, there will still be others that you can get help from.
- Developers: Talk with them prior to starting to work, and explain why you need them to verify their code before releasing it to you for testing. That should be obvious, regardless of this situation, but as we all know, it isn’t. This code verification will save you a lot of defect reporting.
- End-users: If the tested application is for internal use, it’s easier, but even if external – for a customer – it is still an option to get some of the end-users to assist with the testing. You can try to be transparent and just tell them why it is asked, or you can be more diplomatic about it wrapping it with slightly different reasoning, allowing them to just verify that their requirements are met.
Building the right test repository
Creating the best test repository is always a challenge in any testing project. But in this case, it is more so. You have to be precise, structure it correctly, and more than all, minimize the number of tests while still covering all of the tested applications.
There are many ways to remove tests while making sure you get full coverage or the best possible coverage. It can be as simple as reviewing the test list, prioritizing tests based on the project’s requirements and the application’s code, working with the main stakeholders and developers on the required coverage, and all the way to analyzing the test cases using a sophisticated test matrix, resulting in fewer tests with more code coverage.
Explore your way
Yes, you guessed right, we’re referring to Exploratory testing. This saves test-writing time and allows you to cover more than you would otherwise since all you’re doing is testing.
You probably want to include a recording tool (embedded in your test management solution, such as in Tetsuff) while using this methodology. Since there’s no written test, the recording will save much time when the developers try to understand the reported defect.
Automation is the solo-tester’s best friend
Automation testing is always a good idea. When done right it is a strong and helpful means of testing, covering more tests in less time, easily repeated, and cost-saving.
It is even more so when the number of testers is… well, just one :-)
If you did not previously have automation testing implemented, you can try to use it with a series of steps, just for the coverage of essentials. But it might be too much for one tester to handle.
You might be lucky and have automation testing done previously, on other projects, and if it’s relevant for this new project. Try using it.
However, in most cases, you won’t have time or the means to do any automation on your own, while also testing manually. What you can do is to use external tools. There are many tools out there that will help you with different parts of testing – security, performance, browser compatibility, code checks, even coverage observations.
Choosing the right tools
If there are testing tools already in use, continue using them. No need to change anything. But if you need to choose a tool or tools, it may be good to remember that your criteria are a bit different for this project:
- No need for tools that support teamwork and data sharing
- You still want tools that integrate with the developer’s tools (for example test management which integrates with a bug tracker)
- You probably won’t be needing large storage capabilities or high performance, in light of the scale of the project
- Good documentation (of tests, defects, execution, history, etc.) and audit trails are crucial to prevent dependency on you, as the only person working on this project. An emphasis on documentation will carry several benefits:
- In the case of a reported defect, it is easier to understand and reproduce it
- Documentation will help with making sure nothing was forgotten
- Later on, it will be available for review and can be insightful for improved testing
Lastly. Try to enjoy your solo ride. There are things you can see as an advantage (no need to coordinate with others, you are in charge from A to Z, you depend only on yourself and don’t get frustrated by others, and you don’t have to work with those you never liked working with…). You can bring the boat back to the dock safely.