Automation Testing

Developers & Testers – Shut Up and Help in the New Year

By Test Guild
  • Share:
Join the Guild for FREE
Shut up Developers

“The ratio of people to cake is too big.” ~ Milton Waddams — Office Space


My first rant of the new year:) Maybe it’s because I work for a large company, but it sometimes feels like something out of the movie Office Space. I can only hope that it’s just me, but in 2016 I’m already struggling with thinking that seems to be straight out of the 90’s Waterfall development culture.

Agile in Name Only

We implemented Agile and BDD practices on a new development effort a little over two years ago, Although we’re really good at the easy, non-critical things that make it look like we are “Agile”– like forcing everyone to work in one room like a bunch of sheep to being “co-located” and having two-week sprints so we can develop “quickly,” we still struggle with the most important thing that Agile and BDD is supposed to help with, which is to create a culture that values communication and collaboration between teams.

Email Flame Wars with Developers

Just today I received this little flame mail in my inbox:

“Today this was brought to my attention (I didn’t realize that before) that BDD tests resulting in serious data inconsistency on all test systems.  
As a result a number of “spurious” defects are opened by the QA because of such inconsistency.

Then developers fixing those “pseudo-bugs” by providing unnecessary workarounds in the code thus increasing code complexity. It is clearly a waste of time. Then when the tests are completed, some code is cleaning up tables. Unfortunately, it is done in the same clueless way without a proper transaction logic while deleting data rows or similar. As result of such “exercises” a number of records become orphans. Such scenario is not the case in real production since all is managed by supported consistent SQL code encapsulated in RCM(s) which are called in certain order. That’s said, I consider this as a serious issue impacting team productivity.

Whoever is responsible for the BDD automation scripts and other test codes have to perform this in supported consistent way.”

That’s the whole Email. Very helpful, right? WRONG! Although the writer brings up some valid points, it contains elements that are pretty disturbing to me. Worse, I know this isn’t unique to my team or company; I hear similar stories from test engineers at other companies all the time.

Look in the Mirror

[three_fourth_first]Don’t you just love people that seem to know how to fix something but offer no help in resolving the issue? They are quick to kick the can and say “I told you so,” but not lift a finger to actually resolve the issue. This is also a classic case of waterfall silo thinking with the old walls of separation between developers and QA.[/three_fourth_first][one_fourth_3_last]LookInMirror[/one_fourth_3_last]
Let me mention again: If you ask anyone on this team they will swear we’re using “Agile,” but this “developers vs. QA” mentality is still prevalent throughout the organization.

So, to answer one of the questions in this email (“Whoever is responsible for BDD”) the answer is, “Look in the mirror, because we are all responsible for Behavior-Driven Development!”

Ownership – Solve the Problem

The funny thing is that I just stared to read the book Flipping the Switch – Unleashing the Power of Personal Accountability and it talks about how just by changing the types of questions that we ask from blame centered to more personally responsibility type question can change your entire outlook and help you achieve better success.

Here are some better questions anyone can ask (even developers) this year to make things better rather than play this waterfall non-productive blame game:

  • How can I solve the problem?
  • What can I do to contribute?

Notice how these question are the opposite of the types of question from the email above where the person asks more unproductive questions like Who is there to blame? Who is going to fix this?

Take Personal Responsibility

Better questions that can (and should) be asked to actually improve the situation are:

  • How can I help the BDD effort?
  • What can I do to make this BDD test data situation better?
  • How can I take Ownership of this issue and move it forward?

Only when each and every team member begins taking personal responsibility by asking these types of questions will our development and testing efforts start to improve.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Continuous Testing in DevOps Bootcamp (2024 Guide)

Posted on 05/23/2024

One issue I often hear about on my podcast is the fact that ...

Mastering AI in Test Automation: Expert Tips!

Posted on 05/14/2024

Over the last couple of years, many of my podcast guests who work ...

What is Synthetic Monitoring? (2024 Guide)

Posted on 04/18/2024

I've found over the years many testers are unsure about what is synthetic ...