App Software Development: Using Trello for Testing
The Importance of Order
As part of our Delivery Process, we have all our projects tested before handing them over to our customers. All QA related activities need to be completed under tight schedules and budgets. This gives us an opportunity to exercise our creativity to adapt to the tools that are already being used by developers and managers. Specifically, we need to come out with a way to be able to manage our Testing projects using Trello.
On this post, we are presenting a board configuration to manage Testing projects, focused on mobile development. These projects have the tightest schedules and require less documentation.
This board is not focused to specific methodology and our purpose is that it will work for any type of Testing project. This is just a template and can be tailored to meet your specific needs, especially for bug tracking. In our case, Github is often used. We rather do the bug management there and document the bugs on the board.
This board is dived into four basic boards:
~Available Documentation
~Test Scenarios or Use Cases
~Execution – OSx
~Bugs Found
Available Documentation
There’s always some piece of documentation from which the design and development are based. Most of the time these documents can also help testing with the design of tests, and it’s important to keep track of them. We’ve also listed some key points for mobile testing, such as knowing which OS’s will be supported by the app and if it will be supported in different screen sizes.
We recommend keeping documentation as simple as possible and include only relevant information for Testing.
Test Scenarios or Use Cases
The purpose of this list is to have all test scenarios listed and ready to be copied to the lists for execution. We recommend organizing the scenarios by features, but we value and encouraging creativity so this list can be rearranged in a manner that makes sense for the project that’s being developed.
In the image below, an explanation is given as how to format the card to be used as a repository of test scenarios or use cases. We suggest having a naming convention for easy identification and traceability of the scenarios throughout the board.
Execution – OSx
This list is intended to keep record of the actual execution, and we have find it useful for our projects to organize the execution first by OS and then by feature.
The purpose of organizing the scenarios in checklist is to have a broad idea of the execution completion percentage. We have agreed that no scenario will be mark completed if there’s a standing bug related to it. We use the naming convention to easily trace the bug to the “Test Scenario or Use Case”. Items in this list are only left unchecked, and bugs are reported in the last list, “Bugs Found”.
We copy and move the cards from the list “Test Scenarios or Use Cases” to “Execution – OSx” list, as many times as builds come out. On the image below, you’ll find the information we normally include on a card in this list.
Bugs Found
The last list contains all the bugs found, organized by OS, in this case, but they can also be organized by features or what better fits the best for the needs of the project. In our case, we manage bugs externally with Github or JIRA, according to what tool the project is using. So, to keep track of the bugs opened in Trello, we use this list and add links to bugs.
As mentioned on previous list explanation, once the bug is fixed, the item in the check list is checked.
On the following image, we have exemplified the content of a card of this list. It’s worth to note that we have suggested using attachments as a means to further explain a bug; this is just in case there’s no available external bug management app.
Final Advice
To stay informed about changes and progress made on the cards, we suggest using the ”Subscribe” functionality available for cards, since Notifications are poor in Trello. This is specially directed to whoever is managing the Testing Project, and keep in mind that it doesn’t matter who created the card, notifications will not be sent if user is not subscribed to it.
This is our first and basic template to manage Mobile Testing Projects, a very simple but a really helpful way to keep in track your current testing projects. We hope to improve it in the future and we are open to suggestions on how to do it. Please, do not hesitate to leave your questions or comments!
About the Author
Claudia Cancino is a Mechatronics Engineer with almost 5 years of experience in Software Testing. She has worked in companies like IBM and Texas Instruments Education Software testing application.
Post Your Comment Here