Stealing from Science

The Helix Nebula is 700 light-years away from Earth. The original image was taken by ESO’s VISTA Telescope.

I just finished the short but very powerful book A Briefer History of Time, by Stephen Hawking and Leonard Mlodinow. Space and how the universe works is something that has always fascinated me. I think it’s all the unanswered questions and the urge to understand what it ALL means, and the wonder of what may be out there.

A Briefer History of Time is a result of feedback about the original book A Brief History of Time in which many people requested a more accessible version. I for one am happy this was done as it’s now a great introduction to Hawking’s (and other’s) work which was relatively easy to grasp. Now that I have a taste for it, and a slightly better grasp, I’ll continue on and read his other works.

As I read non-fiction books I often think about lessons that can be misappropriated and applied to software testing. This wasn’t my specific goal while reading this book, but one that lingers in the background all the time. It’s often been discussed that testing can take many queues from science, and specifically the scientific method. I’m not going to try and put a new spin on this, but did have some ‘light bulb’ moments when reading this book that I wanted to share.

Recruiting for testers – a hiring perspective

In recent times I have been heavily involved in hiring testers. This is includes fine tuning the hiring process, screening CV’s, interviews, take home exercises and so forth. It also includes spending time with recruiters. I have found two aspects of hiring interesting and we’ll look at one vital component of the process in this post.

Recruiters

I have found recruiters fall into two categories – those that listen and those that don’t. I have met some very good recruiters who have gone out of their way to build a rapport before trying to sell me their wares. I have appreciated this as I have found that they’ve listened to what we were after (our ‘requirements’ if you will) and we got to know each other better. This is important as testing (and the tech business) is about people after all. An example of this is when I recently spoke at a testing conference in Melbourne, Australia (ATD2K16) – three people from the same recruiting firm came to support me because we had established a very good relationship before hand!

Every Tester is a Performance Tester

…at least to some degree. Well, there are human conditions that distort the perception of time but it’s highly unlikely that you’re one of them. So you are a performance tester too.

The biggest annoyance for a performance tester is to get code into a performance environment that CLEARLY has issues that can be detected by the simplest means available (well.. second most annoying, as finding obvious functional defects is even worse). This is where you as a (whatever kind of) tester come in.

You know the times you drum your fingers on the desk waiting for that spinning wheel in the browser to come back? The batch job where the execution is exactly “making one cup of coffee” long? The usual response from you would be to shrug and say something like “This is just the environment. It’s system test afterall.” or “Let performance testing take care of it”.

Now, I can totally relate to such sentiments! We’re all busy and have deadlines to meet. I’d make the case though that you’d actually help the project as a whole and thereby yourself too by not ignoring such issues.

KWST 2014

A late report from our workshop last year. I stumbled across it again in my preparations for KWST (Kiwi Workshop on Software Testing) 2015. It was supposed to be published through our gracious sponsor, The Association for Software Testing (AST), but it never eventuated. So I thought I’d post it here. Better late than never.

So here goes….

For the fourth year in a row, Wellington (New Zealand) has successfully hosted the Kiwi Workshop on Software Testing. The two-day intensive testing workshop is one of the key drivers of the Context-Driven Testing (CDT) community Down Under.

In its beginnings, the aim was to give the experienced and senior community members a platform to drive innovation and exchange ideas. The impact of KWST in the community over these past years has had far reaching effects in New Zealand as well as Australia.

Workshops, conferences, and magazines have emerged since, which have lifted the game right across the board. KWST 2014 was specifically aimed at involving new faces in the community and not drawing as much on the established KWST crowd.

The topic this year was:

“How to speed up testing? – and why we shouldn’t”

ISTQB Fan-Mail

Not too long ago I received an email from my then CEO bringing my attention to an email he had received.  For some context, I will say that this CEO was very much in touch with all his staff, he wasn’t ‘removed’ in anyway so it wasn’t uncommon to receive an email from him (a brilliant trait I might add).

Upon my first read of the email I thought it was a joke. Have a look for yourself, then I’ll provide some thoughts.

Can we learn from History? [Updated]

Today something wonderful happened (31 May 2013). The Ministerial Inquiry into Novopay has been released. Not so wonderful for Novopay/Ministry of Education/Talent2 but one of the few learning experiences we all have to reflect upon what we do in IT.

A little bit of history. Novopay is the second Ministerial Inquiry into an IT project in New Zealand that I am aware of. The first one was the INCIS project from the 90/00’ies run by the Police. The difference between the two is that this report was actually supported by all parties involved, and it is on a project that actually went live.

Anyway, I don’t want to berate MoE or Talent2. I do want to discuss the general issues I see in  many projects and my take on what it means and sometimes how it applies to testers or testing.

Don’t Kid Yourself

In every project (well, nearly every one) there comes the moment, when testing gets squeezed for time. Immediately the next question becomes how to cut back testing in a sensible way.

The immediate reaction of many a tester (especially if she went through some kind formal training) goes a little like this:

Use Risk Based Testing!

I agree but sort of don’t…

Are we are doing UAT wrong?

SoftEd wrote a blog post about UAT and how hard it was (here). I gave a longish reply and thought it might be good to re-iterate my thoughts on User Acceptance Testing (UAT) here on the blog.

I think the primary premise of what UAT should be, that we have here in Wellington/New Zealand, is wrong.

KWST#2 Test conference is coming!

The second KWST or Kiwi Workshop on Software Testing  with be held on the 15th and 16th of June 2012, Wellington, New Zealand. KWST is modelled on the LAWST style peer conferences and is the only testing peer conference in New Zealand. There are a number of things that make this conference unique:-

• It is an invite only conference – we are looking for industry thought leaders
• James Bach will again be back as content owner and helping grow the core of professional test leadership in New Zealand
• Some of the brightest, insightful test thinkers down under will be there
• Unlike any other conference held here, this is a CONFERence where ALL participants participate!
• The theme is Ethical challenges faced by testers which is relevant considering the prevalence of dubious practices and certifications in our industry

The twitter hash tag will be KWST2 and we will be tweeting all of the great thoughts and ideas that will flow from this conference. See http://bjosman.wordpress.com/2011/06/28/kwst-kiwi-workshop-on-software-testing/ and http://bjosman.wordpress.com/2011/07/08/kwst-kiwi-workshop-of-software-testing-day-2/ for details of last years event.

Author: Brian

Sikuli – for all those hard to reach places!

Ever had the scenario in automated testing, that you had something to automate that really didn’t fit any of your tools? Something that was as bristly as an Echidnea?

Normally I try and steer away from anything that doesn’t use standard protocols and/or interfaces. Things like Flash, Silverlight and others. Not that there aren’t test tools that handle these things but it’s just that it’s messy to say the least. For open standards like HTML or SOAP there are gazillions of ways to automate.

So I got surprised by having to test an application on -or should I rather say through- Citrix.