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 Social Tester Newspaper

I was digging through my archives and stumbled across the original The Social Tester newspapers. I wrote two editions. Click on the images below to open the PDF version of the newspaper.

(BTW – They aren’t true stories.)

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.

A New Year – 2014 Goals

I’m officially out of my self imposed social media hibernation. I tend to creep away from my online presence and catch up with my family over December and January. It’s time to venture out and start interacting again.

I have a load of new and exciting goals planned for this year. I’ve spent the last week doing my planning and plotting for this year, as well as a review of last years goals.

I normally hint at a few of my goals via this blog and on twitter but this time around I’m planning on making my goals more visible. It might make me commit to them further 🙂

So here are a few things I’ll be doing this year that are relevant to those interested in software testing.

Goal 1 – Actually post stuff to my blog

Right now I have 233 blog posts in draft.

Some near completion, some with barely a few lines of ideas.

I suspect some of them will get deleted; they will be either too cutting edge, too ranty or too boring. So I guess I’ll have about 150 to post out on my blog by the time I’ve culled them (and allowing for new ideas to emerge).

There is a theme this year.

The theme will be “hiring testers in to a rapid release development team”. I will explore what it takes to find and hire good testers, but I will also explore some ideas around cutting down the silos between functional roles and creating a more holistic fast paced development team.

Goal 2 – Release “Idle Thoughts On Test Management”

My first book, Remaining Relevant and Employable, has done pretty well despite little promotion.

I actually got side tracked writing Remaining Relevant when I should have been writing Idle Thoughts.

I’ve got the basic chapter headings and quite a lot of content, but I won’t be making it public for a few months yet. I will be using LeanPub again to publish this second book. Expect this book to be minimalist and cut down. I want it to be succinct and to the point.

Idle Thoughts is basically a collection of short stories and essays from my time as a Test and Development Manager. Fulfilling many roles through my career (technical author, tester, support engineer, manager, scrum master, agile coach/consultant, etc) has allowed me to blend all of this experience together. I hope to be able to offer some interesting and unique views about test management. Consider it part observation and part experience report.

You can see some of the research content I’m collecting over at my Idle Thoughts Postachio blog. The posts on that blog will arrive in flurries, as will chapters for this book on to LeanPub.

Here are the chapters I’m going to be writing about. I’d be keen to get some feedback as to what else you may want to read about. It’s not complete yet, so expect the following to change somewhat. (Bold and underlined are section headers in the book)

Communication

        • Purpose, Audience and Context – the basics of communication
        • Communicate 10 x more than you currently do
        • Time your communication right
        • Communication doesn’t happen through a process tool
        • Primary, secondary, or made up information source?
        • Active listening for test managers
        • It’s active content, not static documents
        • Don’t skip face-to-face communication
        • Private blogging for sharing of ideas
        • Don’t sit on information, it won’t make the team richer
        • How to run a good meeting
        • Broadcast important stuff, but only if you need to
        • Selling testing
        • Build a communication plan
        • DUJWC (don’t use jargon when communicating)

Productivity and Learning

        • Be Quick and Nimble
        • Environment efficiency
        • Create a practice plan
        • Follow your intuition
        • Busy does not mean productive
        • Where does your day go?
        • Don’t take on too much
        • Stop people burning out
        • Learners will inherit the world

Life

        • We can’t all do what other people can do
        • We are all great. But realise your limits.
        • No job will last forever. Projects are the future.
        • It’s not good. It’s not bad. It just is.
        • Empathy

Process

        • Lean Testing – A myth
        • What a lot of tests, but which one shall I run?
        • Don’t worry about the solution. Work out what the problem is first.
        • Draw a frame and place your testing inside it (but don’t be bound by it)
        • Don’t adopt every technique without pause for thought (sometimes just a few techniques are more valuable)
        • Copy what other people do, where relevant
        • Don’t master an approach or technique just to say you’ve mastered it.
        • The team are testing, but is the product getting better?
          • A difference between intent and outcome
        • You’ll never know whether a team will work until you put them together
        • Teams are not perfect.
        • Look for times when your testing doesn’t work
        • Do you have a vision and purpose, or are you just getting through the day
        • Make decisions. Decision makers are important.
        • With a wider awareness you will be surprised less often
        • Apply constraints – they breed creativity
        • Standards versus trial and error
        • Norms are for breaking. Sometimes.
        • Allow time for innovation
        • People will game the system (if they want to)
        • Leading edge metrics
        • Improving the process is one of your main goals
        • Always go and see for yourself. Or trust your proxy.
        • Test artifacts are an output, not a strategic direction or end goal
        • A test plan is not your testing. A test case is not your testing. The testing being done is your testing.
        • Fix the process first – then bring in technology
        • Don’t obsess over tools
        • Relationships are your key to success. So be friendly.
        • Values versus principles

What is the job of a test manager

        • To hire the right people
        • To empower people to achieve the business goals
        • To develop people to their potential
        • To make decisions
        • To encourage the right behaviour
        • To reduce costs in the right place, but not at the expense of delivery
        • To be communicated through
        • To encourage a sense of learning in the team
        • To help people through tough times

Note taking

        • The importance of good note taking
        • Quick capture
        • Information scraps
        • Types of notes
        • Note taking styles
          • Outlining
          • Mind mapping
        • Digital versus Analog
        • 60 Days proof
        • To Do lists
        • Kanban
          • Visualise your work
          • Work in progress
        • Examples of note taking and capture

Managing a test budget

        • Spend your employers money wisely
        • Is spending money going to solve your problem?
        • Lack of money often leads to innovation

Idle Thoughts

        • Don’t accept limitations
        • We are too young and we are too early in our careers to standardize us.
          • Don’t apply limitations to yourself, your team or even worse, the community.
        • Stop casting yourself as a victim
          • You are as equally important as anyone else on the team. (i.e. There is nothing wrong with you)
        • Experience as much as possible
        • End goals are important, but so to is the serendipity and experience of the journey
          • Don’t always be laser like focused.
          • Take the time to look around
          • Make time for people
          • Allow conversations to meander
          • You cannot organise an accident
        • You will not please everyone
        • You don’t need permission to do Exploratory Testing
        • Communities are where the future lies – not rules and edicts
        • Be skeptical.
          • Is it always true? Is there ever a time when it is not true?
        • Make time for thinking.
        • Stop trying to measure the person.
        • Grow some thick skin. Very thick skin.

Goal 3 – Deliver an awesome presentation…somewhere.

As usual I am hoping to speak at a conference this year. Details to follow.

With the above writing plans I won’t be speaking or attending many other events. I am taking the entire NVM test team to TestBash, whoot!, but other than that I doubt I will be at many events this year.

Goal 4 – Continue to build an amazing development team at NVM

I’ve obviously got some great work goals to achieve. I will be continuing to improving the process, grow the team and deliver the best service we can for our customers. I won’t be sharing my work goals here though 🙂

Goal 5 – Start mentoring someone

I’ve been mentoring people on and off for many years, but I might be making a step to make this a permanent goal, so that each year I can help to mentor one person in their career.

 

I’ve also got some very personal goals which I won’t be airing here either 🙂

Exciting year ahead.

Do you plan goals relating to your career?

If so, did you want to share them in the comments section?

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?