Just read two blogs with a common theme:
Adam Knight posted about interviewing a tester who only had skills to a tester level
Steve = 'the Agile Tester' posted about leaving testing after 12 years and wrote
" my technical skills will have to improve massively "
Dont wish to re-ignite the 'should testers be able to code' debate, just wondered what people were doing to keep their techy skills up to date, if anything, and if they were doing anything do you only keep it to a 'tester level' ?
Me ? Currently working my way through the Rspec book and got RubyMine from JetBrains so I can get better at Ruby
Thank you for all four of those links - awesome insights into this topic, which is one of my favorite soapboxes to stand on.
What do I do? I challenged myself last Feb. by participating in a CodeRetreat. My coding skills were not up to the task (even in Ruby, which I actually use some), but when I took the facilitators' advice and only paired with highly skilled TDD programmers, I found I was able to contribute good design ideas even if I couldn't write the code. What did I learn? That we have to practice our skills. We don't have so many opportunities as programmers - there are not so many testing dojos or katas.
However, one good way to practice is Weekend Testing or Weeknight Testing. I've participated in a few Weeknight Testing sessions, usually pairing with someone across the ocean. It's great practice, and I pick up a lot of new ideas and techniques. Most importantly, I meet a lot of cool people from whom I can learn lots in the future.
I participated in a testing dojo facilitated by Markus Gaertner at Belgium Testing Days, another great learning and practice experience.
Last year, I switched from using the Eclipse IDE to IntelliJ Idea, because everyone else on my team uses IntelliJ. It was harder for me to learn to use, but now I feel I can communicate better with my fellow developers.
I'm just finishing up Bob Martin's _Clean Coder_, which ALL of us should read. He is spot on about what it means to be a true professional.
All that said, though I love to automate tests, and I keep working to learn better ways to design them, I have come around to Gojko Adzic's view that test automation is generally best done by the programmers who also write the production code. They can automate in a fraction of the time that even a "techy" tester like myself can do it, they have the design skills to create maintainable tests with a good ROI, and they are able to design the code to make test automation easier. There are exceptions to this, but generally, if testers and programmers collaborate on testing activities, each can contribute their best skills, and everyone ends up with time to add maximum value.
So, though I enjoy building my more technical skills, and find them useful, I also need to specifically build my testing skills, because that's where I can help my team the most.
When I started my current job, I found it useful to be come the local "expert" on server installation, configuration, and maintenance, including various Windows server versions, Apache Tomcat, and various SQL Server versions. I have secure Apache installation and configuration as a future task (still have to beg the developers for help).
I already knew VBS scripting for GUI automation, but I've decided to download Eclipse and learn basic Java application development. That will allow me to investigate setting up a prototype BDD environment to demo to the developers and management. My goal is to eventually set up a "read only" dev environment on a VM server to explore various BDD tools with our current Java application.
IMHO, this isn't a preference - it's survival. Thanks for posting this!
Over Xmas I too downloaded Eclipse and was working my way through the Agile Java book - it taught me something about Java, something about Eclipse and gave me a glimpse into TDD with writing tests then code then refactoring
Adam, I admire your ability to write a multi-threaded test harness for your JDBC interface, but I'm curious. Was there no programmer on your team (or at least, on the development team, if the test team was separate) who could do this? And if so, couldn't that programmer probably have done it a lot faster, freeing your time to think of what scenarios to test with that new harness, and actually doing that testing?
I believe we must get away from this notion of testing as a separate phase and separate activity from coding, and get the whole team taking responsibility for quality & testing activities. Then we can collaborate and maximize the usefulness of the skills we are best at.
It is a good point and possibly yes this is an activity that could possibly have been done more quickly by someone else, but it was something that I wanted to do to develop my java skills.
I spent a few evenings of my own time working to get the basic linear test structure set up. I then worked with one of our programmers to understand the threading structure required. Then it took about a day to get the harness finished. I could have saved some time by getting someone else to do this but this would have missed part of the point of the exercise, which was identifying an opportunity for me to develop my own skills whilst adding value to the team. As a C house java is not our main programming language, but we do expose java interfaces so having another person with java knowledge able to interactively test against these interfaces was worth the additional effort of doing the work myself.
Hi Adam, that makes sense. You were doing this as much for your own learning, to increase your future ability to help the team, and you were capable of mastering it. Not only did you increase your skills, I bet you enhanced your ability to communicate with the programmers, as you understand Java better now.
In the past, I've spent a lot of time learning some vendor GUI tool and automating tests with that, with no help from the programmers (didn't even occur to me to ask). I learned a new skill, but it wasn't all that useful since the production code was written in a different language. I have enough programming skill to create decently maintainable tests. However, I now rue the lost opportunity - I could have used that time for something more useful and important to me if I'd have thought to ask the programmers to help solve the automation problems.
This is something that I have realised and had brought home to me more and more recently. It is better for me to ask for help from a developer to write me a test harness than it is for me to write the harness myself. I can sit with the developer to produce the app that I need but ultimately the job will be done much quicker and more efficiently if a developer does the work.
As far as my own development goes I am learning Selenium at the moment so I can test web apps better and also SoapUI. I am really enjoying the experience actually. Most of this learning is being done in the evenings and I apply it when I get into work the next day!
Don't you think that doing some amount of that kind of work helps you increase your understanding, even if you might save a few hours?
I'm a bit wary that "get the devs to do it" if taken to the extremes may be a case of optimising a part of the work and losing something from the whole - the most efficient way to get something done isn't always the most effective thing to do long-term, sometimes it's worth having someone slower at a task do it occasionally because it increases their knowledge and helps them be more effective in other work they do. (Otherwise we'd never ever hire grads or juniors - why bother training anyone when a senior can do it much more quickly?)
Example of this:
I tested a small additional feature to one of our services recently. The Java developer working on the feature did something I thought was pretty smart: she wrote the Fitnesse tests she needed while developing, but left a couple undone for me to complete - even though she could have put them together in a few minutes - because she said "I thought it'd be easier for you to pick up what was going on if you'd actually had to put some of the Fitnesse tests together, rather than just reading what I'd done". She was absolutely right - I wouldn't have understood it as well (it's easy to kid yourself you understand something when you're just reading it, whereas actually trying it reveals pretty quickly that you have holes in your understanding.)
Anna, that's an excellent point. I'm certainly not trying to pigeonhole people or put up more walls in between "roles". In fact, the roles are blurring more and more, and that's a good thing.
Your example is just the sort of collaboration I would like to see on all teams.
I need to formulate a better way to encourage better communication between testers and programmers, and nurturing a learning culture while avoiding pitfalls such as someone creating a bunch of unmaintainable tests, then saying "Look, test automation doesn't work."
Very well said Anna. +1 to the reply.
My technical learning -> I have got myself a big fat "Head first Java" book. I like the way the book is written. Plan to complete it by November and start writing my own small tools to help with Session based testing.