Testers Learning To Code

One of the topics that always pops up in conversation with Testers is whether or not we need to know how to code.

I think a lot of this depends on your context and your career goals and aims, but really it pays to at least understand how the code is hanging together and to get a sense of what it’s doing. It would undoubtedly be useful to code at a basic level to help build tools and programs to help you and also to crack Test Automation (i.e. not relying on Record and Playback as your strategy).

I often hear the excuse that there isn’t time to learn, but I don’t think this is true. I think we could all snaffle 10 minutes a day to work on some code. The time argument depends greatly on the importance you place on learning to code. There are lunch times and after work and weekends too.

One of the things we’ve got set up within our team is two 30 minute sessions each week where the whole test team sit together and work through coding katas with our tech tester and programmer. It works really well but still needs each Tester to spend a little extra time each week re-enforcing the learning.

I thought I would collate together some resources that might help and inspire you. Oh yeah, and deciding which language to learn is often the hardest decision. I can’t offer any guidance on that really, it’s what works best for your environment, your product, your goals and your interest in each language.

So here are a few resources I’m finding helpful:

So you want to learn programming basics?

There are loads of resources for learning basic programming (try a Google search for it) but the one that stands out from the crowd is Code Academy. It’s a great interactive tutorial teaching you the basics using JavaScript as it’s main language. The lessons are short and the guidance is awesome.

So you want to learn Python?

Python is a really powerful scripting language and you would be surprised at how many of your favourite sites are running on it on the web.

There are a number of great resources available on Python but one of my favourites is this very straight forward guide called “The Programming Historian“. The lessons are kept simple and you’ll be writing Python to manipulate files and text in no time.

If you’re in a .Net environment then IronPython might be the way to go.

So you want to learn C#?

There is a pretty good course here at Programmer’s Heaven on C# basics.

CSharp-station also has some good tutorials.

 

So you want to learn Java?

By far the most relevant and intuitive book on Java for Testing is Alan Richardson’sSelenium Simplified“. The guide is very straight forward and in no time you’ll have some tests running on your web site. It’s obviously aimed at getting you started with Selenium but Alan introduces you to Java as part of the journey.

Update – Alan has also now released Java For Testers. Head over to the site and check it out.

Here is an introduction to Object Orientated Programming in Java.

Learn Java Programming with Green Foot. This is a really great program for learning about Java and Object Orientated Programming. You get to build a world where Wombats eat leaves. Great fun.

So you want to learn Ruby?

I would recommend to you dive straight in to Brian Marick’s excellent book “everyday scripting with Ruby“. It’s partly aimed at Tester’s so it’s a great read.

Ruby for Kids is very cool also. Don’t be put off by the title. The lessons are great and the basics can be learned very quickly indeed.

 

Why’s Poignant’s Guide to Ruby is a cult classic in the Ruby domain. It’s a crazy story that introduces Ruby and general programming ideas. I actually enjoyed reading this. It’s a PDF –> http://www.rubyinside.com/media/poignant-guide.pdf

Ruby in Twenty Minutes offers snippets of learning. A good resource for getting started and getting it all installed etc.

If you’re in a .net environment but still want to use Ruby then check out IronRuby.

Each of these languages is typically coded in an IDE (Integrated Development Environment) although you could also use something low tech like Notepad. A good list of IDEs is here on Wikipedia.

There are also other languages I’ve not covered here like PERL, PHP, C++ and many others.

Any other sources I might have missed? Let me know in the comments.

Test Bash > Done

It was so great to be part of the Test Bash last Friday in Cambridge. I for one had a great day and I’m so glad that others did too.

The feedback we received about the event was great and it was clear from the vibe throughout the day that people enjoyed themselves, mingled and generally felt connected with others.

I’d like to thank the speakers for such an awesome day:

David Evans
Alan Richardson
Ben Wirtz

Steve Green
Huib Schoots and Markus Gartner
Adam Knight
Andy Glover

I’d also like to thank the attendees who brought such enthusiasm with them. Our sponsors MagenTys and QASymphony. And of course our community members who helped out on the day.

The venue was superb  and the food delicious. Me and Rosie were more than happy with how it went and we were thrilled to see Twitter buzzing and of course, Markus Gartner live blogging*.

