During a recent webinar on Continuous Integration (CI), I talked about the concerns of developers vs the concerns of testers in relation to CI (sign up to never miss another webinar here). The pressures developers face are different from those faced by testers. In this post I name a few and show how the concern of one role differs from the concern of another role. These are not concrete, 100% precise and complete listings of all the concerns either role would have. Some people will have different concerns in their environments and organizations.
It’s easy to think of one side of this table as being more “correct” than the other. For instance, if you’re a tester it would be easy to view these concerns this way:
On the other hand, if you’re a developer, it would be easy to view the table this way:
During the webinar, I talked about the prioritization of certain concerns above others. For instance, the developer’s need for quick feedback. I noted that some of these concerns can be addressed with Continuous Integration and some can not. Consider why builds run slowly – are tests too long? Do they provide proper information to devs? Must they be run every build? Is there a different type of test we could run get the information we need? CI in itself does not fix these problems. Design of test cases or how tests are organized for CI have a better chance as resolving this concern.
There are other considerations or characterizations about these concerns. For instance, if we shade the concerns that could potentially be supported or resolved by CI in green and those that are unlikely to be in red, the table might look like this:
Now these may all be debatable, and I guess that’s what the comment section is for… but can CI actually remove gaps between what the application really does and what stakeholders requested? Not really. Can CI explore the application? No. But can it help us deliver high-quality software? I would say Yes.
What if we only consider the set of concerns that could potentially be helped with Continuous Integration? If we shade the more likely of those concerns to be helped with CI more darkly, the table may look like this:
I believe the tables above are worth a conversation in most teams that already have CI running. For those that do not, I hope that this post is helpful at least in understanding the purpose different roles may have for CI.
To function as a healthy software organization we usually need may sets of concerns and owners for them. Responsibilities related to these concerns are generally implicit in roles. But how often do we discuss them? How many conflicts do you have in your organization because of misunderstood needs for a process like CI?
I wonder if clarifying concerns within your group about CI would be helpful? What if you took your team aside for a few minutes and drew these up on a white board. What if you asked the team to adjust these, redefine the concerns so that they are relevant and accurate for your team. How would you shade them? What would you uncover? How would you deliver high-quality software more quickly as a result of the conversation? Would you uncover anything? If not, is something not being talked about?
What are your thoughts? Do you believe the concerns in this table are real and identified accurately? Add your thoughts and results in the comments.