Training New Testers

So as my more regular readers will be aware, at work, we are changing some major systems for something a bit more modern. This means more testing is required than my test team is able to do. So we’ve recruited some more people to test. I decided that the  best approach for this was to recruit internally for people who had the familiarity with the business processes that are impacted by the software change that I could teach how to test.

Now there are obvious risks to this approach, my ability to assess someone’s ability to learn quickly, have an appropriate mindset for good quality testing, my ability to train them, the list goes on. However, I felt that connection with the business was worth the risk, the ability to see what’s going to be a challenge in the departments, and what’s going to work well, plus the increased trust for the business by having key people involved in the testing process.

So the challenge that I have is to train them all to be great testers, well as great as I can help them be. There are plenty of great resources out there, videos, blog, books etc. However there are 5 of them, and we have to be testing the system at the same time as I’m training them. So I recruited them all earlier than I actually needed them, so they could start learning before it became critical. My first step was to get them to watch James Bach’s open lecture, I used this as a starting point as James has an engaging style of presentation, and the lecture covers some of the basic challenges in testing in an easy to understand way, with little need for the watcher to already understand testing or a great deal about software development. I also ran some training on the basic housekeeping tasks that make up the test process we are using here, session notes, timings, bug reporting etc. Plus a have a small selection of books that they can borrow which cover aspects of testing.  We also have regular open discussions about testing where we can share what we have learnt, and ask questions about how to do things. I’ve also given each of them a cheat sheet with some helpful heuristics and information about data types.

I have also encouraged them to spend a little time every week on some self-directed learning about software testing, which I ask them about, and when they have found something that is useful to the team to share it with them. I have also encouraged them to just log into the system, have a poke about, see how stuff works, and practice session note taking while doing so. This has been of great use, it’s uncovered a few bugs, and given me the chance to run a few debrief’s, and provide some feedback on both the notes they have taken and how they have thought about what they were doing while logged into the system.  My next challenge is to give them a grounding in some test methodologies, without confusing them, so they can start applying differing approaches to what they are doing.

 

How have you approached training new testers? Do you have ready-made material or favoured techniques?

Long Chain Bugs

We’ve all seen them, your testing away, and something odd happens, application crash, unusual error message. you look back at what you were up to, retracing your steps waiting to see the same behaviour repeated, yet nothing shows, you end up digging around into system state, other applications that were running as well, other people who were in the environment as well, sometimes we can work it all out, a lot of the time, at least I, can’t. Well as I found out recently at a medical appointment I attended with my other half, it would seem that the medical community has long chain errors as well.

My partner has Lyme, she’s been very unwell with it for a number of years, and we recently had the chance to talk to a top-flight consultant about her condition. What they explained was Lyme Borreliosis Complex (LBC), as they have dubbed it, is a complex condition that has only in part to do with a single event. The system state also needs to have a variety of conditions meet for that bite to then cascade into the horrible condition that LBC is. They are not sure what the precise conditions need to be, they believe its a combination of genetics, familiar health, and environmental.

At, this point I had to try very hard not to hijack the appointment and start talking with them about how they are researching this and have they seen the very cool ted talk about a multi-disciplinary team that tackles big challenges that have eluded specialists.

It has made me think about how people who have practised testing, understand the mindset required to untangle these complex scenarios could have incredibly interesting and fulfilling jobs if we could convince other communities of the value and benefit we could bring.

Have any of you had the chance to bring your testing skill set to unexpected places?

Mewt 5 is coming, tomorrow!

So tomorrow is MEWT 5, and I’m attending!

I’m very excited about the opportunity even if I’m some apprehensive about the whole standing up and talking bit. I hope that I can contribute to the conversations, I’m sure I will learn plenty as well.

 

Looking forward to meeting some more testers, and learning from their experiences, especially if any of them has done project of a similar scale to the one I’m currently involved in.

I will post up about my experiences at MEWT what I’ve learnt, how I found it, for now though I’m just very excited about the workshop.

Do you know what testing is?

