Testing and Bug Resolution using Lighthouse app
At Click Labs, we are always striving to be the most transparent and open company around. Our clients appreciate it and have often suggested things by which we can improve our processes further. In that spirit, this is first of many informational articles that our clients can educate themselves with. We have heard many competitors are always asking some of our staff members for the secret sauce that makes us the best. Let me tell you, here is what we do, we are glad to help you copy it. I am going to talk about testing and bug resolution in this post. We use Lighthouse app as far as testing is concerned. At Click Labs we use it for keeping track of bugs and checking the status of projects at the testing stage. Anyone who has access to the Project on Lighthouse can check the Project status (for testing phase) and get up to speed with the same. It also acts as a handy tool for all kinds of discussions between clients, testers and developers.Multiple users can access these bugs and add their queries thus acting as an efficient mechanism to keep projects having multiple developers and testers on track. Individual bugs/tickets can be assigned to relevant persons who can be held accountable for the same.
How Will You Get Access To Lighthouse: We will send you an invite through an email. You will have to register on the website and you will have access to our Bug tracking mechanism.
Bugs/Tickets can be categorized under 6 heads:
1) New: The state when a bug is identified is referred to as ‘new’.
2) Open: The state where a bug is genuine is referred to as ‘open’.
Ticket state can be broadly referred to as open under these categories.
3) Resolved: Tickets resolved by the developer come under this category.
4) Invalid: if a ticket is not found out to be genuine by developer after the mutual discussion of developer, PM and Tester, then it is termed as invalid.
5) Hold: If a ticket has less priority/shifted to another milestone/ resolution depends on resolution of some other ticket its status can be marked as on ‘Hold’.
6) Closed: Tester can directly intervene and close the ticket if he/she finds that the issue no longer exists in the next build.
Some other features which come in handy are related to versioning of the app. It makes sense in most of the projects to come out with different versions of the app rather than complete feature loaded app all at once. Consequently, tickets can be allotted to different milestones so that the required changes are never obscured and can be tackled accordingly.
No comments yet.