Working as a consulting test manager in my latest project, a new website with 20 local sites, I was planning user acceptance testing which would be done by using all project members, reference groups, local site owners etc. (60+ persons) as testers.
The question was how to do this. How will testers report issues they found? In our tech team we used Scrum Board and post-it notes to handle issues we found internally in the team. We did not have issue tracking system and we, actually, did not need it.
Should I set it up now for external testers? Many of those “testers” were not so technical and such tools might discourage them from reporting issues (login, complexity, filling all mandatory fields etc.) On the other hand it could also take some time to set up an issue tracking system and depending on if it is an open source or a commercial tool, it could cost some money for license cost.
So, my first idea was that testers would report using email. But what format should a report have? Excel, power point or something else?
I did not want to receive long issue lists which I need to merge and eliminate duplicates, and which is difficult to handle. It would also mean that we use two systems – email and, for example, excel to handle issues. I wanted only one system for simplicity sake. It is good both for issue reporters and for us who are fixing issues.
I decided it would be simplest to use only email as an issue tracking system. Tester would write issues directly in email body, one issue per email to make issue handling easier.
Subject of email would be short description of the issue, and in the body of the email it would be info about browser, operative system, url of the page the issue is found, detailed description of the issue and screenshot(s) if needed.
I created a new Gmail account that was easy to associate with the project, something like: [project name].firstname.lastname@example.org
Then I informed all involved that they can report issues to this issue-mailbox and gave them all necessary info: when they can start reporting, template they would use and so on.
Testers would get immediate feedback from us: if the reported issue is accepted or rejected. They would be also informed when the issue is resolved. This feedback process was really appreciated by testers.
But how was it on our side – side which was supposed to fix issues? As I said before, I wanted to use only one system so all project members who were supposed to do something with incoming issues got login information for the issue-mailbox. I created different labels for different teams: ‘tech’ for developers, ‘design’ for designers, ‘change requests’ for BA and product owner, ‘content’ for content team. We had also different labels to specify severity/priority of issues such as ‘trivial’, ‘minor’, ‘major’ and ‘critical’. And also labels with team members’ names used for assignment of issues. Other labels could be created depending on needs (e.g. ‘fixed’, ‘rejected’ etc.).
Issue dispatcher was owner of the inbox. He/she was supposed to reply to reporters and move issues to the correlated folder (actually label, because Gmail uses labels instead of folders, which is better since your issue can have several different labels ).
All others work only in their folders (labels). When you want to work on an issue and assign it to yourself, you add your name label to the issue and forward the issue to your private email account. When you are done, you just reply from your private email account to the issue-mailbox with information about what you have done. The email then come to the issue-mailbox inbox, dispatcher check/test that issue is really fixed and if it is so, he/she inform the reporter that the issue is resolved. Dispatcher then remove all labels from the issue and move it to the ‘fixed’ folder.
On this way we had all history in email threads and could see who did what.
Good things with using Gmail are:
Of course Gmail is not so powerful as a real issue tracking system and lacks many of its features, but if you do not already have such system and need to start gather issues from external project members with a minimum of the set-up time, then, I believe, Gmail is really good way to go.