A Positive Way to Think About Bugs

Bugs are the things of nightmares. There are the ones that appear unannounced in production systems, at a critical time, and are spotted by the most vocal hater of your company. There are the intermittent ones that you spend hours trying to track down, and the small, irritating ones that you know will never be prioritised. There are the ones you’ve never seen but suspect are there, lurking. Waiting.

Over the years I’ve had an additional bug nightmare. One where someone expects me to spend a significant amount of my time capturing bug report metrics. They want to know how long bugs take to fix, how long we took to find the bug, or how good a developer is based on the number of bug reports we have.

When you take all this negative bug energy and throw in Jira. Or Mantis. Or BugZilla… it’s easy to understand why we all hate bugs.

But there is a positive side to bugs.

It’s too common to hear of bugs surprising teams and nothing changing. Some bugs are unexpected, and it doesn’t always make sense to try to stop a similar things happening again, but those are the exceptions. It is much more common for similar bugs to appear in different parts of the systems, these are strong indicators that things are not quite right. Observing and sharing these patterns can be a great trigger to motivate teams to change.

Every wondered how you can convince people to give you time to work on tech debt, or process improvement, or make progress on that cool infrastructure project? Well bugs can be very persuasive…

When a release showstopper bug, or production issue is found use it to its full potential. Understand the root cause, try to establish exactly why the bug appeared when it did. Was the issue poor communication, lacking test environments, or something else? Don’t make this a blame game about individuals but use it to find pieces of your process or technology that could be improved. In my experience bugs are almost never a result of poor code, they are much more likely to indicate code complexity, lack of context, poor test data, or simple lack of experience.

Once you have your information tell your story. Keep telling it. You’re not trying to force people to change things, you want to simply highlight the issues that are occurring as a result of things being the way they are. Once you find your interested audience work with them to make improvements.

Step by step you’ll find things improve.

Don’t make it easy to be ignored

Most people hate saying no. Our reluctance to disappoint someone, or a fear of conflict, can lead to us doing all kinds of things that we didn’t intend to do just because we couldn’t, or wouldn’t, say no. Our fear of saying no often extends so far that we’ll avoid putting other people in a situation where they have to say no, just in case they feel as bad as we do. The result? We don’t get what we want. even worse, we never learn how to effectively ask for what we want.

There will be times when you have to ask for help, and failing to get people to agree will mean things don’t happen; things like events, because you always need speakers, or parties. At work it becomes even more pressing. Modern workplaces are built on collaboration so you might find that you can only succeed with the help of others. The good news is that almost everyone working in these collaborative environments is expecting to be asked for help, you just need to learn how to do it.

Step 1 – Know what you want. 
It is very hard to ask for something that you don’t understand or can’t articulate. Take some time to decide what it is you actually need to ask for. Is it time? Budget? Assistance?

Step 2 – Be Specific.
Often the way we ask for something is the problem. Either through inexperience or nerves we make the request so vague that we become easy to ignore. People are busy, they might not have time to dig through your long statement to try and work out if you asked for something without actually asking for it.

Step 3 – If the request is crappy, or if you know they’re busy, you need to appeal to their ego.
Everyone has an ego. Appealing to it can make a huge difference in helping someone decide if they’re going to help you or not.

Here are a few examples to show how these three steps can make a huge difference:

Example 1

Other person: “So anyone able to tell me anything about X?”
Everyone else: Thinking – I’m not sure exactly what she wants but this little thing I know probably isn’t important “…”

A more effective version
Other person: “So I’m stuck on this bug. Anyone worked on this code recently? Amy didn’t you look at it recently?”
Me: “Nope, that was this other thing but I think Adam might know more”
Adam: “I don’t think I know much more but let’s pair and work this thing out!”

Why it works: Explaining why you’re asking for something helps. Targeting an individual within a group will always be more effective than a vague full group address. If you don’t know who to target just pick someone who is responsive, diligent, and kind, they’ll help you find the right person.

Example 2

Other person: “I was wondering if you were going to be in the office tomorrow?”
Me: Thinking – umm, that sounds like it could lead to something bad… “Umm, so I’m not sure yet. Why…?”
Other person: “Ah, I was just looking for someone to do this crappy thing for me”
Me: ….

How this could have been better
Other person: “Could you do me a massive favour and be in the office to look after X tomorrow? I think you might be the only one around who can help”
Me: Feeling needed – “Oh hey, yeah sure, tell me more”

