Red Buffer, the company I work at, recently revamped their website. The website hadn’t been updated for quite a while and it was also in need of a new(read:better) design, so we decided to give it a new look altogether.
It was one of those internal projects which are always planned but are somehow never fully executed. This time, we decided to work on it and mark it off that planned-but-never-done list, once and for all.
A couple of people worked on it apart from other different projects they were working on. They finalized the design, developed it and put it online. I was asked to do a quick test of the website for a general user perspective since this is a company portfolio website and there was no defined set of requirements to match against. (On another note, I think giving your testers the full freedom to first explore the system and provide a general user perspective of the system is a great practice before you thrust a requirements list in their hand.)
Exploring the system
It was supposed to be a quick test to develop an idea about how the website behaves across different devices. It’s a one-page website containing about four to five navigation options. Since I don’t do “quick” quick tests (because “quick” quick tests don’t give me the quality feels*), I took some time to list down my observations and potential bugs.
Communicating the issues
The idea was to just send a message on slack to the guy leading the project to convey the overall viewpoint and potential issues. When I went on to actually put that information in a message, I figured that this wouldn’t work.
There were four to five issues. Even if I wrote a one line description for each with a picture link, it wouldn’t have been an effective way of communicating it. However small an issue might be, it is still going to have at least a 1-2 line description and of course, an image depicting the problem.
So imagine a few software issues listed in a message. Even if the other person understands it for that time, he will have to later go back to them, work on them or inform relevant people and then ping you back about them being fixed. Chances are some of them would even get lost somewhere in between this seemingly convenient but actually inefficient process of communicating the bugs.
Hence, we ended up creating a workspace for it on asana. It really makes your life easy – state the problem, add attachment, assign to the relevant person and you’re good to go.
- Do not underestimate any software system no matter how small it may appear. It might have the potential of consuming more of your time than a supposedly complex system.
- Digging deep is the key. You have to be detail-oriented if you want to be an efficient tester. There is no software system which can’t be investigated in depth.
- Do not rely on apparently faster means of communication like messaging to convey software bugs. While it might feel like a time-saving approach at that time, chances are that you will face difficulties in tracking them later on.
- If you have a passion for testing then not only will you enjoy anything and everything you test, but you might also be able to turn your testing endeavors into fascinating tales.
. . . . .
*The quality feels is the satisfaction you experience after testing something; that you have tested it enough to have done justice to it. Of course, we can’t guarantee 100% coverage but we still can avoid apparent bugs. So, when you are certain that there wouldn’t be any apparent bugs or issues, you might achieve the quality feels. When a tester will achieve that is highly subjective. (Note: I am not following any conventions here and this is my own term).