I think when you are working with offshore team or outsourcing company – this particular phase is the most tricky to deal with. Because most of us now a days are so accustomed to work with internal QA team. Things take a drastic change during the Testing and Bug tracking phase. And that is another reason why services of a company like “HeliDigiZen” come in handy. As we know what we are dealing with and know how to handle this. During the testing phase if you uncover a bug – the fix needs to go through regression testing. So not only you have to test all the flows once the bug fix in place – you also have to test it across all the devices as well. You have to make sure the bug fix under one flow is not introducing new bugs on another flow and make sure none of the old bugs are coming back in while merging the changes while deployment.
Most of us now a days have our own favorite bug tracking system but while you are working with the outsourcing company it is best to work with a bug tracking system that works for both the parties. You don’t want your outsourcing resources to waste time trying to figure out how to operate a certain bug tracking system at the same time you don’t want to go through that process either. This is where some innovation comes in handy. We developed our own bug tracking system using google docs and google spreadsheet – as most of the people know how to use it and it does not require any additional software to be bought or installed. This helped us solve a few issues that we were facing,
- Now we always had a way to track what is happening with each bug reported – as we had 5 state defined for each bug – Open, Working, Fixed, Verified and Reopened
- Every one had an easy way to reproduce the bug – as we always defined the steps to reproduce when reporting a bug – very important
- It was simple to go through all the list of bugs while testing different flows and making sure none of the old bug are coming back or we are reporting the same bug again and again.
- And it was simple to reopen a particular bug just in case we see it again rather than reporting it all over again!
Up until this point we had always been working on the outsourcing company’s server but at this point we realized we wanted some control so we had them deploy the project on our end – so we can keep on testing while they are still working on bug fixing on their end. Helped us out a lot, and gave us an idea of “Pre Beta Launch” as well. But now we needed a way to track 2 different versions of code and an ability to report bugs for each one. It was pretty simple to accomplish using our own tracking system.
Once we were fairly confident of how things are working on our own server, we wanted some additional user feedback. We wanted to make sure that the flows are tested by some users who had no idea how this is suppose to work, and that is when we came up with the “Pre Beta Launch”. At this point we invited a few of our friends from technical background to do a test run on our system – and help us with some feed back. A great step – as that helped us understand what flows are confusing, some text revision needed and also gave us some confidence that we are pretty close to the Beta launch.
How did we go about our Beta launch? That we will cover in our next post!