I want to talk about an experience that has got me thinking in alot more depth about my profession. In my last sprint, I had a story to develop a solution to performance test our system’s midtier.
It was late in the day. It was late in the sprint. I had just finished a complex part of my Gatling script. I needed to write a few lambda equations. These would facilitate a hash map to hold my test data.
I then noticed another problem. I had to fix a dependency in the Gradle build file of my Scala project. This is so that it would point to the correct version of our internal Maven repository. It had recently changed. I made the adjustment and everything seemed to be fine.
I was able to run the code fine on my local machine. I could do the same on my development VM, which is running Ubuntu 14.04. But I also needed to get it working on the teams shared Jenkins instance. This was running on an AWS hosted instance, which had CentOS as the operating system.
More messing around, frantic Googling, and tearing my hair out. It was 3am and it still wasn’t working, but I had come too far to quit now. I won’t bore you with the details of what I had to go through to get it working. But I got there in the end.
So to get to the point. I had been working solidly on this for days. Even working past the twilight hours and getting up again at 5am to carry on (I was that caught up in it). It was frustrating at times, no doubt. But there is a release of endorphins I get from perseverance and finally solving the problem. This makes it all worth it to me. I learnt a ton in this period, enjoyed my work, and can now look back on it with pride.
Where’s the testing?
But at the end of all this, basking in the glory of all I had learnt and achieved, a thought occurred to me. What has any of this got to do with testing, really? I haven’t done any “testing”, in the traditional sense, for weeks.
I suppose that the final product has testing value. The Gatling script and it’s implementation will performance test our system. But the development work, that I poured many hours and mugs of coffee into, is just that – development work.
The next day, someone outside my Agile team came over to me. “Hey, you’re a tester right?. We need you to manually verify this regression test case. If you could document it with screenshots that would be nice.”
I wasn’t sure what to say. On the one hand, he was right. I am the tester, and this wasn’t an unreasonable request by any means. But I had spent the last couple of weeks immersed in complex and specialised code. To now be thrust into this straightforward and mundane task just felt wrong.
Who else could he ask? You wouldn’t ask a developer to do this. The product owner doesn’t have enough knowledge of how the system works internally. Aside from outsourcing it totally (not practical for a one-off like this), there isn’t anyone else.
This experience isn’t a one-off for me either. It happens more and more. Especially as my technical knowledge and ability grows. I find that I am focusing more on the tools and the code, and want to do more of that stuff.
But this is likely to the detriment of my testing ability. Its the same with all skills, they are like muscles. If you don’t use them, they get weaker over time. Should I be concerned?
What testing should an Agile SDET do?
It got me thinking about how much actual “testing” I do though. I have worked in my current role, as an SDET at SAP, for just over 1 year now. Its a challenging, technical role. As well as writing a lot of code, you need to foster and grow deep domain knowledge.
I absolutely love the role. But I don’t do many of the traditional tasks that I used to previously in my career as a tester. That isn’t necessarily a bad thing, far from it. I don’t write much documentation anymore, other than the occasional test strategy. I rarely write a bug report, I just tell the developer there is a problem. Or I just fix it myself, since I have that ability now.
But shouldn’t I be doing more testing as well? I can’t help but feel that I shouldn’t just be writing code all day. Even if it is code that tests other code. On that note, even if I did just write automation code all day, who tests that code? Do I really think, as an SDET, I can write better code than a regular developer? There’s something to think about…
The rise of the SDET
There is a huge demand in the industry right now for SDETs. Companies want to recruit testers who can write code. They seem to want the perfect hybrid though. Someone with widespread knowledge of testing techniques and when to apply them. But also with the ability to write production quality code.
The problem with this is, it’s hard to find candidates with enough skills on both sides of the equation.
Take a typical developer for example. They want to write code. They don’t particularly want to do testing. They certainly don’t want to do manual testing. So they write code to do the testing for them (automation). But automation is not testing!
On the other side, you have the typical or traditional tester. They want to explore the application and find all the ways to break it. Even the ways that nobody else thought of. They don’t just care if the system works or not. They want to know if its effective, if it will satisfy the customer. To think and discover how it can be made better.
These are two significantly different viewpoints. They are the reason that testing and development have been kept distinct in the past. So why are we so desperate to merge them now?
Defining the role of the SDET
The role of the SDET is often not clearly defined. Perhaps that is because it is such a new role in our industry. You can be viewed differently by two people in your company, even two people in the same team.
Should you be picking up all the manual testing? Perhaps some, but I would wager that most SDETs don’t want to do much manual testing, beyond explorartory. These experiences of being an SDET at Microsoft are interesting, and I can relate to them closely at the moment.
Manual testing should be outsourced. Especially when it has to be repeated regularly. It shouldn’t just fall to the pool of SDET resources to pick up. They have their own complex work to do, and its already more difficult that development anyway. Not to mention, an SDET resource is usually paid as much as a development resource. So having the SDETs pick up this work is expensive for the business.
Whats the problem anyway?
Is any of this a problem? Not really. I am discovering that I love writing code, especially when it solves problems. But I also still love testing, finding those unusual ways to break the system. To break the developers (just kidding…) . To think from different points of view.
I’m going to carry on doing both. I think being an SDET is an incredibly exciting and rewarding place to be. There are huge opportunities out there, and they are increasing at a pace.
But I also think its important for companies to remember to make a distinction. Between the traditional tester and the new SDET. They are not the same role, they are different. They shouldn’t recruit a candidate to fill both roles, it won’t end well.
From the perspective of a SDET, I find that it’s easy to get wrapped up in the technical work you are doing. But its important to remember the T in SDET. We aren’t just software developers, we are still testers, it’s in our job title. Its important that we take time to go and explore the system. Find ways to break it. Go back to our roots!
These are some of my sporadic thoughts. I would love to hear your feedback below.