What can you do if all testing at a company is done with little interaction with developers? How can you change things to be more iterative? Testing expert Scott Barber explains.
On having little interaction with the developers
Some testers lament that they don't have enough interaction with the development team, while other testers complain if they are expected to interact with developers. I have my preference (I like to be integrated as a single team, working literally side-by-side), as I'm sure most people do, but the fact is that this is as much a matter of preference and policy as anything else.
The key here is to figure out why you don't have much interaction with the developers. Then, based on that answer, decide whether to champion a change or deal with the status quo.
More interaction with the developers in and of itself will not make a team more iterative, more agile or more effective. More interaction will simply make the teams more interactive -- and in some environments interactions between developers and testers is not pleasant. So, before you decide to champion a change, make sure you know what you're getting yourself/your team into.
On becoming more iterative
This is a project- to company-level question, not a test-team level question. To be honest, of all the possible company/project roles who should be involved in deciding what approach the company/project should take for software development, testers and test managers are least relevant to that decision.
Put another way, if the testers want the Rational Unified Process (RUP), the developers want Extreme Programming (XP), and the company as a whole wants to follow STEP, which approach do you think will result in the best software come release day?
The answer is "Whatever the developers want." Why? Because if you force the developers into a development model they don't like, they're going spend their energy hating the model and longing to do it the way they like to do it and end up writing bad code that they don't care very much about.
As a tester, it's my job to adapt to whatever works best for the development team. It's my job to help the developers make better software. If I think having the developers be more interactive with the testers and being more iterative will help the developers make better software, then I'm going to demonstrate that to them by interacting with them. Once I prove that interacting with me adds tangible value for them and they trust me, then maybe I'll suggest shortening iteration cycles or developer/tester pairing for test sessions before code is ever checked in -- or whatever.
At the end of the day, it's all about people. Focus on the people and seek to understand why things are the way they are. Do that, and answers will start becoming very clear to you.
