You have to believe in change for it to happen

After delivering my talk at EuroSTAR last year about weekly releases I got lots of positive responses, but also some intense negativity and skepticism about the subject.

It wasn’t just “wow – that must be so tricky” it was more along the lines of “you are full of ****” and “what a load of ************ [insert your own expletive]”.

The responses were mostly ones of sheer skepticism combined with aggression. A few people believed it wasn’t possible to release often and that appeared to stir some frustration.

Yet that’s the interesting thing. If you can never picture change happening, or you don’t believe it’s ever possible to move to faster and have more frequent releases then the chances are it wont ever happen.

“It would never work here”

“We could never do that”

“We don’t have the right people”

Three years ago we were releasing yearly and the quality could have done with improving. We could have sat down and looked around and said it’s not possible. But we didn’t.

We believed there was a better way of doing things and we tried.

If you never believe that the development and testing at your company could be better then it simply wont improve.

You (or someone) have to believe things can be different.

It’s my belief that testing standards and best practices are the result of this closed thinking; they assume things don’t change.

The reality is technology is changing all the time, the companies we work for are always changing and the markets we sell in to are always changing.

So couldn’t your approach to development change also? Couldn’t you look for new ways of doing things? Couldn’t you open your mind to a future that different?

The product you test can make or break you as a tester

No product domain is better than any other, but we do each have preferences and favourable products to test. We each prefer to use, test and work with some types of products over others.

When I was testing products I didn’t enjoy I wanted to leave software testing. Period. I wanted out. Software testing sucked.

Sure, the environments/methodology these products were built in didn’t help, but ultimately I didn’t have an affinity to the product and this made me think that the trade of software testing was at fault.

I didn’t understand the product. Actually – let’s be honest, I didn’t *want* to understand it – it held no interest to me. I wasn’t interested. It didn’t make me feel curious about how it worked.

I actually thought I was rubbish because of this.

I realized over time though that it wasn’t me though. I was OK. I was a naturally curious person, just not about some products. It was the product – it wasn’t me.

I’m not curious about things that don’t interest me. However, when I find a product I like and a product I understand I flourish. I become a good tester. I am curious. I am interested. I am engaged. I want the product to succeed. I become a product evangelist. I want to know how it works, why it works and how useful it can be.

I’ve met so many testers over the years that hate testing. Or at least they think they do.

When I ask these testers what their favorite product is they always have an answer. When I ask how they use the product and how the product works they can always answer me. When I ask what it must be like to test a product like this they get wild eyed and passionate about that testing job. And when they notice this enthusiasm in themselves they soon realize that it’s not testing they don’t enjoy – it’s the product that they are testing.

I don’t have an interest in testing transactional banking, insurance products or defense products, some people will thrive testing these. I prefer cloud/hosted/web services that have communication or social interaction at their heart, some people would loathe to work on these products.

So if you’re feeling down about testing and you’re finding you’ve lost your testing mojo it might just be related to the product you’re testing.

It might not be you. It might not be testing. It might just be the way you feel about the product you’re testing.

Shine a light

Most software testing, in my experience, is rushed and often under time pressure, typically driven by a desire to meet a metric or measure of questionable value. Yet to rush through the testing of a feature or product is to often miss the changing nature of that product (or your own changing nature).

If you are testing a capability of a product and look at it in one way (say with the mindset of trying to break it) you may find several issues. If you shine a light on the product in another way (say with the mindset of trying to use the product really quickly) you may spot other issues.

Also, if you test the product on one day you may miss something you may spot on another day. You change (mood, energy, focus) all the time, so expect this to affect your testing.

The product likely hasn’t changed, but the way you see it now has.

Tours, personas and a variety of other test ideas give you a way of re-shining your light. Use these ideas to see the product in different ways, but never forget that it’s often time that is against you. And time is one of the hardest commodities to argue for during your testing phase.

How much time you will need to re-shine your light in different ways will mostly be unknown, but try to avoid being so laser focused on completing a test for coverage sake, or reaching the end goal of X test run per day, that you miss the serendipity that sometimes comes from simply stopping and observing and re-focusing your attention.

Creating a test lab

This week sees the development team moving in to new offices. In these new offices is our newly created test lab. A room for testers to hang out and also a place for us to keep our supported devices.

There’s loads of work to do to get the test lab functioning and adding value for us.

It’s been lead by Raji (Twitter – @peppytester) and Andrew (Twitter – @coyletester)

We’re in a good place with our test environments as they are hosted, just like our great call centre product, in the cloud so we don’t have to store or house our physical servers here in the office test lab.

However, we need to make phone calls and connect via the web hence the test lab – a place to do this, but also a place for the team to get together to do our regular regression testing.

We have the capacity to do our testing with these devices already, but they are localised around individual testers with devices often locked away in a drawer somewhere. Not good for the collaboration and sharing we need to do now as we grow much much bigger. The lab is a way of getting a centralised set of kit, a place to test and a place for us to come together to talk about testing, our test approaches and our supported devices.

Test Lab
Test Lab

Here’s some “starter for ten” goals/requirements we’ve identified for the lab. Obviously the specific details are not listed here but they give you a flavor of what we’re aiming for.

  1. All supported devices and phone carriers must be available in the lab. (i.e. if we support it – we need to test it)
  2. All devices should be charged and ready to use. (i.e. there’s no point needing a device/phone and then having to wait to use it because it’s got a flat battery)
  3. All devices should have a shared folder or other sharing faciltiy on them (Evernote notebook is one example of how we can share screenshots, findings and notes).
  4. The devices must not be plugged in and charging 24/7 unless they are being used. (Although the devices need to be available we don’t want to destroy the planet by charging them all day everyday when they are not being used. We’ll experiment with timers to give them a burst of juice to keep them functioning and tweak it to get a decent balance.)
  5. At busy periods it must be possible to book out devices, but this booking system should be a last resort, and should be a friction free as possible – a casual approach to sharing the devices should be sought first before booking forms and other waste are introduce. (i.e. it takes time to fill out forms, book things and deal with the “paperwork”. What if you just want ten minutes of usage…it’s a massive overhead to book it out. Add this overhead if needed but let’s see how it goes first)
  6. All devices will be connected to the network, clearly labelled (resolution, network, IP address etc) and available in the right place (i.e. people put them back where they come from)
  7. The phones should be included in our generic “default” call plans meaning all testers know where to get extra devices and phones from (i.e. when needed people should be able to easily add these devices to their accounts and gain access to them)
  8. All devices should have quick, one step log in and access (i.e. unless security is compromised let’s make it as frictionless as possible to use these devices and phones)
  9. A monitor showing NewRelic (plus other test related data) should be available in the lab. (i.e. data informed testing and feedback from your testing are key to the right focus)
  10. All default call plans and test accounts should be well documented and easy to follow meaning new starters can rapidly learn how to get on clouds quickly. (i.e. make it quick to get testing in the lab)
  11. There should be a number of network ports and power sockets available to house groups of testers doing testing. (i.e. when a group of testers (what’s the collective term for that???) get together is there enough power and cabling?)
  12. All test related books should be relocated to the test lab (i.e. when we need inspiration it should be there)
  13. Elisabeth Hendrickson’s cheat sheet will be available – ideally blown up and made to look freaking awesome. (i.e. ideas for testing should look good as well as be functional)
  14. The test lab should remain looking neat, tidy and welcoming (i.e. clean, simple, tidy and functional environments help to clear the mind for focus on productive stuff)

And there we have it. A starter for ten. But something to head towards.

I’ll keep you posted, as I’m sure Raji and Andrew will on Twitter about how we get on.

What do you all have in your test labs?