Archive for the ‘testing’ Category
How do you recruit a tester?
We are currently recruiting for a tester at the moment and as ever, this is proving to be a very difficult role to fill. This is partly due to this mentality from development snobs that ‘Testers are Idiots‘. I’ve only every recruited a couple of good testers and quite a few bad ones. They’re a rare breed of technologists.
So what are the properties of a good tester? To be honest, I simply don’t know. However, the best testers I’ve come across are quirky. They do have an eye for detail. They are passionate about technology. They do develop software and build stuff. They do know how to program using C++, or Java, or .NET, or whatever. They are NOT just ’simple’ scripters. They do like to solve complex problems. They are NOT idiots.
But their focus is somewhere else. And this is part I don’t get. I love to build stuff using interesting tech for the sake of it. Just to see how it works. To experience it. To see how it feels in comparison to other stuff I know. That’s the sweet spot. In the end, what I build it is not as important as the tech that I used to create it with. Sure, I get the, that was a cool project and we hit all the milestones and deadlines. But what I’ll take away from the project is the journey, not the destination. And the tech is large part of the journey.
I need to ask that question of a few testers I know and see what they come back with. Maybe that would help. Are testers results-driven? Do they pride themselves in being instrumental in raising the quality of software? Do they like getting the most of teams? Working them and/or working in them? I don’t know.
Now if you’re a tester, not a developer in a testing role, but a tester, I would love you to comment on the above and put into words why you love testing?
Oh, and if you’re looking for a cool place to work, we’re recruiting…
RSpec: automated testing and then manual testing. It works!
I think I have caught the Ruby bug (always last to the party cleve, always the last to arrive!) in a big way. In between my day job, I have been reading (Programming Ruby, Agile Web Development with Rails, Everyday Scripting with Ruby) and writing (currently re-writing clevegibbon.com) Ruby. However, today I was seriously impressed with RSpec.
RSpec has come on some over the last few months. Armed with RSpec, today was the first time I’ve completely writing a bunch of new features for a web site, without once using the site directly. Let me put it another way, I didn’t fire up my browser once when developing the new features. It was all done via RSpec and Rails built-in support for functional/integration testing. And when I was happy that I had spec’d out the features and all the examples were passing, I fired up the browser, traversed to the site and hey presto, it worked as specified. I had to really shake myself, because I was preparing myself for a troubleshooting and/or debug session. I was simply not ready for it working as specified. So I now have time to write this blog entry…
Oh, before you go, here is the rspec for my Rails controllers for my new features (there are also some for the models, views and helpers). You can probably work out what I’m doing by just reading it. Nice!
AdminController for authorised users
- should have access to secured pages
AdminController for unauthorised Users
- should be re-directed to the login page
HomeController for all users
- should allow anonymous users access
InprogressController for authorised users
- should have access to secured pages
InprogressController for unauthorised users
- should be re-directed to the login page
LoginController for anonymous users
- should log in a known user and send them to the admin page
- should not permit unknown users to login in
LoginController for authorised users
- should log them out and direct them to the home page
- should log out users who attempt to login with a GET request
RubyController for all users
- should allow anonymous users access
StuffController for all users
- should allow anonymous users access
Finished in 0.260431 seconds
11 examples, 0 failures
Do you test? If not, why not?
First off, don’t take the question as a challenge. It’s funny how this question has a tendency to provoke developers into shields up mode. That is not my intention. I’m actually very interested in your honest answer to this question. Honestly!
Let me give you my answer to that question. As a developer, I wrote tests for a number of reasons, and none of them because I enjoy testing. Let’s be frank, I’m not that passionate about writing tests, but I do strive to write the best software I possibly can. Overtime, I’ve learnt that this cannot be done without a good helping of discipline and lashing of tests. I write tests because:
- I fundamentally believe that software will fail and in the absence of tests you are just making life unnecessarily hard for yourself.
- Code rots and as it rots how can you refactor your code with confidence without tests.
- I have supported software written by both myself and other developers, and supporting poorly tested software is painful at best.
- If I can’t write a test to verify a piece of functionality I plan to deliver, I haven’t understood the requirements. So right there is my kick up the arse to find out more.
- Tests are a great method of communication within a team - its the first place I go hunting to learn a new piece of software and/or a change in functionality.
So, I do test. More importantly, as I get older I write more tests (memory is not as good as it used to be you see). However, what I have learnt is that not everyone is the same. In fact, people are different! Go figure. You may laugh, but when working in teams you discover just how different people are, particularly around testing. I have worked with some damned good developers who simply will not write tests. So I ask them the obvious question, why don’t you write tests? They reply:
- I know I should write tests Cleve, but you know, I didn’t get round to it. Next time, I promise.
- There is just no time to write tests, we have to build ABC by XYZ, we’ll do it later if we get time. That never happens.
- Writing tests means that I have to maintain the tests as well, I simply don’t have the time for that Cleve.
- We’ll catch the majority of the bugs during UAT, no biggy, so its a waste of time to write integration tests now.
- Tests Cleve - WTF!
With over 15 years working in teams to deliver software, from my experience, the reality is that:
- The majority of developers either do not write tests at all or write a handful of tests after they have implemented the code
- Getting these kinds of developers to write tests is hard work and requires good coaching. It’s not impossible.
- You need to go back to basics, discover testing from first principles and reach consensus (e.g what is a unit vs. integration test, why do this? what have we gained by testing that? what would we lose by cutting this corner?)
- Developers need to experience software failures first hand. The bigger and earlier in the careers, the better.
- All developers should spend some time in the support sin bin and listen to customer complaints - its funny just how many developers have managed to dodge this bullet - and to my experience to their detriment!
So, if its this difficult to get testing working with a team, just imagine how difficult it is put forth the beginnings of a test culture within a organisation, involving multiple teams, projects, customers and countries. This is a hard problem because it requires buy in at so many different levels, agreement around test terminology and its use across numerous technologies, domains and architectural layers. It is a challenge of a lifetime, but it is an important one to address.
So, I’ll ask again, do you test? If not, why not?