Excel as a Test Management Tool

Because you're going to use it anyway...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Managing Knowledge Transfer Sessions

Read the article, grab the templates

Ask questions

If you don't ask, you won't learn. You won't teach either.

Friday, 3 February 2012

Get your code up

For testers like me, coding beyond batch/routine like scripting is a bit exotic in the main. In my experience most testers are doing VBScript on you-know-which-tool, maybe some Java on pretty much every tool as it’s the defacto language it seems. There’s a smattering of Python in use but the ardents seem few and far between. Then there’s fan boys like me doing some Ruby stuff all mixed with a smattering of other languages depending on the environment the tester works in.

I guess it’s more like doing testing which involves a bit of coding, instead of coding which involves a bit of testing. It’s great if your role involves you touching code at some point a few days a week. That way you can get your coding skills up and keep them up to. A lot of testers however are looking to start coding so they can develop professionally and of course utilise it for automation, testing, etc.
One problem I found was deciding which language to pick. So, simply put:

Step 1: Pick a language
There’s a multitude to pick from, the TIOBE index (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) is said in some circles to be worthless but if you don’t know what’s out there it’s a good start point for reference.
What are you using at your current workplace? What are they developing in? Well there’s your starter for 10. Is there a particular tool you want to get good at, which involves some coding? Bingo, go learn that then.
There are languages that are flipping everywhere. Java, PHP, VBScript, JavaScript, C, C#, C++ and of course the handy ones such as SQL and Perl that have been in utility use forever.
If you can, pick one that’s going to see you able to use it day to day, ideally one that those around you are competent in too. It’s easier to learn that way.
In order to learn you need to find some trusted sources of tuition, I’m assuming you’re doing self-directed study here and not going on a course. Have a look at www.codeyear.com for example, how about http://www.sqlcourse.com or just searching for “Learn [language] online” and see what comes up. There are too many resources to list but plenty to get started.
Create some form of learning plan and set yourself a goal as to how many hours you’re going to spend learning your chosen language. I picked 100 hours after a suggestion on the Software Testing Club. I have a goal but not a how-many-hours-a-week goal, I study when I can. If you can set time aside then great. Regarding a plan, simply list out what topics you want to learn and tick some off or add some more as you go.

Step 3: Share your learning
There’s nothing better than backing yourself up against a wall, putting yourself in a corner, etc. by telling the world you’re going to learn to programme. Head over to http://www.softwaretestingclub.com and start blogging about your plan and progress.
Also, have a look at www.codepad.org where you can paste snippets of code, then post the link in your blogs. Set up your free Github repository over at https://github.com, there’s an easy to follow tutorial there and it’s 3 commands day to day to maintain your library. Don’t forget to use the Wiki you get to document what you’re adding.
Just get started, whatever you learn will be of use!
Good luck and I look forward to reading your updates.

100 Hours of Testing practice

Just shy of the end of 2011 I started to do ‘100 Hours of Testing Practice’ prompted by a post from Phil Kirkham over at the Software Testing Club. Find his post here: http://www.softwaretestingclub.com/forum/topics/100-hours-of-testing-practice

First question - does 100 hours feel a lot or a little?

It’s an odd one, if you think about how we do on average 40 hour weeks in work then it’s not a lot. If you think about how much time you get to spend on your hobbies/pass times/interests then it’ll take more than a few weeks to get 100 hours in! In those terms 100 hours is a lot.

Either way, that’s the goal that was proposed and that I’m working too. 100 hours which I’ve not decided to dedicate fully to learning Ruby ‘stuff’. By that I mean the Ruby language of course, as I’ve defined it ‘beyond simple scripting, but also automation, frameworks and tools using Ruby.

I decided a few years ago that Java wasn’t the language for me, I did a formal course with the Open University as part of my degree. It was OK, but didn’t get me excited, far too verbose even if it is admittedly ubiquitous and probably a good language to learn career wise. (never say never and all that…). Ruby got me excited, it seemed very learnable like Python but more widely used.

The Blog Posts

Since Phil’s post was essentially an invitation to participate I decided to do so and share what I’ve been doing over at the STC. Each member has a blog space provided so I’ve been blogging my adventures there.

I’m currently at hour 22 of 100 and will be officially ¼ the way through early next week. So, does it feel a lot in reality? Well, yes actually. It’s taken a good few weeks to get this far and on the way I’ve learned a fair bit. I’ve also uncovered a lot I want to look at too.

This is a side benefit, the extent of my ‘view’ on what resources, sites, blogs, books there are has increased. So has my hit list of things to look at!

A little Git!

One other side benefit too is I set up a public Github repository for the scripts I’m creating. Not only is it’s sensible place to put scripts but it’s another tool I’m learning along the way.

Have a look at: https://github.com/MarkCTest/Script-Bucket

Why not join in the fun? Read Phil’s post and get started on your 100 hours, then blog over at STC to keep everyone involved and yourself motivated!

Have fun!