Testers are weird. When they find a bug in their AUT they feel good. But when it comes to integration testing, testers feel a sense of defeat when a bug is found to be in the AUT they are responsible for, rather than the AUT the other tester is responsible for. Can you relate? Stay with me.
When discussing integration testing observations, devs, testers, and business people say things like…
“we do this”
“then we do that”
…to describing the application they associate themselves with. And if the discussion includes an external application, folks start saying things like:
“when they send us this, we send them that”
“they create the XML file and we import it”
I hate when people use subjective personal pronouns instead of proper names. For one thing, it would be easier to understand a sentence like “Application_A sends the file to Application_B”, than a sentence like “They send us the file”. Afterall, they are called subjective personal pronouns. But the other reason I hate this way of communicating is that it reinforces an unhealthy sense of pride. People connect themselves, too intimately, with the application they refer to as “we”. People are biased towards the group they belong to. They start to build a bubble around their app; “It’s not our bug, it’s their bug”.
My little language tip may seem trivial, but think about it the next time you discuss system integration. If you resist the urge to use subjective personal pronouns, I think better communication will occur and your ego will be less likely to distract from effective teamwork.
RSS
Test blogs I try to read
- Adam Goucher
- Adam White
- Ben Simo's Quality Frog
- Dawn Cannan's Blog
- Google Testing Blog
- I.M. Testy
- James Bach's Satisfice
- Jonathan Kohl's Collaborative Software Testing
- Matt Heusser's Blog
- Michael Bolton's DevelopSense
- MSDN's Software Testing Forum
- Steve Rowe's Blog
- Test Obsessed
- Testy Redhead
- The Braidy Tester
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, hit the gym, listen to public radio, drink strong coffee, perform virgin software tests, break for lunch and a Euro-board game with the devs, log more bugs, walk the dogs, enjoy a meal with Melissa, an IPA, and a Netflix, look forward to a weekend with a cave trip or woodworking project.
Hi Eric,
You are definitely right about how personal the people involved in integrated products make their applications.
I actually just sat through a meeting today because of the very same thing. There was, however, one major difference. The controversy that began because I took the liberty of installing both applications on my machine to test. Months of confusion and about 100 email chains later, a meeting was called. I realize what I did changes the scope of what would "normally" be considered integration testing, but it gives me a clearer picture of what I am testing. Apparently it gave others heartburn as it really messed with the "definitions", tester roles, test plans, and status quo of the organizations.
Fortunately at the end of the meeting my civil arguements won out and I can continue to do what I have been doing without my hands being tied. I explained the value of it and how it would not really be overlapping in test efforts since the reasoning behind me testing this way was to provide my own data and have a better understanding of what the customer will encounter in the entire process, not just "does this data work". How can I even imagine what the user sees if I don't see it myself? What happens if the data is not pre-planned for the integration? What if mistakes are made by the customer and those end up in the files? Etc.
It does help to remember that at the end of the day either the stakeholders and customers are satisfied or they are not. "We" can work toward that a lot better than "Them" and "Us".
Good post!
Ah, good story, Michele. As long as we understand how the apps work, we can gather lots of info using our own little simulations of the real world, even if we have to break a few rules to do so.
I’m glad you liked this post. I was distracted all day yesterday, listening to people describe various scenarios between the many apps that support this place. I kept finding myself clarifying, “when you say ‘we’ process the file which module do you mean?”.
And the devs are the worst! It’s like their code is them…”When I get the data, if I see a null value I return a fault. I’m not sure if they do anything with the fault when I give it to them
I hear what you're saying but I also think it's quite natural to speak like that, particularly when dealing with entities that you created or helped create. It really implies a sense of ownership and pride in what you do as well as defining what you are responsible for. And maybe that's the problem.
Developers are a very logical bunch(duh). We have to know where the boundries are because if we step over that boundry then it can cause problems in other parts of the code. When a bug is found in the code you wrote, there's no one to blame but yourself. Mabye too much compartmentalization. So if it's NOT your code that has the problem, you instantly recognize that as "they".
Once looking at a broader picture, it's harder to shift gears and see the problem within your circle of influence rather than outside it.
But all in all, I do agree that it would be better to try and speak more clearly. The hard part is recognizing when you are doing it.
Thanks for your thoughts, Tripp. Yes, it is a "natural" way of communicating.
Now that you've spent a fraction of your brain on this, you'll have no problem noticing it.
You'll just have to decide if it's worth the effort.