The lines are getting blurred

ID-10039210I hear about this all the time when I talk to PractiTest’s users.  You can read about it in the blogs and tweets of our fellow testers.  People in QA conferences are talking about it more and more…

The trend is clear.

For most testers this is not an easy change.

At the beginning it frightened me. Then I learned to live with it.  And, as I immersed myself into this new reality, I started to realize the incredible range of opportunities and improvements it offered both to development teams in general and to testers in particular.

What am I talking about…?

The fact that today the lines that separate between developers and testers are getting blurred, resulting in more and more testing tasks being done by the developers within our teams (Introducing DevOps).

This is not happening in your team… Or is it?

The first reaction I get when I bring this subject up with fellow testers is that in their company this is not happening.

Then, when I ask if programmers are doing more tests today than they did 3 or 5 years ago the faces and tones suddenly change and become less secure.

Everywhere you look at developers are getting more involved in testing.  They are writing more unit tests, Continuous Integration practices are common in many organizations, there are more programmers walking up to testers with questions about testing scenarios, etc.

The “virtual wall” previously used by developers to toss the product over to the testing team now has many doors and windows that both teams use to communicate and even collaborate.


What does this mean to the organization?

For starters it means that programmers need to learn how to test.

Testers get a chance to teach our development peers that testing (or at least good testing) is not a trivial task of randomly pressing buttons on the screen or typing “asdf” into text fields to ensure you can enter data into the system.

We’ve become testing mentors, explaining about testing scripts and testing data, reviewing positive and negative scenarios, explaining about pairwise testing and the testing heuristics we use.

Additionally, this change also means that our project teams now allocate time for developers to test their code. Even if this sounds trivial at first it is a big mental shift in the way companies prioritize their tasks, especially when projects get close to their deadline and time becomes the most scarce resource in the team.

What does this mean to us as testers?

I already wrote  that we’ve become mentors to our development peers. But does that mean that we are actually teaching our work to others in order to be relieved of our duties in the near future?

At first this is what frightened me, not personally for my future, but for the future of our career as a whole.

I was afraid that testers would become another VHS player or another Fax Machine, useful in the past, but doomed to extinction as times and technology advanced.

But then I realize that this was only partly true.

It is true that part of our job is being migrated to others in our organization, but it is also true that we are being given more responsibilities within the team and also being offered the chance to influence more on our process and the outcome of our projects.

In many places testers today have become strategists and advisors, working from the early stages of the project in order to assess and plan the overall development approach of each feature based on it’s requirements, risks and also based on what will need to be tested and how.

We’ve also been given more responsibilities to work with users both before as well as after the product has been delivered to them.

We are also being asked to perform more technical tasks, planning and architecting large parts of the automatic testing framework that will serve both developers and tester in our work.

Depending on the type of environments and companies we work in, testers are being given additional tasks.  For example, in many SaaS companies (such as PractiTest) testers are tasked with many of the deployment and production monitoring operations, as well as troubleshooting issues happening to customers in their real-work environments.  As a friend of mine put it some weeks ago, it is not about whether a bug is happening or not, but about how many times it is happening and to what percentage of our users…

And obviously, we are being asked to compile all the information that relates to the project and its quality status.  Giving a live, clear and concise overview to the rest of the team on the state of the product, the status of the process and the ways in which both of them can be improved.

What is the next step…?

I am not sure what the next step will be, but as I said before the trend is clear and the lines between testers and developers are getting blurred.

For the good or the less good (let’s keep optimistic) this is happening and it is something we all should be aware off in order to be prepared for the changes that will continue coming in the future.

Are you seeing this in your company?
How is this changing the way you work today?

Share with us your experience to understand how is this new reality changing your life and your work as a tester!

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.


7 Responses to The lines are getting blurred

  1. Jamie Skibicki November 18, 2013 at 10:16 pm #

    I certainly see QA being involved much earlier in the design process. Not only does it help the QA by understanding the project or changes as dev is working on them, but the QA team also adds to the design process. Asking how the application will handle the tests you have come up with during design usually exposes some problem with the design or incomplete knowledge about what the feature is supposed to do.

    And as we all know the earlier you find a bug, the cheaper it is to fix.

  2. joelmonte November 19, 2013 at 8:23 am #

    Thanks Jamie,

    I agree with you on the advantages of “dry-testing” the design early and saving lots of time and money by finding the bugs even before they are written.

    But what I am seeing lately that is different (and more revolutionary) than this point above, at least IMHO. Tester’s participation not only around testability or incongruences in the design, but also about bringing more of the user’s perspective into the system.

    As much as we’d like to think Product Managers have that point covered, it seems that the perspectives we are bringing (as testers) playing the role of customer advocates is only growing with time.

    In my mind this is a nice addition the list of responsibilities we have in our projects 🙂

    What do you think?

  3. Jamie Skibicki November 19, 2013 at 7:05 pm #

    I try to bring the users perspective in and try to act as a user advocate, but I typically don’t have the subject matter experience to do that well. I have been in 6 different fields since I’ve started and have stayed largely industry agnostic.

    That being said, I do get as much industry knowledge as I can from those I work with to help with this, but it’s usually slow coming.

    Those that are SME’s can certainly do this much better than I can and I have that shift to SME’s creating tests and QA handling the automation, reporting, etc. THis has it’s own downfalls though,

  4. joelmonte November 20, 2013 at 11:16 am #

    Sounds like a good approach, I always thought that a great although it helps to know how to play some instruments, a great orchestra director does not need to master all of them, for that he has his first violin, first cello, etc.

    Still, one of the things I learned to do whenever I start working on a new product or industry is to ask to meet with as many customers as I can. And if I can’t for some reason, at least to try to understand them via long and diverse talks with Customer Representatives.

  5. Rebecca December 27, 2013 at 2:47 am #

    I don’t see the lines being blurred, but a deeper understanding and appreciation about one another’s skill set and earlier sharing of tests and test strategy in order to verify the requirements are being met both from a development perspective, but testing as well.

  6. joelmonte December 29, 2013 at 7:50 am #

    Each team will see something different (some of them will see no changes at all).

    My personal experience is that the point of “deeper understanding” comes somewhat before the lines really start getting blurred and you start sharing or porting some tasks between devs and testers.

    In any case, the fact that the sharing takes place is in itself an extremely positive and valuable factor to the process.


  1. Testing Bits – 11/10/13 – 11/16/13 | Testing Curator Blog - November 30, 2013

    […] lines are getting blurred – Joel Montvelisky – TYRANNY OF THE INNOCENTS, EXHIBIT A: GARY COHEN – James Bach – […]

Leave a Reply