So you are working on a project, large or small and you are working with a variety of stakeholders, some may know what testing is, some may think they know what testing is, and some have never even thought about it.
So what do you do?
For me this one is an easy thing to address, I tell them all what testing is to me, in small bit size pieces. Using plain English, and alway checking back with them about what they mean when they use technical language, always phrased as ” just so I can understand..” not so I can correct them, so I can make sure I really know what they mean, This goes for technical people more than any, I sat in a meeting with a system architect lead, interface lead and developer lead, and they all had a different definition to unit testing (or developer testing). If I hadn’t asked it would have gone unsaid, assuming they all meant the same things.
People who don’t know what testing is, you have to show them the value you bring, demonstrate why what you do, makes their lives easier. Telling them isn’t enough, they have to see what you bring to the table otherwise you are just some strange IT role.
Be open and inclusive invite people to see what you do, help them see why you ask the questions you do, and never fear being challenged, just make sure when you respond to that challenge its positive, clear, easy to understand and relevant, they aren’t saying your wrong, or not needed, they are really saying I don’t understand why often with little realisation that this drives what they are saying.
If you want to do well in the professional world being able to demonstrate your worth is a skill that is worth developing, as the way you demonstrate it has to change according to the audience, you have to be able to explain in terms anyone can understand and defend why you have done or are doing what you are, especially if they come with preconceptions about what it is you do.
James Bach and Micheal Bolton tester story is an invaluable tool here (These are the people who I first saw this from not sure who’s idea it was first) It gives a framework within which to think about the differing side of what you are doing, and how to address questions about it to support why you have chosen to do what you have, when you have.
It’s all about understanding, what the concerns are, and how you can provide assurance to the stakeholder who raised it, that you will be able to provide them with proof/information/demonstration of that area so they can make a judgement on how happy they are with it, for example, in my current project the speed of order entry for the trade sales team is very important, they need to be able to work through an order flow, including placing individual lines on an order at the speed of speach. We are addressing this through demonstartaions and timings of screen loading, so the Trade sales manager can see how fast it is and make a judgement of if they are happy with that.

Assumptions

Over the weekend I happened to read an article on assumptions and if we should be making them. The article talks about the writers progression from the assumptions are bad, to assumptions are okay if they are reasonable. It was interesting to read the progression of the writers thoughts over the use of assumptions. They went from, as a younger person following the adage about asses, to coming to realise that some assumptions are part and parcel of life. 
However, it struck me that  we could do with a better education when it comes to this type of reasoning within software testing. Too little time is spent talking about how you investigate something and the process that you go through to come up with theories to test, most sciences, both the more classical and social sciences spend time teaching how to investigate, and the use of assumptions.
It reads to me like the author is talking about beliefs, those things that drive our assumptions. If they had dug a little deeper and thought about these assumptions maybe they wouldn’t have held them in such low esteem.
We could rephrase the article, rather they are talking about justified beliefs, in the epistemological sense, or we are using them to form part of an ampliative argument. In either case, the negative connotations of the “assumptions” should be removed as you are no longer talking about the vague process of making a guess at something, but it is a considered idea that you believe is supported by the available evidence.
Both of these play a large part in the process of assessing a situation and forming a hypothesis that you are going to investigate further and are held in much higher regard than the simple assumption.
I think that if we could move to accepting that this is the normal process that is gone through, and start using the techniques that are available in other disciplines that rely on investigations we would be able to share in the developments in ways that you can investigate.

New Year, New Challanges

So i hope everyones new year is going well, so far mine has kicked of to a great start, got my certificate for successfully completing the foundation BBST testing course, very happy about that. I highly recommend the course, it’s packed full of great material.
I also gave a well received presentation on the test strategy for the ERP project at work to the 30 or so core individuals of both work and the reseller of AX that are helping with the config and installation, lots of questions, hopefully answered to everyone’s satisfaction. Its been a long time since i’ve done any presentations so I was rather rusty, so I watched a few good presentations and did plenty of prep to ensure I knew what I wanted to say and at a good speed.
Now I have the challenge of moving it forwards, so I have a couple of exercises to detail, one to help them understand the initial activity of working out what we could test, I’m planning on taking a simple object and running a session or working out what all the testable elements of that are. Secondly I’m going to try running a version of the dice game, so they can practice thinking about how they understand something.
Then I just have to plan out how I’m going to train some people who’ve never tested before, so they can help out testing on the project.
Busy times ahead.

Testing – What to know and how do I know if i’m on Track

