Building a mobile team from ground up

I moved from Cleveland to Chicago about 4 months ago and I should say it has been pretty hectic but at the same time exciting. This time I am talking about my new gig at a travel booking company leading a mobile testing group.I wanted to share my experiences building a team from ground up and establishing a stable process within 2 months. These are the approaches I took to create a stable test process and strategy.

Step 1- Gathering test devices 

As a new member to the team I had to start from somewhere. I decided to concentrate on what devices I have for testing as a start. As I was gathering the test devices I kept the below things in mind

  • What different devices do I have?

  • What OS versions do the devices have?

  • How better to manage these devices?

Asking the above questions help me to get my head around the test devices I had and I took this further and created a Wiki with all the devices I had, their UUID number, OS versions etc.

Step 2- Creating a Test wiki to have central repository for testing resources

Another common problem in many teams is, resources are scattered all over the place. When I say resources I mean

  • Tools which are available

  • Username/Password to access different intranet websites

  • What are other accesses testers would need while doing their testing

  • Where to request access to these resources

  • Where is the information about different systems used by the company and team.

  • What are the available documentation on them

And so on......To help in this, I created a team wiki where all the resources related to testing were housed in one page via links, tables, attachments and plain text. After the team found this useful I extended the Wiki to house all the information related to developers and testers in one place. This helped a lot and has since been used for all intensive purposes.

Step 3- Creating ET charters and doing time boxed testing sessions

I had to quickly not only establish a test process but also start doing testing. There were so many test plans which were previously used and outdated too. There were other test scripts which were in different locations.I took the time to go through each one of them and see what can be re-used. Then, I created Exploratory Testing Charters some re-usable and some containing test ideas for different functionalities of our apps.I did time boxed test sessions and recorded all my observations in charter. I housed all these charters in one central location so that it is visible to the whole team. In this way testing is not considered a separate/secretive activity and is more transparent and open to all.

Step 4- Creating a Bug template for consistent Bug reporting

Another thing I observed was all the team members including developers and business people posted bugs. But each one these reported bugs had different kinds of information. Some were descriptive, some had screenshots, some were just one liners about what they observed etc.To bring consistency in the way anyone reports bugs in the team, I created a bug report template which consisted the following items-

  • One line description of the bug

  • Detailed description of the bug

  • Steps to Reproduce

  • The environment it was found in

  • The devices and OS versions

  • The app versions being tested

  • Screenshots.

All the other items like Priority, severity, who found it, who it is assigned to was handled by JIRA. So that made this job a lot easier.Since I created the Bug Report Template the whole team has been doing consistent bug reporting and it is now readable by anyone.These were my initial experiences after joining a new company. What was yours? Feel free to share them here.   

Previous
Previous

Localization Testing Cheat Sheet - Mind Map

Next
Next

Mobile Testing Cheat Sheet - Doing Quick Tours on Your Mobile Apps