We ran the Low Tech Social Network throughout the day which brought people together to connect with those who shared similar interests and hobbies. I witnessed a number of people seeking out others with the same hobbies such as surfing and fast cars and then talking testing with them. That’s the point of it; connections to people you might not normally talk to. Fantastic to see this in action.

Test Bash is a celebration of connectedness, community, creativity, ideas and most importantly, the sharing of these ideas in a safe and trusted environment. We saw loads of good ideas being bounced around and it was amazing how many people felt safe to share and talk about testing openly.

It was also great to finally put a face to an online name. It was good to meet so many people I already knew in the digital world. It was also great to meet so many new faces. I only wish I had more time to chat testing everyone.

Events like the Test Bash fill me with positivity. They make me realise that Testing isn’t a battlefield of right versus wrong. Instead, it’s a melting pot of ideas; some better and some worse depending on what context they find themselves in. There were some frank discussions and opinions aired, but the collaborative nature of the event meant these discussions were constructive, useful and open for all to experiment with.

I didn’t hear the words “Best Practices”, there were no certification bashing, nor evangelism, discussions nor were there any discussions of “my way or no way”. It was a day of optimism. A day of hope for our often negative and frequently argumentative domain.

It was also a great day of learning and a great chance to get together to talk about what matters; new ideas for testing.

And this, in a sense, is what me and Rosie and our community managers work so very hard for. These moments where people connect. Where people share ideas. Where the craft of testing is pushed forward. Where there is real hope of a shift from “one size fits all” testing to a value driven activity across all stages of the life cycle.

Yet, throughout all of this I couldn’t help but notice something blindingly obvious; even within our own industry we have wildly different ideas about what testing is and who is in actual fact a “Tester”.

I don’t think this is a bad thing. In fact, I think it could be the most amazing part of what we do and who we are. We get to do what we think is right. We get to add the value we are employed to add. And that means we’re edging ever so slowly away from the long held stereotypes of Testing and Testers.

We get to nudge our craft towards the future we want for it. And that’s a pretty cool thing.

 

 

* There is no one in the business faster than Markus for blogging. I swear he had posted the final remarks before the speakers had even uttered them 🙂 :

http://www.shino.de/2012/03/23/testbash-survival-of-the-fit-tester/

http://www.shino.de/2012/03/23/testbash-an-8-layer-model-for-exploratory-testing/

http://www.shino.de/2012/03/23/testbash-the-tale-of-a-startup/

http://www.shino.de/2012/03/23/testbash-the-evil-testers-guide-to-eeevil/

http://www.shino.de/2012/03/23/testbash-visualizing-quality-a-random-walk-of-ideas/

 

Book : Designing Data Visualizations

I’ve just finished reading Designing Data Visualizations by Noah Iliinsky and Julie Steele.

It’s a very relevant book to many as we strive to communicate the growing amount of data we are capturing. The book introduces the many different types of data visualisations including infographics and the use of charts, tables, graphs etc. The authors spend a lot of time explaining the reasons behind the visualisations which is very important, but often overlooked in other books. There is lots of information about colours, fonts, audiences and purposes and the channels used.

The authors support each piece of information with examples and external references, which adds lots of credibility to their arguments. There are some really insightful ideas and a lot of examples of good and bad visualisations which help make each point easier to understand.

It’s great that the authors spend time talking about colour blindness and the psychology behind colours, locations, shapes and proximity. I found this chapter incredibly useful indeed.

At times it felt like the book repeated itself, especially in the first few chapters. I got the sense I was reading the same information again, but thankfully the later chapters made the content more distinct.

Overall this is an easy to read and fun book that gives you the background, insight and tool ideas needed for you to get cracking with building visuals. Very good book indeed.

 
This post is part of the Oreilly Blogger review process.

Data Geek

I’m a big fan of gathering metrics about my own activities.

It allows me to look at trends and patterns about my own behavior either for self-improvement, or to simply understand more about the things I may have often taken for granted.

I’ve also found tracking my Testing activities and some of the metrics that go along with that incredibly valuable. I know at what time of the day I am most productive, what sort of music brings out the best Tester in me and some interesting data points suggesting I find twice as many bugs per Testing session when I work from home versus the office.

Freak! I hear you shout. Yep. Maybe.

