Can someone be a good automated tester and be terrible programmer?

Question

I'm currently working as an automated tester. Mostly I do GUI testing in SilkTest, which I like and think I'm fairly good at. Recently, I've been assigned a COM-testing project for our application's API. This involves coding in C++ with some more low-level concepts (pointers, manual memory management, complex data types, etc) than I've done previously in this role. Now, I have done some C/C++ programming in the past, and I'm getting through the project, but it does make me question how good of coder I am since I'm still making elementary mistakes. Is this acceptable? Does this in any way take away from my skills using higher-level languages and tools like Silk or Perl?

Answer 1

I think you're selling yourself short, here - you've said that in a language and skillset with which you're familiar and current you do well, but you're struggling with a language and skillset you have worked with in the past but where you've become rather rusty.

That's normal. Seriously. Automation and programming are complementary skills but they're also domain-bound. If you're not practicing in a particular domain (like interfacing with COM objects using C++), you lose the instant grasp of a lot of the basics and need references or assistance to get that back. You'll also be slower.

If you're not maintaining your Silk and Perl skills, you'll find when you return to them that they won't be as fluent as they were before you started this project. Again, this is normal.

Don't fall into the trap of thinking that because you're good at one specific area and you understand the principles means you'll automatically be good at other specific areas. There's always a learning curve to any specific application of testing principles and automation (and coding) principles.

Right now, I do most of my automation coding using TestComplete and DelphiScript. I have worked with the C family, Java, VB and the script versions of all of these, but I wouldn't expect to be able to pick up and code any of them immediately because I haven't used them in quite a few years. I would expect to get better at working with them, but not instantly or even (necessarily) quickly, depending on the situation I was in and whatever else was placing demands on my time and energy.

In short, your skillset would appear to be more than merely acceptable, and the fact that you're producing results indicates that you're learning enough to keep things moving in your position.

It's great that you're wanting to improve more and more quickly, but don't forget you're just as human as everyone else here (I think. As far as I know there aren't any robot contributors here... Sorry. Strange sense of humor).

Answer 2

"Good automated tester" and "terrible programmer" are judgments made in the context of a myriad of circumstances such as the subject's previous experiences, the task at hand, the simultaneous background work, the company environment, the team dynamics, and tools.

One may be a good automated tester in one context and a terrible automated tester in another. Similarly, one may be a terrible programmer in one context and a stellar programmer in another.

You cannot learn without making mistakes. I suggest you throw away the self-defeating labels and allow yourself to go through the learning process. Each of us learns at a different pace and in a different way. Pay attention to what you do, be honest about your mistakes, and give yourself time.

Answer 3

Elementary mistakes? You are too hard on yourself. I applaud you for stretching your skillset. Don't give up.

Answer 4

You sound like an unusually good programmer for an automated tester, and this is undoubtedly why you were trusted with such a difficult testing task. Most dedicated programmers who use higher-level languages mostly would also stumble badly at first if they suddenly had to work with unmanaged code, even if they'd used unmanaged code at some point in the past.

While you are learning these new skills, you can take steps to control the quality of your automation so it's easier to maintain later. I would recommend finding a developer who is willing to mentor you and provide code reviews. If this is difficult on your own, you may need to ask your manager to help you locate someone who can code review your work frequently (and it may take managerial influence to convince developers that this is a good use of their time, depending on your team dynamics). It is very reasonable to let your manager know that you have mostly developed automation in high-level languages, and want your COM API testing code to be of equal quality, even though your skill set with C / C++ is rusty. You can also point out how having a dedicated code reviewer will also help you re-learn these lower-level language skills more quickly.

If someone at work is implying that your mistakes mean you are incompetent, you need to push back and market your willingness to learn on the job and expand your skill set. Keep a confident smile on your face, thank them for sharing their concerns, and help your management remember why they chose you for this task. You, specifically, were asked to do this for a reason.

Answer 5

To answer the question posed in the subject: yes. I say that because I know first hand that it's true in reverse: I'm a pretty good programmer and simply cannot do testing (automatically or otherwise) on anything I write in an effective manner.

But the question in the body isn't actually the same as the one in the title. C++ is not the simplest language out there, and neither is COM interaction with it. Programmers who haven't done it in a while or have never done it will screw it up, no matter how good they are. If pointers and manual memory management were easy, we wouldn't have so many common mistakes using them still and we wouldn't have managed languages that try to take over control of that stuff. Much like anything else it gets easier with practice.

As for it affecting your use of higher level languages... not really. It certainly doesn't hurt, but indepth C++ knowledge isn't necessary to use Perl.

Answer 6

OK so you're working with some low level C/C++ concepts, yes they are tricky and you do have to hit the books and study your way to understanding.

On the complex data structures; if they are proprietary to the problem domain in which you are working then the quickest way to gain mastery of these is to pair with a colleague.

Write small unit tests as you progress to test your work and simultaneously learn your craft. Automate the running of those tests.

And finally, keep the faith and stick at it, your bit of self doubt is an indicator of your conscientiousness which no doubt your employer values; in pseudo code

while (!(succeed=try()));

(pseudo code borrowed from website that sells t-shirts and tech toys to ruminating geek masses)

Answer 7

Well C and C++ are hard. Many Software Engineers who have not written any C or C++ code in a few years would make elementary mistakes so don't be too hard on yourself. Even the fact you are on Stack Exchange asking these questions means something.

Answer 8

I think when it comes to judging about someone if he's a good programmer or a good automated tester, the important thing is how mature the process to tackle a new problem is. The average programmer will have a solid understanding of a specific domain, lets say persisting objects with hibernate in java, after having to deal with it in several projects.

But i don't think that there are many people that do only one specific thing in their career. It's how one learns to learn new things quickly (and safely = not causing production errors). Furthermore, how much of a broad overview of the concepts that are included in the problem domain.

I've been programming in java for quite a while now which does not mean that I can write code that never throws a NullPointerException, i just learned to write tests for that.

Answer 9

Making elementary mistakes is always acceptable when you notice those mistake. Silk (4Test) and Perl (I have this skillset too!) is more high level languages. This languages are much easy then C++. When you do mistake in Silk code – it is not so important and you always can fix it, because it is not a production code. When you programming in Perl – you do not need to think about some additional array boundary checking or exception handling and so on.

But, even when you are programming in Perl, you have to think in Perl and follow the best practices for that particular language. The same think is about C++. When you are programming in C++ you should not think in Perl, but learn how to think in C++. You cannot open file in C++ and die if this operation fails. And you should not use hashes everywhere, because you have to use classes in C++. Thinking in C++ requires a lot more time. And this situation is complicated with COM that is not so easy too.

In my past project, the new developers have to write tests in C++ and COM for our application API for about a year. And only about a year of doing such testing, the senior Developers allows them to write some small production code.