The lines are getting blurred

I 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.

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!

http://qablog.practitest.com/2013/11/the-lines-are-getting-blurred/