Why it works: There are three parts to the success of this one:
– You acknowledge that you’re asking for a favour. And you actually ask them for something instead of making loose statements.
– You’re up front about the crappy thing you want someone to do.
– You appeal to their desire to be needed (very effective!).

Example 3

Other person: “So I’m looking for people to talk at this event”
Me: Feeling a bit interested but also busy “Oh hey, yeah maybe one day…”

How this could have gone better
Other person: “Oh so I’m organising this event (and it’s going to be awesome because of X) and I’d love you to come and talk about Y”
Me: Feeling flattered but still busy “Oh really? Well sure, I’ll see if I can fit it in”

How this could have gone even better
Other person: “Oh so I’m organising this event (and it’s going to be awesome because of X) and I’d love you to come and give that talk you gave at Y. I really loved it.”
Me: Feeling loved beyond belief “Oh really? Well sure!”

Why this works:
You’re selling your event to the person by telling them why they should care.
You’re explaining why you’re asking this specific person.
You remove a load of work for them by telling them you want a specific, already existing, talk.

So next time you need something to happen take the time, and a deep breath, and actually ask for what you want.

You are the sum of everything you’ve ever experienced

It can be easy to think that every problem you face has been solved before, or to think that every story you have to tell has already been told. In fact we should all remember, and embrace our uniqueness. People have likely faced similar situations before you, but no-one has ever stood in your shoes.

Our experiences in life give us the tools we need to navigate the present. Even without intentionally realising it, the person with 20 years of experience have more tools to help make decisions than the person with 6 months of experience. Maybe you haven’t helped this child to stop crying after this particular fall but you have helped others. Or maybe you haven’t had to decide on the best restaurant in this particular city but you have chosen restaurants before. Work is the same, people fight, get upset, or want it to be different. Years of experience can help you navigate each unique, but comparable, situation because you can see the similarities, or patterns, to previous situations.

The problem is we very rarely seek out patterns or experiences intentionality. Instead choosing to let time provide us with the experiences we need. Imagine if there was a way to fast track this process! You could gather up years and years of experience and have them right now!

Here’s the thing. You can.

We see the world through the many veils of our previous experiences. Every time you feel something, see something, do something, or even hear something you add another layer to your view. That means that every book, article, even tweet you read is contributing something to your world outlook. Instead of needing to actually experience every single problem or situation you can take a lot of someone else’s experience and layer them in with your own.

“The only true voyage would be not to travel through a hundred different lands with the same pair of eyes, but to see the same land through a hundred different pairs of eyes.”
— Marcel Proust

So if you want to be better at your job then you need to intentionally seek out more experience. Some of it will come with time but most will come by actively learning about other people’s opinions and experiences and using them to enhance your own thinking.

Rather than aspire to be the person with the most years experience we should all be aspiring to be the person with the richest world view.

Eight reasons why no one’s listening to you

One of the most frustrating things about working with other people is trying to convince them of something you really believe in, only to have them dismiss it as unimportant. You tell them once, you repeat yourself, nothing happens. You get frustrated and wonder why they don’t take you seriously. Eventually you give up, annoyed. But it doesn’t have to end this way.

It is possible that the people you’re trying to convince are ignorant fools. But it’s far more likely that you’re falling into one of the following traps:

1. You’re saying it in the wrong way

When you try to convince someone of something, or to change someone’s mind about something, you need empathy. Understand what their world looks like, what made them reach the conclusion they reached? The more you can understand their position the easier it will be to try and move them.

If you’ve explained something to someone and they still don’t get it, try explaining it differently. Or drawing them a diagram or picture to illustrate. Maybe they need to see some code or numbers to understand. Explore different approaches until you hit on one that works.

2. You’re saying it to the wrong person

Sometimes you push and push. You use words, images, brilliant examples and still nothing seems to be changing. Take a step back and consider if you’re talking to the right person. Are they really empowered to change this? Even someone with the “Boss” job title might be the wrong person if they don’t hold the implicit power to make the change. if you suspect that the person you’ve been talking to is onboard but unable to help ask them “is there anyone else you think would be interested in talking about this?”. Give them an opening to pull in other people without losing face.

3. You’re saying it to someone who is actively blocking you (and they may not realise it)

