What are you doing to keep technical - nothing or something ?

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 "

 

Compare this to TESTHEAD ( Michael Larsen ) who writes about Learning Cucumber and testers getting lazy

 

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

Views: 295

Reply to This

Replies to This Discussion

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

Phil,

Thanks for taking the time to read my post, this is an interesting discussion.

First, a quick rant but I as I wrote about here I have a problem with describing testers as "technical". We can acquire skills in certain technologies in order to carry out our jobs, just as programmers do, but we should discuss these skills individually and not under a generic banner of "technical" testers. You don't hear of programmers being described as "technical" because they know C and not just Java. 

I think that there are two key avenues that we can progress down when looking to advance our skillsets.

The first is to develop skills that allow us to gain an understanding of how our software behaves and interacts with its environment. Relevant skills here might be in operating system knowledge and tools in tracking processes, CPU usage, memory, network traffic, IO performance, File Handles and other resources that our software uses as it operates. I think that developing a strong understanding of the environment in which a program operates is one of the key areas that we can improve on our skills and abilities. Although less well defined that skills such as scripting or programming, such knowledge really help a tester in carrying out their role. It is also easier to justify taking the time to learn this type of skills as they can be related more directly to the testing effort in adding immediate value.

The second avenue is in developing skills and expertise in languages and technologies that allow us to harness and automate the testing effort. I find that these skills are often harder to justify as the immediate payoff is lower, however the long term benefits to the tester and the team can be great. In order to advance in this way requires a commitment to time and effort required for the tester to become proficient enough to add value back into the team. This commitment may come from the employer, if the tester can convince them of the long term value, or it may have to come from the tester themself. A couple of years ago I spent my evenings learning java so that I could develop a multi-threaded test harness for our JDBC interface. It took effort on my part, but once I had the basic skills I could apply these more frequently at work in different scenarios and now have a valuable skill to add to my CV.

In an ideal world we'd get all the training and skills that we need from our employers, however we should not sit back and rely on this. I think that people such as yourself who clearly takeresponsibility for their training and personal development will always stand out as the role models for our profession.

Adam.

----------------------------------------
http://a-sisyphean-task.blogspot.com/
twitter: adampknight
----------------------------------------

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.

Lisa,

 

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!

 

Stephen

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.

Hi Adam - I read your reply above with interest, particularly the operating system/host environment paragraph. Do you have any resources you can particularly recommend for this kind of learning?

RSS

Adverts

© 2017   Created by Rosie Sherry.   Powered by

Badges  |  Report an Issue  |  Terms of Service