Technical, Non-Technical Testers, and what does that even mean!

So it turns out that I get quite annoyed when the terms Technical, Non-Technical testers are used to describe what my team of testers should, and should not be doing! I was recently in a heated conversation about getting access to read some SQL based ETL’s and one of the reasons for us not to have visibility of this was my team are not technical testers, and as such shouldn’t, and by implication, can’t read such things.

So let’s explore for a minute what I think when I hear those words, I think more about someone who builds tools to use in testing vs someone who does not, what I’ve also heard called test engineers and test analysts. At no point does it cross my mind that you’d be talking about a code illiterate person or even someone incapable of looking up the bits used to get a general understanding.

So upon hearing it used in this way has caused an irrational response, one of annoyance. I can’t help think that maybe it’s down then to how I think they see a person they are describing as incapable of reading code, my insecurities rather than their intent? beware your own biases they can really colour a conversation.

Unfortunately, the knowledge that I’m annoyed because of my personal interpretation hasn’t reduced my annoyance at the whole situation, life’s a bummer.

I disagree with the test team not having access to the ETL’s as I personally feel the documentation of them isn’t as good as the ETL’s themselves, sadly it’s not my call to make at the end of the day, we work with what we have, and I have to put my frustration aside about this and get one with the many tasks I still have to do.

How do you deal with situations that have both  an emotive content for you, and you disagree with from a project/task perspective?



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?

Test planning, so you want more time!

If you’ve been involved in test planning you’ve no doubt encountered the questions, “Can you do it in less time?, What if you did test like this, is there a quicker way? what if we get some of the business to do all the testing for you?”

There are more questions like these as well, they all tell us something about the questioner, about how they are thinking, what matters to them, and they give you options to talk to them about. Testing can normally be done quicker, it’s just a question of do you want the risk that is associated with doing so?

So we are near the end of a change of software in part of the warehouse, there’s loads of config, some development, and a tonne of business understanding to gain. This is the second time we’ve tried this, the first time the business wasn’t at all happy with the config, so it was back to the drawing board for the project team. So now we are near the end and there won’t be a third chance so it has to go in, and be right. I haven’t been on this project, as you may have read in other posts my focus has been on the ERP we are putting in. However they are near the end and are worried it’s not going to happen, so I’ve been moved back to this one and basically asked to make the testing fit in the short time that is left. It’s all driven by the overall project budget, basically getting more money is going to be hard, so I have to look at what’s left and work out what not to do.

It’s all about risk here, the work is largely split into to pieces, the interface work, moving data via a bus between the new system and existing systems, and the new warehouse system itself. The interfaces have to work, but we control most of how the data arrives, so we can do a reasonable job on that without having to do to deep a piece of testing, and the warehouse system has had people all over it for months, there are in fact a group currently signing off business processes and user stories against what the set up in the system is, so they will have a good chance of seeing if the basic flows don’t work. So my sales pitch is more focus on the interfaces, less on the new piece. The focus of testing on the new warehouse piece would be the edge cases that the team signing off the basic flows are unlikely to go near.

Yes the state of what’s going on is far from ideal, but it rarely is, so we work with what we have, I’m often reminded of the scene in 13th warrior where they are on the boat and the northmen are laughing at the storm, show no fear, laugh at danger. There’s no point bemoaning the state it’s all in, get on and do what you can, make it work as best you can with the time and resources you have, flag risks if they are too much for the business to bare they will say. Your job is to let them know what these are and do the best you can to help get the project past the go live.