As a general rule people don’t like change and they will actively block anything that makes them feel vulnerable. You’re missing the trust; they need to trust that you’re doing something for the right reasons, and you need to trust that their reaction is fair. Unfortunately not all relationships are made equal and there will certainly be times when you’re proposing change to someone who doesn’t trust you, or someone who might actually want you to fail for some reason. Even more trickily they might not even realise that they feel this way about you.

The only way to get around this, aside from maybe sidestepping them and working with someone else which incidentally reduces the trust relationship further, is to invest in the relationship. If they seem resistant to your suggestion trying working with them, talking to them, or just generally getting to know them without pushing your change proposal on them. If you’re lucky you might build enough of a relationship to allow you to successfully bring your suggestion to life.

4. You’re saying it at the wrong time

Sometimes you’re saying the right thing to the right person but you’ll have chosen the wrong time. Don’t grab your manager when they’re stressed out and expect them to care about something trivial in your life. Similarly, managers, don’t grab a stressed out report and expect them to receive career coaching well. Don’t wait for the hour before a big release to tell everyone that you think the whole idea of the product is wrong. People won’t care. They can’t afford to care. Pick a time when they can care.

5. You’re still saying it in the wrong place

The method of communicating is just as important as what you are communicating. Trying to explain a new, and complex concept to a novice who is sat in a meeting room with experts probably won’t work. They’ll be defensive and embarrassed. Consider when an email might be more appropriate than face-to-face. Is Slack the way to go? Whatever your method look at who else is listening in, are they helping or hindering?

Think about how you would feel if the tables were turned. Does your idea or advice still feel constructive? If not, change it.

6. You don’t have the bigger picture

Maybe you would be right if you had more context, but you don’t, so you’re wrong. If you’re lucky the person you’re trying to convince will fill you in on the missing context and explain why it matters. Unfortunately there are times when things are happening that you can’t know about, big company things, personal things, things involving peers. You might have success in explicitly asking if “there’s anything you’ve overlooked” to learn more about these things. Maybe talking to more people will help you build up a better picture of how things look. Unfortunately there will be times when you don’t have the context and you don’t know it, but no one fills you in. That’s tough, and probably hard to plan for.

7. You’re wrong

In a fair world being wrong wouldn’t be enough to make you ignored but the world is not fair. Sometimes when you say something to someone who thinks, or knows, you’re wrong they take the lazy route and simply ignore you. A debate or conversation with a patient and considerate person would explore why you believe something. Maybe you’d discuss case studies or data to back up your argument. In the course of the discussion holes in your argument would become apparent. Luckily rubber ducking can help you out. Before making any argument think through what you’re arguing for and why. What data do you have to back it up? If people have given you feedback before then apply it. Nothing is more likely to get you ignored than earning yourself a reputation for repeatedly making weak or impractical suggestions.

8. You’re making people feel vulnerable

When you say something that seem so obvious to you and it is met with silence, or opposition, remember this quote from Seth Godin “If you’re seeking to create positive change in your community, it’s almost certain you’ll be creating discomfort as well.”. Take change slowly and make it easy for people to be wrong.

 

Next time you find yourself being ignored take a step back and try to understand why. Empathise with the person who’s ignoring you, what are they feeling? Are you making them vulnerable or confused? Is your suggestion too trivial, or too political to be acknowledged? Use this information to build a bigger and better argument and then try again. Maybe you’ll need to bring in more people, or choose your time more carefully, maybe it is simply a case of changing your approach. Whatever it takes persist. Being ignored is not an excuse to avoid change.

What is Quality?

A few months ago I asked people to complete a short survey on quality. Thanks to all who took part.

Quality is often defined using Jerry Weinberg’s definition of “Value to some person who matters”. Although testers tend to use this definition frequently, and comfortably, I’ve found it to have some limitations. The word ‘value” is almost as fuzzy as “quality” and who exactly are those people who matter? It seems that even with a widely accepted definition it’s still hard to translate quality into a tangible concept for developers or customers.

I decided to try turn a definition of quality into a feeling that people could actually relate to, and hopefully use to better their own work. To do this I asked people to rate the quality of LinkedIn. I know many of you will be laughing at the idea that LinkedIn might represent quality but it turns out to be a very divisive topic. People who want to manage a professional network generally rate LinkedIn’s quality highly. Testing professionals usually don’t.

Although heavily leaning towards the “no”, we can see a decent number of people do think LinkedIn is a quality service.