So we testers generally end up on this path by “accident” , there are few of us who set out looking to be a software tester, most of us end up here through a progression of roles that orbit some of the skills needed to test, and finally fall into an actual testing role. Now I’m happy to admit that i’ve met few testers, and my generalisation is almost certainly more applicable to the older generations than the youngsters of today, however I think the same things will apply.
When I fell into an actual testing role, I was largely guided by what the dev guys wanted from me, Basically a squishy computer, lots on input output checking, very dull. But i’m one of those people who can focus and get on with stuff like that, so I did.
While doing this I thought I’d better have a read around testing and find out what the techniques were, good ways of doing stuff, anything I should know, you know that handy stuff that makes doing your job easier.
So I Googled testing and kept running across this ISTQB test qualifications and syllabus stuff. So I spoke to my boss, pointed it out, and we got access to the course content, I dutifully began studying it. It was dry, dull and seemed so much like those big litigious businesses that we so hate dealing with, all their pointless paperwork. Not a great sign, I got about halfway through the course before I ended up skim-reading the rest.
Time to use some real Google-Fu, I actually have a certificate in that you know, I dug around online looking at testing info, and started to find references to context driven testing. So I read what I could find with my initial searches, and boy did it make so much more sense.
But what’s all this got to do with the knowledge base needed to test?
Well for those of you who haven’t looked into context driven testing, you should, but you’ll find a name and blog crop up quite a bit, James Bach, and his blog.
What I have found, probably coming to the realisation over the last 6 months, is real testing is something I’m crazy passionate about. why? because it offers such a world of mental engagement and complexity. I took me a few time of looking at James’s Testers Syllabus to realise quite how much all of this draws me in.
Where am I going with this? Well after discovering this other land of testing, I have read a few blogs watch a lot of conferences, perused some books and generally been absorbing the atmosphere, It’s hard to quantify where I’ve got to, and where I should concentrate next, mainly because there is so much to know, so many topics that are worth learning. So I struck on a solution, on James’s blog there is this fantastic mind map for a testers Syllabus, so I plundered it for my own uses. Not only does it give me a framework of great topics, as estimated by someone who I think has a great deal of useful things to say about testing. But I allows me to track where I have focused my attention, and where i’m a bit light in knowledge.
So I’ve copied James’s mind map, and started to recorded on it details beyond where it stops, so specific points, concepts, books, classes etc.
What has this given me?
Well a great way of seeing what i’ve been neglecting, where I have focused, and what I currently think I know something about.
I’ve done this because testing is a passion of mine, I have found a place where I can mentally fit, a job that gives equal parts engagement and challenge. It is something I plan on doing for as long as i’m working, and I will be brilliant at it, but only if I keep learning, and pushing what I know, into all the areas that will make me a better tester, this mind map gives me a way of seeing how i’m doing.
There is a long way to go but all journeys begin with one step.

Now I just need to find this fabled community to match wits with, not that i’m ready to do so, but talking about testing really helps to understand it. And I plan on really understanding it.

Test strategy

Over the past few months I’ve been working on a test strategy at work, some foundations for doing better testing, it’s been a lot of work but I’m slowing getting there.
There’s been a lot of re education, and educating from the start for a variety of levels of people across the business.
yesterday was, in my mind a break through, It’s been agreed in principal, and will be used on one of the largest projects we have done at work. 
How did i get to this point?
A lot of conversations, me learning enough about all the elements that I could answer any question, and debate any point with any person. repeating myself, in a variety of meeting with the same people. Having confidence in what i’m doing helps as well, the fact I truly believe that this is the right thing for us really help, I think at times it overwhelms my restraint and I can get a bit pushy with it, I do try to reign it in though.
So where am I know with it, I have a strategy doc, it needs a bit of additional detail around the edges, but we are moving forwards with it, and in the new year we will begin the implementation of it for the project, Really looking forward to that.
If you believe you can help the quality of testing where you work, you can make a difference, it takes passion, and patience, you have to be prepared and able to explain any part of context driven testing, at a multitude of levels, to a variety of people. If you can do this, you can slowly bring them around to seeing the benefits of doing it. You have to be aware of your work places particular worries, and hang ups, so you can address those in detail, and with confidence, if you don’t sound like you know it’s going to work, and be an improvement, you are not going to convince anyone else either.
Make sure it rests on a base of solid detail and fact, with actionable processes that satisfy your works needs. I started with the Dev team leader nearly a year ago, why him? because I have a good working relationship with him, and his opinions are well respected by the heads of IT, so when I got him on board I had a powerful ally. You don’t have to start with the main decision maker, its often easier to start with those that surround them, and slowly work your way along, addressing worries, providing details, and example, showing how it could work for you.
If they say no, find out why, understand what’s behind that, go away and understand that, and how you can address it. Its an achievable goal, you just need to make that first step.

BBST foundation in software testing

So I finally finished the course this weekend, and it was a fantastic one. Really engaging and thought provoking.
I’d really recommend it to anyone new to software testing, or new to the context driven school. There is even plenty of content for those of you who are familiar with the techniques but haven’t yet formalised what they know.

Counting those Test Cases

So we are working through a test strategy for a big software rollout at work, change of ERP for those of you that are interested.
As you will have read in my earlier posts we have a consultant in to help us with this, He’s done a great job of highlighting some pitfalls we have overlooked, and suggested some thing that we really need to be considering. However he also has a huge amount of work in his overview for writing test cases, writing test scripts , then running those test scripts. I have challenged him on this, I have suggested that we would be much better of if we used Exploratory Testing, and get the SME’s (subject matter expert) to use this rather than us writing thousands of test cases which, mostly will need rewriting as soon as the business gets a good look at the software and changes a load of stuff, like they normally do.
He seemed bemused that I’d want to take this approach on such an important project. I did my best to explain the benefits of the context driven approach, but I’m new to the whole thing, so we will see how well I do when we attempt to restructure the plan today.
Any pointers on how to sway people are gratefully accepted.