Episode 7 of the software testing podcast that I record with Dan Ashby is now available. In this episode we talk about the idea of ‘schools of testing’ and compare and contrast approaches such as those from the ISTQB and context-driven communities.
You can download it from the site, via RSS or it’ll shortly be in iTunes as usual.
I was interviewed recently for the uTest blog. I’ll be speaking about ‘Testing As An Activity’ at the forthcoming Next Generation Testing Conference, and so they asked me some questions about the topic, as well as some more general one’s about my thoughts on testing and how I started in the industry.
Worth a read I reckon, (I am biased of course). You can find the uTest blog post on their site.
More details on the Next Generation Testing Conference are on their site.
I firmly believe that in order to be as effective as possible, testers need to engage with the software testing community. Learning from others, particularly outside of the companies where we work, makes us more rounded and better informed individuals. It enables us to inspire ourselves and our colleagues in ways that we could not otherwise.
Recently I’ve been wondering why more people do not engage with the community. What is stopping them, and how can we all help change this? We can explain how brilliant the wider community is, and we can give examples from our experience. We can send people to conferences and email round blog posts. What is that does not work?
What do we do about those within a team who do not want to interact? Those who do not see it as a good use of their time, and are not willing to spend time on community matters, even if that time is given to them by the company. Should we incentivise people to do so? At least in order to push them in the direction of the wider testing community, where hopefully they will get hooked? Or should we do the opposite? Is it a valid idea to make community engagement a part of people’s role description, and therefore penalise those who hold such positions and do not exhibit such engagement?
Or is there another way of persuading everyone that the software testing community is key to their personal development? I’d be interested to know what you think.
If you are a functional test automation expert then times are good. There’s big bucks to be made in the contracting game, companies are desperate for candidates to ‘automate everything’ and to get to this oddly perceived test automation nirvana that those who are either mis-informed or have hidden agenda’s seem to feel fit to promote.
This has made me think. Primarily about how we have got to this state? Is it because, as the testing community, we have wanted to own test automation? Is it because those outside of the test community see test automation as less important than the production code that it tests? Is it that we just built up an expertise and then protected it just for the money?
Some might say that what has actually happened is that we now have a situation where second rate developers now have a great way to stay in the development game. There is a danger, in the apparent supply-side crisis that we find the industry in, that companies merely employ anyone who says they know something about test automation, without doing the same due diligence that one would do for a development position. This would be a mistake.
In my mind there is a solution to all these problems, and that solution comes from treating test automation just like production code. And that means primarily using developers to write it. Sure, you may choose to have testers involved as well, where they have the skills and expertise, but let’s not try and force skills on people who don’t want them, and let’s not accept second rate people just because they can ‘do some test automation’. One advantage to using developers is that test automation becomes a team thing, and you are less likely to spend time playing catch-up when development slips. One downside; it’s going to look like the team has slowed down. Believe me, it hasn’t. It’s just got more effective, and is playing to the right skill-sets.
Don’t believe me? 🙂 Here’s a couple more examples from Rob Lambert and Amy Phillips which show where continuous or more frequent delivery has been successfully rolled out at New Voice Media and Songkick. The common thread – in both cases the test automation is a development activity.
Recently I’ve started to come to the belief that we can solve a lot of our problems if we just start to think differently about testing. If instead of thinking about software testing only as a distinct discipline, we instead to start to think about it as an activity. After all, testing is just that, an activity. It’s something we do. Something we’d love others to do more. James Bach likes to define software testing as a performance, and what is a performance without some activity to perform?
Once we start to think of testing as an activity then it matter less that it’s not always testers who do it. Everyone in a team should test, it’s just that the tester role can be where the expertise lies, and where the test coaching comes from.
Think of all the problems we can solve if we think like this.
In my first post about ‘A Testers Hierarchy of Needs’ I explained a little about humanistic psychology and the work of Abraham Maslow. Let’s now look at how this can be applied to software testing.
As with the first post, the headings match with the slides I presented at TestBash.
A typical testers career path can look like this – it’s rather rigid and set. There are similar paths to this for management roles, and often testers are pushed towards management because it pays better, even if they don’t like management.
But what if we forgot about roles and job descriptions? After all, why do we have to consider our roles as part of a career ladder? How do we fit within our roles? What makes us satisfied as testers? What satisfies those who work for us in testing?
It’s all about considering building blocks. How do we fit the pieces together? How do we build a different kind of model to help us understand ourselves and our testers? Well I think Maslow’s work can help us out here. It can give us a framework.
Our first level – Maslow would call this the Physiological level. I call it acceptance. Acceptance of testing. So testing is just a job. Management view is ‘anyone can do it’. You are probably complying with work rules and basic processes to continue staying in job. There’s a lack of respect or support BUT there is testing happening. It’s probably manual checking only but it’s a start. So a positive step.
The next level is Maslow’s Safety level. Testing is mandated. There is a test team. Testers have peers. There is some safety – the job is seen as worthwhile and so unlikely to suddenly be moved to somewhere where people can press the buttons and check more cheaply. But testers are still universally seen as an annoyance. It’s about meeting expectations of peers and bosses, sometimes unspoken, to meet a moral and social code. It’s a learning level. As a tester you can learn testing, the company you work for is learning about testing. You play a key part in ensuring that learning happens.
One level up and it’s all about belonging. Testing, testers and the test team is seen as a key part of the company. It is taken seriously by all. It’s about meeting and exceeding more demanding expectations of peers and bosses, sometimes unspoken, to meet moral and social code. Consultation. Respect. Inclusion.
The Interaction level is next. The impact of testing reaches further than just the IT team. Consultation from the business. Reliance. Interaction. And overall a real sense of Esteem for the tester. A sense of worth. You are really adding value.
Then the top. Maslow’s self-actualisation level. Test Mastery.
Maslow never drew the theory of needs as a pyramid. In fact he never drew it as a diagram at all as far as I know. That was done in a later psychology text book. He felt that there could be overlap between states. You can move between states. Down as well as up. Changing roles, changing teams, life changes, can all affect movement between levels. Where you are on the hierarchy is just a snapshot in time.
I feel that, for a testers theory of needs, a pyramid is right. It shows the hierarchy best. But it could be a set of overlapping balloons, if you like that sort of thing.
Are you on a path to self-actualization. To Test Mastery? Do you think you are there already? What are you doing to stay there? What about the testers who are in your team? What about the company you work for?
I’d be very interested to know what you think.
Thing have been a bit quiet around here. Maybe you’ve noticed it. Maybe you’ve only came to this blog for the first time, from a link from Google or Bing, in which case welcome, and do note the gap in posts. I’ve been busy.
Primarily this has been because I’ve been searching for, and then settling into, a new job in a new company. Starting a new job isn’t easy, be it in testing or any other field, and it’s what you do in the first few months in a new company that can really affect how the rest of your time there goes. Those relationships you make early on, and how you are seen by others matter. It matters a lot.
So, while things are fresh in my mind, here’s some handy hints on what you should consider when starting somewhere new. I’ll be sharing further articles about recruitment, job searching and C.V.’s over the forthcoming months.
All presented with a software testing view.
Probably the most important thing you can do when you start, especially in a testing role. Being a good communicator, with the ability to get on with as many people as possible is very important as a tester. Spend your time searching out the important people, introduce yourself, and find out more about them. Ask them about the company, ask them about how you can work together, and find out what they think about how the company does testing. Those relationships you make early on affect how people see you for a long time. Sure, you won’t be able to remember all their names, but make sure they remember yours. And yes, this does mean talking to more than just testers 🙂
Testing is all about questioning a product in order to evaluate it, right? Take the same approach when you start a new job. Ask everything you can think of, no question is too stupid to ask if you don’t know the answer. Often, so much information in a company, is un-documented, and you want to make sure that you can understand the bigger picture, as well as just knowing enough to do your role. As testers we need as broad a view as possible in order to work effectively so make sure that you learn by questioning, and continue to do so. It takes time to settle into a new job but the more questions you ask then the quicker you should be able to feel like you understand company and your role within it. Don’t sit there, feeling blocked because you don’t feel like you can ask something.
First impressions count. When you first start you meet a lot of people. Every time you meet someone new then that’s a new first impression. Always remember to be nice. Even if you are really an evil tester 🙂
They decided to employ you, there must be a reason, right? 🙂 Remember that you have good, and relevant, experience that you can bring. It’s easy when you first start, to just spend your time learning the company and your new role. But do not forget that your experience from outside the company could be really useful. Maybe your old company did it’s test automation a particular way or maybe you can see the new company works in a way you helped improve in an old role. It’s often new starters who are in the best position to see improvement areas. Don’t just accept that ‘this is the way its done round here’, and don’t feel afraid to speak up.
It can be really easy when you start somewhere new to just go into things head down and try and pick everything up at once. Remember that you need to pause and ask for feedback. Make sure that you question your own understanding of things, as you learn them, and regularly ask for feedback from those you work with.
When you start at a new company it can be really easy to spend all your time learning your new role. After all, there is a lot to pick up and a lot to learn. It is tiring, but don’t forget what you did before. Since you are reading this then I assume you read software testing blogs at least. Keep active in the testing community and keep learning. That way you can bring not only new ideas from your previous job, but also new ideas from the whole testing community.
It takes a lot of effort when you start a new job. There is a lot to learn and a lot of people to meet. Focus on what attracted you to the new job and don’t forget to enjoy it 🙂
Some exciting news – I’ll be speaking about “A Tester’s Hierarchy of Needs” at TestBash 2.0 which is being held in Brighton, in the UK, on Friday 22nd March 2013. This will be the first time I’ve spoken at the event, and looking at the others speakers, then I’ll be certainly in very good company. James Bach will be giving the keynote.
You can find out a lot more about TestBash 2.0 at the event website, including how to get Super Early Bird tickets.
Hope to see you there.
As part of my role I manage testers and also those involved in delivery operations. This means thinking not only about testing and test techniques, but also about person management, and the tools and techniques that a good manager uses in order to have a happy and productive team. These two areas should not, of course, be treated in isolation since, in order to have a successful test team, it’s the managers job to ensure that the two areas fit well together. If this can be done in as seamless as possible a way, maybe even without the team members even being aware of it, then my experience tells me that you can hit that sweet spot where the team is technically excellent as well as being the sort of team that testers want to work in, and are proud to work in.
I’ve studied a lot of theories of management in the past but the one that I keep coming back to again and again is Maslow’s Hierarchy of Needs. At it’s simplest it seeks to explain the needs of human’s in their most basic form, expressed hierarchically in order of those needs.
So, for example, the theory puts forward the hypothesis that it is most important (and therefore at the bottom of the pyramid) that human’s experience a need for food, water, etc. Safety needs come next, followed by a need for belonging, and so on.
As a manager, keeping this simple theory in mind can really help. I’ve found numerous occasions in the past where it has helped me understand team members actions, and to help ensure the team is working effectively together.
But it has also got my thinking about how one might go about applying Maslow’s Theory of Needs to Testing. More specifically, how a tester in a team or project might experience and visualise those needs, as reflected by their status within the team. This lead me to produce this:
Test Mastery is a place I see the respected, happy tester sitting. Probably people like you, who interact and are involved with the software testing community, who self-learn and who are able to articulate the need for testing effectively.
This is just the start of the theory. I’m sure, as a community we can add more to this. What would you add to the different levels and why? Leave a comment below.
I’ve recently been reading through my ISEB Practitioner notes, which I got when attending a course organised by Grove Consultants a few years back, as I mentioned in my previous post. It’s got me thinking about test cases, and in particular the four criteria of a good test case. Having attended both Rapid Software Testing and Rapid Test Management recently, and having rolled out an Exploratory and Session Based Test Strategy in my teams then it’s caused me to question again the validity of test cases and the need for them.
So, to a good test case. Reading my notes, a good test case is, in no particular order, apparently:
1. Exemplary.
2. Evolvable.
3. Economic.
4. Effective.
Straight from the ISTQB/ ISEB of course. But not without merit. Are these still relevant?
Good test cases can test more than one condition at the same time. This is one good reason for taking the time to design test cases in the first place. Just writing test cases because “it’s the done thing” or “because the policy says so” is time wasting, but designing them so that when the testing is carried out it is done so in the most efficient way requires exemplary test cases and can add value. It is also the case that test cases are shared and it’s difficult, especially in large organisations, to ensure that all testers have the same basic level of ability. Having test cases can help.
From a contextual point of view perhaps a good test case is not written down at all but merely in the testers head, and driving the testing into particular areas that the tester feels are worthy of time and effort. Cases where the software is the specification are becoming increasingly common; in-sufficient or non-existent requirements documentation which requires the tester to apply their previous knowledge of the system under test in order to effectively test it. Clearly in this case, if documented test cases are required then they will be need to evolve. As Rapid Software Testing mentions “How do you invent the right tests at the right time – evolve them with an exploratory strategy”.
Time is money and often in testing we have little time and sometimes little money. So using that time and that money in the most efficient way means we minimise the economic impact. Of course, sometimes the best way to get maximum value is to have a purely exploratory approach and spend more of the time and money with the software in hand. A choice which is key to a good test strategy and highly dependant on the industry area one is testing within.
Clearly a good test cases should be effective. We are not in the business of wasting time, particularly when time is precious as it often is in testing projects.
I’d argue that the definitions given in ISEB/ ISTQB are still relevant and can be a good guide as to what is required of a test case. In a lot of industries test cases are still very much required and, particularly where there is strict regulation such as in areas of financial software and even in mobile software. The ability to write a good test case is a skill which should not be forgotten.