If a service offers value then many people are able to ignore, or maybe don’t even notice shortcomings. I asked people to rate the quality of LinkedIn using just a yes, or a no option. As many respondents pointed out quality is definitely on a scale. What’s interesting to me is that the people who wanted to give a “yes, but no” response tended to say that LinkedIn offers value in managing a professional network (so it is a quality service), but that it it unintuitive to use (so it isn’t a quality service).

The frequency of “intuitiveness” as a measure of quality is of particular interest to the tester side of me. How often do we get caught up testing something against the requirements and ignore the unspecified side of the system? We spend hours hunting down weird and wonderful edge cases, maybe too often choosing to spend our time logging bugs rather than helping to improve the intuitiveness of a system.

We frequently discuss whether testers should learn to code or not. Maybe now is the time to start talking about whether testers should be learning about UX design. At Songkick we see huge benefit in including all team members in testing and quality activities. UI designers are experts at creating usable designs. UX designers understand how users interact with the system. Developers understand how code complexities can cause unexpected behaviour. Ops Engineers know how the system actually runs in production. Product Owners know exactly what they want the system to do. Including all of them in testing discussions brings a wealth of knowledge and skills that, when combined with a testing expert, can have a huge impact on quality.

Quality isn’t the (sole) responsibility of the test team. Everyone involved in developing software should have a good understanding of who the intended users are, their goals, and at least a working understanding of the methods we can use to meet expectations. Facilitate discussions to identify the “people who matter” for your particular system. Help connect team members to users. Even a single session on the customer support desk can have a huge impact on helping people see the real-life impact of a poor design choice. Even just making sure you have a solid approach to managing code maintainability will impact quality as least as much as prioritising features correctly.

Treat quality as a team responsibility. Work together to assist each other in building systems that people actually want to use.

Why I hate DevOps

DevOps. The latest software development fad. Now you can be Agile, use Continuous Delivery, and believe in DevOps.

Continuous Delivery (CD), the act of small, frequent, releases was defined in detail by Jez Humble and Dave Farley in their book – Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. The approach makes a lot of sense and encourages a number of healthy behaviours in a team. For example, frequent releases more or less have to be small. Small releases are easier to understand, which in turn increases our chances of building good features, but also our chances of testing for the right risks. If you do run into problems during testing then it’s pretty easy to work out the change that caused them, reducing the time to debug and fix issues.

Unfortunately, along with all the good parts of CD we have a slight problem. The book focused on the areas which were considered to be the most broken, and unfortunately that led to the original CD description implying “Done” meant the code was shipped to production. As anyone who has ever worked on software will know, running code in production also requires a fair bit of work.

So, teams started adopting CD but no one was talking about how the Ops team fitted into the release cycle. Everything from knowing when production systems were in trouble, to reliable release systems was just assumed to be fully functional, and unnecessary for explanation.

To try to plug the gap DevOps rose up.

Now, just to make things even more confusing. Dave Farley later said that not talking about Ops was an omission and CD does include the entire development and release cycle, including running in production. So DevOps and CD have some overlap there.

DevOps does take a slightly different angle on the approach than CD. The emphasis for DevOps is on the collaboration rather than the process. Silos should be actively broken down to help developers understand systems well enough to be able to write good, robust and scalable code.

So far so good.

The problem is we now have teams saying they’re doing DevOps. By that they mean is they make small, frequent, releases to production AND the developers are working closely with the Ops team to get things out to production and to keep them running.

Sounds good. So what’s the problem?

Well, the problem is the name. We now have a term “DevOps” to describe the entire build, test, release approach. The problem is when you call something DevOps anyone who doesn’t identify themselves as a dev or as Ops automatically assumes they’re not part of the process.

Seriously, go and ask your designers what they think of DevOps. Or how about your testers. Or Product Managers. Or Customer Support.

And that’s a problem.

We’ve managed to take something that is completely dependant on collaboration, and trust, and name it in a way that excludes a significant number of people. All of the name suggestions that arise when you mention this are just ridiculous. DevTestOps? BusinessDevTestOps? DesignDevOps? Aside from just being stupid names these continue to exclude anyone who doesn’t have these words in their title.

So do I hate DevOps? Well no, not the practice. I think we should always be thinking about how things will actually work in production. We need an Ops team to help us do that so it makes total sense to have them involved in the process. Just take care with that name.

