As promised here is Q&A follow-up from the Developer and Tester Working Together Agile Style webinar held on 12/5/13.
JeanAnn Harrison (JAH), the tester and Jonathan Spurgin (JS) the developer spoke about how their collaboration and good working relationship helped to achieve a higher quality mobile medical device. If you missed the webinar it can be accessed on Youtube and slideshare.
Here are the answers to a few questions and comments.
Q. Do you feel it’s management jobs or test/dev teams job to make sure the two teams are working together?
(JS) All are responsible for getting along but it is really management’s primary responsibility. But if management is not taking an active roll, I’d advocate the motivated people in the two teams to take the initiative. If management does not impede the cooperation, all is good! If they do impede working together, well, not good at all. (JAH) Completely agree with Jonathan here. Management really does need to enforce collaboration. Great question as both Jonathan & I did have to take this initiative at one point. Sometimes you can make games, social gatherings after work or even share a group social lunch can help. I would go so far as to create a fun game type meeting once in awhile but assign teams of Dev/Tester to work together for that common goal. It can really help to ease tension while working outside of the social setting]
Q. Given that bugs are more hidden and intermittent, do you have any suggestions for updating/modifying the RIMGEA mnemonic to better address mobile testing specific issues? (JS) Definitely a Jean Ann question!
(JAH) 1) Replicate: Not only do you want to replicate the steps for the bug, you need to replicate the problem on another device. Change the hardware to confirm the bug is not hardware dependent. So for example, if you find a problem on an Android phone, then try replicating on another Android phone, first the same model, then change the model. I also recommend replicating on other device configurations like tablets. But now you also need to think about the operating system and combine your tests to include devices with different operating systems. This means testing on an iPhone, iPad, etc. Now you know the bug is not hardware specific.
2) Isolate: Limiting the steps is important for efficiently utilizing Development’s time. In mobile though, the need to isolate is vital because hardware, firmware and software teams all have extraordinarily different perspectives and more often from different companies. Spend some extra time testing, eliminating factors like various hardware, firmware conditions such as charging the device, turning the wifi on/off, different locations. Break the steps of your replicating the bug to as few as possible along with the types of conditions. Don’t forget to eliminate the question of device configuration as well.
3) Maximize: Be sure to increase the hardware variants in the test especially to stress the hardware and observe how the software can handle the stress. Consider including how the software recovers from crashes, error messages and problems. Think combinations of the hardware, the drivers, and the software when thinking tests.
4) Generalize: I am not really sure what this means from just a standard testing point of view but I would think the same applies to mobile testing. If you find a bug, then the way to go about testing that bug is to find general conditions based on any knowledge of how the user would or could come across the bug. This means understanding the inter-dependencies of the software application.
5) Externalize: All bug reports should contain some sort of explanation of investment for the user. The more clear a tester or other team members (get some buy in from marketing/sales/management) can fully explain HOW the problem can impact the company, the more investment the Dev team will have in fixing the bug. But the bug report must contain information regarding user experience information. Company reputation can be immediately impacted if the lack of response to fixing a bug is not completed and released. Mobile bugs can devastate a company in seconds.
And, Clarity/Say it without emotion: Pretty much the same as what is described – be clear, concise and dispassionate about your reports. The more you put focus on the above points, the more clear information you can provide to Dev. But with mobile testing projects having a shorter schedule to deliver, the better the team will look if they help out the Dev team.
Hopefully this helps give you a different perspective.
Two other comments from the audience and the speakers…
When running tests and the test fails the failure needs to be evaluated. The failure maybe a software issue but may also be a hardware issue, requirements issue, design issue, test case issue or low or high priority. The problems need to be evaluated by a multi functional group.
(JS) Excellent point!
(JAH) We found that we preferred spending time together to isolate problems because 1) we wanted to address the root cause, 2) because we did enjoy working together 3) we always managed to learn something to help us in future projects/issues etc. I do believe if you all commit to working together, find a common goal AND connection (a particular sense of humor style), you will get all working together and management should encourage that commitment.
QA is required to look at the program differently then a tester is required to look at the program.
(JS) That’s the power of team collaboration!
(JAH) You never know when inspiration will strike. One says one thing, another says another and perhaps even another person says something else but when in a discussion, you might find these things on their own do not work but analysis of all 3 things provides ideas in moving forward.