We sat down with Jeff “Cheezy” Morgan ahead of his STAR CANADA 2013 session titled “Android Mobile Development: A Test-driven Approach.” Jeff shared with us how there’s simply not one way to achieve successful collaboration between testers and developers. Everyone has to be willing to give a little, and when they do – it’s to the benefit of all.
Noel: Your upcoming session addresses taking a "test-driven approach" to Android mobile development. What would you say is currently "driving" development in Android, and why does it need to change?
On the development side of the equation it is very rare for developers to be test-driving their mobile applications. Many believe it is not even possible. Testers typically test mobile applications manually which means long feedback loops to developers and also means that testing happens late in the development lifecycle. What happens as a result is a long cycle of defect discovery and rework, which causes delay in releasing to the public. Also, the codebase for the application tends to get messy which continues to add to the defect count and delays in delivery.
Noel: When selling TDD or ATDD to teams that may not have attempted it before, do you notice testers or developers resisting the change more, or is there generally equal skepticism or excitement to try something new?
I rarely run into skepticism as both of these practices have been around for quite a while and they have a track record of improving quality. It is very easy to demonstrate these practices and people can see how it will help in their quest to deliver high quality software. I do often see hesitation that I believe is due to fear. Both of these practices fundamentally change the way we work and change can be frightening. The good news is that both of these practices can be learned with time and practice and many have done so and reap the rewards daily.
Noel: In regards to the need for collaboration between developers and testers - do you see this requiring more from testers, or developers? In other words, is one team having to make a larger new contribution or will testers and developers share the change equally?
Some of this depends on what type of testing is currently being performed. Manual execution of test scripts dramatically reduces the collaboration points between developers and testers, as the software needs to be developed before testing can begin. In this situation I would like to see the team adopt a test automation strategy. If the testers are going to perform the automation (my preference) then they will have more change than the developers. If the developers perform the automation then they would have more change.
Good collaboration requires a lot of things from people. One of the fundamental things required is trust and I find that this is often missing between developers and testers. My experience is that testers often have a harder time overcoming this lack of trust. As a result, they often have further to go on the soft skills side of this collaboration.
Noel: Once testers and developers begin to "play nice," and collaborate better, what's one of the first benefits they should all notice in their workload?
They would notice a dramatic reduction in rework. Rework is the defect discovery / rework phase that typically happens at the end of development.
Noel: With one of agile's core principle of always finding ways to do things better, if you had to predict the future, what's in store for tomorrow? What's not being advocated today, that we may one