Is there a solution? Well, in my mind we’re still talking about collaboration above all else. Thinking about CD as “Delivery on demand” also makes more sense to me. We, the whole team, should be ready to deliver working software to the customer when they want it. By being aware of the confusion, and exclusion that some of these names create we can hopefully bring everyone into the project before it’s too late.

Should developers own acceptance tests?

A couple of weeks ago I watched a talk from Dave Farley that said developers should own acceptance tests. It’s a great talk, you should watch it if you haven’t already. Afterwards I realised that I was going to have to write this blog post to explain why I thought the talk was brilliant, but misleading.

First, let’s define acceptance tests. Dave explains them as “trying to assert that the code does what the users want the code to do”. For me they are the tests that we perform (with, or without tools), to decide whether to accept a feature/system or not.

Dave’s talk addresses an important topic. Namely that testers shouldn’t be the owners of these tests. I totally agree with this statement. In all the projects I’ve worked on, I have never seen a test suite solely owned by testers being a useful thing. Of course the testers usually design brilliant tests, and these tests often uncover serious issues before any code gets released but they are still a terrible idea for two reasons.

Firstly, we have an entire suite of tests that exists and runs without any developer involvement. Unless you work in a team that really doesn’t think about testing in any way before code get handed over to testers then this is going to cause test duplication. If your developers really don’t think about testing then you probably have some serious silo issues that need addressing. Go and sort those out before you read the rest of this post. But seriously, developers think about testing all the time. Allowing acceptance testing to be separated from development is going to guarantee duplication in tests. It’s also likely to guarantee some gaps in testing as the approaches of developers and testers are not joined up.

Secondly, testers are brilliant at designing tests. We should expect them to be able to turn up some issues, many of them fundamental and serious. Why wouldn’t we want to do that much earlier in the process? Acceptance tests are usually run against a release candidate. Often a release candidate contains one, or even several weeks of work. Waiting that long to run these tests and then turning up a problem is going to make for some expensive re-work.

In Dave’s talk he argued that developers should be the owners of acceptance tests. To me this sounds like a bad idea. Acceptance tests should be a measure of how well the feature meets the requirements. Developers are probably least qualified, or at least biased enough, to be unable to make this decision. That’s not to say that testers should be the owner either. We still want to avoid creating any kind of “wall” for code to be thrown over.

So who should own the tests? Maybe the team would be a better owner. If acceptance tests are truly going to be a measure of how well the feature meets requirements then it seems to me that a business/product owner needs to decide what gets tested. So we ask the business owner to define the journeys that need testing. Testers know a lot about designing good tests so the Testers should be helping to turn those journeys in to good test scenarios with suitable test data. Developers know how to write robust code so the Developers should be writing and maintaining the tests.

The end result is a well designed, and implemented test suite that actually tests something the product owners wants to have tested.

This collaborate test design brings together the strengths, and input, of the entire team. We give testers the opportunity to uncover issues, but the collaborative nature of the test design means it’s likely to happen far earlier that it would if testers own the tests. Maybe even at the test design stage instead of a week later during release testing. Developers can write the tests and avoid many of the “tester written test” issues. The test scripts get treated as any other code, written and maintained by developers. Finally the real strength of this approach is being able to involve the business owner in the discussions. Hearing about the things they’re worried about right at the beginning can have a massive impact on the design and implementation of the feature.

In fairness I think Dave was actually arguing for exactly this approach. Developers should absolutely be at the heart of acceptance tests but I don’t think we should use the word ‘own’. Teams own things, not individuals. The right group of people collaborate to achieve the best result.

What’s the cost of shipping bugs?

A tiny question to reveal huge insight.

At Songkick we use Continuous Deployment for many of our releases. This approach requires a risk-based approach for every change. Are we tweaking the copy, or re-designing the sign up system? Are we changing a core system, or an add-on feature? The answers will determine how much risk we’re willing to take. And subsequently decide whether this feature can be automatically deployed by our Jenkins pipeline or not. The most useful question we ask ourselves before writing any code is “What’s the cost of shipping bugs?”.

If the answer is “low”, perhaps because this is an experiment, easily fixed, invisible to users etc then we know we can move faster. Developers can be more autonomous. Maybe they don’t need a code review. Maybe the testers don’t need to spend so long testing things before we release. Maybe we don’t need to update our test suites.

