When you are planning for your tests, either small-scale plans, just to look at a single feature or change, or more complex plans for testing and application there are a few steps you can go through to help ensure you have to revisit your plan only when your understanding of the SIT changes rather than the requirements for the plan changing.
Be clear from the start who is using your plan, is it just for you to help plan what you are going to test? is it for the test team to allow for a shared understanding? or will it be used by the wider project?
Having an understand of this will enable you to include the information that the rest of the audience need for the plan to be helpful for them. You may find that a single plan isn’t sufficient as different people require dramatically different information.
Where the test team may only need a loose plan to help the achieve good coverage the project manager could be wanting to understand resources or duration and stakeholders may want to be able to see that what they are worried about is getting sufficient testing to give them comfort once live it will be reliable.
Understanding the differing requirements for any plan you make can help you produce one that is fit for purpose, in my experience the easiest way to do this, is to create an outline of the plan, something that doesn’t take too much time to do, and share it with those who will be looking at your final plan, speak with them about what it tells them and what they need to know that they can not see, incorporate what you can, make compromises where there are too many conflicting needs.
This will help you create a plan that works well for most people the first time and hopefully reduce the number of times you need to revisit the plan.
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?
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.
Well he’s been in for a week today, we have bombarded him with info, he’s taken a fair chunk on board, not done much questioning though, not sure why. I am sure it’s not because we have covered all angles.
I should get a chance to see his strategy doc either today or monday, from what I have gathered so far it’s going to revolve around the factory school approach. So he’s looks like he’ll be suggesting a more longer time frame, or higher resource requirement.
So hopefully in the next couple of days i’ll get the time to talk through with him about an alternative approach, he does seem open to the ideas of exploratory testing, and context driven testing, he’s just nervous about it in a project as I don’t think he’s ever taken that leap.
We’ll see how that goes.
He is thankfully highlighting the risks for the business about what we are doing, and how much work is involved, so we should be viewing those more seriously now we have a paid for opinion on the matter, more on that another time.
What have i learnt from this week so far, just because they have years of experience, doesn’t make them a better tester than someone who has a better understanding of the context.
That experience has helpful insights but it can also carry over problems from their experiences.
we’ll see how the next week goes.
Well I get to move on to a massive new project in the next few weeks, really excited about it, I’m nominally named as the test lead, not like there will be many people to lead though, we do have a new tester starting in november, taking to total number of dedicated testers to two, I know good isnt it. I should have some project resources for testing as well though.
Why am I so excited though? Well its my opportunity to demonstrate that exploratory testing is a worth while thing to be doing, that gives tangible results, and works on the largest of projects, this is the biggest thing we are going to be doing any time soon.
The downside, I get this wrong and they won’t support ET any time soon, that and it could cost me my job, but hey I’m willing to take the risk, as I believe it will work and that we will show them that test case counting is pointless and a waste of valuable resources, and you never know i might get a new job out of it if I can play my cards right.
We are going to be installing a new ERP over the coming months, I suspect longer than they currently think, but that’s definitely for another time, and I will be responsible for providing updates on testing, bug tracking, test management and resource coordination, currently. We are getting a consultant in to help produce a strategy, and give realistic time frames and resource requirements for testing a project of this size, how much we agree is something that I will find out when they get this guy in. I might even post about it if it goes well.
I plan on ET with session based management to ease the company into the realms of real testing. that I will most definitely post about as I go along. It all starts in around 4 weeks for me. Here’s to it going well, lots of hard work but I am looking forward to it.