Monday, October 24, 2016

The two language trap

For a good number of years, I worked with an organization that was doing production and test automation code all in C#. The organization got there partially through trial and error with VendorScript and discarding all work of an individual because no one else could maintain it.  And partially from a timely recommendation from me. I had an opinion: it would be better to work on one language and not go for a different language for the testing code. 

And I'm simplifying things here. In addition to C#, there was at first a lot of JavaScript. Both in production code and tests. And then later on, there started to be a lot of TypeScript. And there was Powershell. So clearly the developers could move around languages. But common thing was that each of the languages was motivated primarily from production, and testing followed. 

The good thing about working on the same language selection was that as the lone tester, I would not be alone even if I would contribute to the automation efforts. The automation was there to support the developers, and while e.g. Python and Robot-framework sales were high (it's from Finland after all), a new language, I believed, would create a distance. 

So I changed jobs and the timely recommendation from me was way past being timely, with years of effort committed to a two language environment. The production language being C++, I could see why the choice of the same language for testing was not quite as straightforward. So the test language was Python. 

The more I look at this, the more I understand that there isn't a real choice of one language. But the two languages still looks a lot like a trap. Here's some differences I'm observing:
  • The gap between 'real' production programmers and the test automation programmers is deeper. 
  • The perceptions of the 'betterness' of the languages deepen the gap
  • People seldom develop equal skills in both, and as new learners they strictly start from one or the other. 
  • The self-esteem of the test automation programmers in their programmer identity is lower as they work on the 'simpler language'
  • There is a lot more of a separation of dev and test, even if both are code 
  • As an exploratory tester, I will be in a two-language trap - learning both enough to get the information in two different formats to the extent I feel I need it
I feel the two language trap exists, because a lot of people struggle early in their programming careers to just work on one language. There's a lot of language specific tricks and development to follow in both the ecosystems, taking the groups further apart. 

So this whole thing puzzles me. I have ideas of how, through collaboration, I could improve what I perceive as suboptimal siloing. How there's cultural work in promoting the two languages as equals in the toolset. How clean code and technical excellence might work as a bridge.

But I wish I did not have to. I wish I could live in a shared language environment. And most of all I wish that those who are not forced by realities into separating production and testing into two different languages, would think twice on their choices. 

It's not about what language your tester is comfortable with. It's also about who will help her in the work, and how much will she have to push to get her work to be the feedback the developers need. 

When the test fails, who cares? I would hope the answer extends the group of test automators. 

2 comments:

  1. A good compromise that I've found in my current position is that, while my testing framework is in python and the SUT is in golang, I was able to make articulate reasons to the developers *why* this was a good idea, which was mainly the libraries and tools available in python that don't exist or aren't quite ready yet, as well as the requirements of the system. Any engineer worth anything will agree with the statement that you should use the best available tool for the job, and while python wouldn't be a great choice for our application (high throughput, need microservices, etc) golang wouldn't be a good tool to use to test a REST api.

    As for the gap problems, those are real, but methods that we use to mitigate them are: Testers write development code, or at least tests (unit tests and the like in production) and developers write test code in the test framework. This keeps both parties familiar with the SUT's new functionality as well as the methods that the test team is using to actually perform those tests.

    ReplyDelete
    Replies
    1. In two language trap, I also find it relevant to not limit individuals per language but actively bridge both sides to take some steps on the other language side. That's my reference to "collaboration". My way of doing that is, unsurprisingly to my readers, mob programming.

      Delete