If however the answer is “high”, perhaps because we’ve broken something like this in the past, or it’s going to be hard to fix, or highly damaging, or we’re all about to take a week off to visit New York. Then we know that we need to be more cautious. Testers need to be more involved. We need to consider releasing this with feature flippers, or using a dead canary release. We’ll make sure the release takes place at a time when there are people available to monitor the release, and get involved if needed.

It’s a tiny question that takes just a minute to ask but this tiny question can shape our entire development and release approach.

How do you estimate the cost of shipping bugs? 

Get outside your comfort zone

The testing community is awesome. There are so many friendly faces. So many people reading things, discussing things, watching things, and developing their ideas. As the communities grow stronger the people you spend most of your time with are likely to be similar to yourself. Maybe you all belong to a similar school of thought. Maybe you’ve worked on projects together before, or attended training courses or conferences together.

It’s great.

Or is it?

The problem is these people are likely to be very similar to you. They share your ideals, and your ideas. You start to think that you’re in the majority whereas is many cases you’re not.

When was the last time you read something you disagreed with? Or attended a conference that wasn’t solely about your craft? Now I’m not saying that you have to go out there and engage everyone in debate. You’re not looking to convert these people, or even to change your own opinions. Broadening your view might simply give you something to measure your ideas against.

If you’re an agile advocate do you really understand why not everyone is into it? Do you know why testers are often excluded from projects? Have you asked a developer why they haven’t attended a test conference? Have you asked yourself why you haven’t attended a design conference?

We all work in development and yet we all hold these independent, and often incompatible views. Look up and see the world that your work fits in to. It might just make you a better tester.

 

Are you an Independent Tester?

March, the time of TestBash Brighton. As always it was a pleasure to return to Brighton and catch up with some of the smartest, friendliest, and most inspirational testers.

The final talk of the day was from Nicola Owen. Her story was about moving from being a tester in a large organisation to being the only tester in a company. She talked of the challenges and benefits that came from being a sole tester.

Nicola’s talk made me ponder the role of a tester. Often we struggle to gain recognition in teams and companies. Testers are frequently the ones who get forgotten about when teams are thanked, or team lunches are organised. Is that really because we’re so forgettable? Does the sheer number of developers make testers invisible?

I believe that testers can, and should, be seen as a beacon of expertise throughout the company. Testers have so much knowledge about the product, the users, and the project risks. Every tester should know exactly when the project deadline is, who the customer is, and what the project goals are. Hopefully they also know the technology stack being used, the experience-level of the developers, and have a deep understanding of every step of the development and release process.

Knowledge is power. Testers don’t have to be technical. The ability to write code doesn’t have to be a measure of how good a tester you are. If you work with good developers then it probably doesn’t matter if you know how to configure a web server, or submit a binary to Google. What does matter is being able to initiate, and contribute to important conversations.

Talking about a problem out loud triggers your brain to think about things in a different way. For this reason many developers use the “Rubber duck debugging” technique to find issues in their code. Talking things through, even with just a rubber duck, can make you realise that you’re missing something, or spot an obvious problem in the design. If a rubber duck can bring this much value to a developer just imagine what a creative, and knowledgeable tester can bring to the conversation.

Whether you work in a small team or a large team you should take responsibility for your own role. A bigger team doesn’t mean you get to take less responsibility.

Behave as you would if you were the only tester around. Ask questions, and make notes, connect the information people give you and turn it into knowledge. If you come across a casual group conversation then get involved. Kitchens are a great place to spend time. Tell people your ideas and ask for their input. Not only will you learn some interesting, and possibly useful things, but you’ll also meet some new people. Don’t under-estimate the power of being well-connected within a company.

Your own experience is worth more than a thousand books. Reflect, search, and understand how your actions impact the team. At the same time read widely, watch talks, and engage with people outside of your organisation. Compare your experiences with others. What can you learn?

Always have an opinion about everything – even if you don’t always share it. Learning to question things, to spot the areas that could have been better will help you become better. Do this with your own work and with others’. When you read an article, or a book, question what it is telling you. How does your own experience differ?

Independent testers are resilient and self-supporting. They have the knowledge and skills to be able to excel as a sole tester in a company but they also have the knowledge and skills to make a larger test team a powerhouse. So don’t look around you and use your team size as a measure of how good a tester you need to be. Look around you and see the opportunities that are open to you. Now grab them.

The TestBash videos are now available over at The Dojo.