I’ve “quantified” myself for many years now right from how much I spend each day to my fitness routine. (or lack of)

In the work place I don’t live by numbers, for example progress based on No. of Tests executed, or any other crazy metric some teams may be governed by.

But I do like to look for trends. Trends and patterns can show me interesting things. I want to know how many times a story or defect has been bounced back from Test, even more so for groups or clusters of stories over periods of time.

I want to know how long on average it takes to spin kits to out test environment over X number of days. I want to know on average how many kits are good versus how many are bad. This shows me useful data that can start further conversations with, nothing more than that.

With data points, trends and patterns I can start to look at underlying problems (or enablers) and do techniques like “The 5 Why’s” to get to the root cause. Single sets of numbers often don’t offer insights like this, they can be flukes, anomalies or unrepresentative. Numbers gathered over periods of time offer more credibility (although could still be invalid or incorrect).

So I thought I would share with you two of my favourite tools for tracking data.

  • Daytum
  • Your Flowing Data

Daytum

Daytum has been around for quite a while now. I love Daytum because it lets you create almost any data combination structures you want and gives you a nice simple interface and some neat graphical displays to choose from.

I’ve been using Daytum for some time for personal stuff like expenses, items I spend money on, miles run, etc etc.
For Testing I’ve experimented with data such as “Sessions completed”, “Bugs per session”, “Bugs per sprint”, “Most Bugs Per Music Genre” and all-sorts of other crazy data that might lead to more insights in to my Testing.

Your Flowing Data

Your Flowing Data (YFD) YFD is a new one for me but I’m really liking it.

It’s proving pretty awesome at capturing all types of data for me.

The killer feature for me is that I can do all of this from Twitter. I can send a DM to YFD from my Twitter account and it records that data for me. This is a neat little feature. You can still enter data via the web interface also.

The data can be graphed or exported for further manipulation which gives it a great level of flexibility. There are more graphs being added too as well as the ability to export your data out to a spreadsheet.

Want more?

There’s also Me-Trics, mycrocosm, grafitter and beeminder (more goals related)

If none of the above sound cool, then how about trusty excel, or a whiteboard with stickies on it?

For a data geek like me though, these tools allow me to shift my focus towards understanding people and behaviours, and how these different behaviours may interlink and relate to each other. From this data I can start to see patterns, stories and trends.
And I really quite like that.

New Home

This is my first post directly to WordPress. So it’s partly a test and partly to let people know I have changed my blog platform.

Those following my old Posterous URL will have received a post with a new url, and those who have always followed at thesocialtester.co.uk will just start to receive posts from this WordPress blog.

I’ve been a little quiet on the blogging front recently but that’s because I’ve been writing lots of cool goodness for the community and also prepping ready for this weeks Test Bash in Cambridge.

Hoping to catch up with a few of you there.

No Test Case, No Bug

A while ago I remember Phil Kirkham mentioning that he’d found a bug that “fell” outside of the Test Cases he’d been given and someone was arguing that it wasn’t a bug. I found it incredibly interesting that someone would dismiss a serious bug because it was not found as part of a test case.

The test case is an abstract, it’s something we create to guide us (mostly), yet too many people take the test case to be the testing. The testing is a human process. The test case is a guide, an artefact, a crutch, something we may *have* to create, a container of information, a checklist or any other supporting element to our testing. The test case itself…is not testing.

About a year or so ago I wrote a short eBook on the problems with Testing. I set the main Test Manager character in a company who valued process over actual results. That process over results was similar to what I believe Phil saw.

This was originally going to be a decent sized blog post about process and test case management. Instead I thought I’d spent 5 minutes hacking together an Xtra Normal video to see if I could get the point across with animated characters instead (I also wanted an excuse to have a go at an Xtra Normal vid). (BTW – The Evil Tester did an Xtra Normal video here : http://www.eviltester.com/index.php/2010/03/03/hey-you-are-you-a-tester-the-m…

My video is by no means an award winning video, but it was actually quicker than writing out my thoughts. I think it conveys a similar meaning.

I’ve always wanted to be a film director too. I’ve got a lot of work to do to make that a paying reality 🙂

http://www.xtranormal.com/xtraplayr/13134755/no-test-case-no-bug