Testing the Boundaries of Testing
My current project is quite busy right now for me. I'm on my forth week of overtime, and despite being prepared for the crunch, I'm becoming a bit weary. Therefore, I'm taking a break to share with you a few things I've learned recently about testing as a consultant. I've heard many testers explain what is and is not in the scope of their "job" as a tester. Strict statements, such as "It is my job to provide information, but I don't assure quality." or "I make recommendations, not decisions." One of my favorites, heard recently, was "You are a consultant. You provide suggestions. It could harm your longevity with the client if you forget that!" Wow. There are some strong feelings out there about what boundaries we testers must stay within. Being a tester, exploring boundaries is quite natural for me. In fact, if I never check them, I could be guilty of self-limiting behavior, which is worse than testing boundaries to me.
I see my role as a consultant to provide what is needed for the project to succeed. Sometimes that is testing information. It certainly includes a solid testing strategy that adapts as the context changes, and it does include testing that is improving over time. On this project, I've created a new section to test plans that my boss plans to use for future test plans, I've started creating draft read-mes and delivering those along with some documents to help users to the tech support team which supports our product (along with dozens of other products), I'm doing the planning and documentation for UAT, and have done research to inform the deployment plan for the project. None of these things are traditionally testing tasks. I feel fantastic about this! Teams are smaller. The teams I want to be on should hire a flexible person who will grow over time. I want to keep learning skills. I also want to work with Developers who do what is needed. You need a diagram on how X works with Y? They will draw one on the white board to use for now, and possibly revise it later, but they don't wait for the planets all to align and a new analyst to be trained just to stay within their job description. This is part of the freedom of being a team member, and not just a role or list of skills. While not all of the tasks we do fit into "testing" strictly, I'm a consultant. That frees me up to do what is needed, which is not always testing.
I see my role as a consultant to provide what is needed for the project to succeed. Sometimes that is testing information. It certainly includes a solid testing strategy that adapts as the context changes, and it does include testing that is improving over time. On this project, I've created a new section to test plans that my boss plans to use for future test plans, I've started creating draft read-mes and delivering those along with some documents to help users to the tech support team which supports our product (along with dozens of other products), I'm doing the planning and documentation for UAT, and have done research to inform the deployment plan for the project. None of these things are traditionally testing tasks. I feel fantastic about this! Teams are smaller. The teams I want to be on should hire a flexible person who will grow over time. I want to keep learning skills. I also want to work with Developers who do what is needed. You need a diagram on how X works with Y? They will draw one on the white board to use for now, and possibly revise it later, but they don't wait for the planets all to align and a new analyst to be trained just to stay within their job description. This is part of the freedom of being a team member, and not just a role or list of skills. While not all of the tasks we do fit into "testing" strictly, I'm a consultant. That frees me up to do what is needed, which is not always testing.
Posted by Testy Redhead at 17 Jan 2011 
Categories: value, Human Testing, test planning, Methodology, test strategy, Software Testing, Trends, Working with Others, career development, methodology, test methdology, Interviews, test documentation, agile, Human Bias, language, consulting, Ideas, testing ideas, testing
Categories: value, Human Testing, test planning, Methodology, test strategy, Software Testing, Trends, Working with Others, career development, methodology, test methdology, Interviews, test documentation, agile, Human Bias, language, consulting, Ideas, testing ideas, testing
Fortunately, my contracts and statements of work are all pretty clear as to what I'm going to do, whether it's testing, managing, or shepherding. That takes a lot of my internal pressure off, as I won't try to do it all in 80 hours.
Reply to this
That makes sense! On this team, I have one clear functional lead on the project. I make sure she is the one who sets the priorities. I ask her if she would like "this" or "that" with my time, and also explain when it will cost overtime. The fact the client pays for overtime means it doesn't generally happen unless there is a GOOD reason for it. She is pretty good about understanding risk & reminding me that they are comfortable with it (more than I am!)
I do have to watch for scope creep in my job, and makee sure I don't become a default dumping ground for work. That HAS happened before. Part of the reason is because I enjoy work and I like being needed, but the other part is because they know I'll do it, even if it isn't good for me.
Reply to this
In a non-consulting context, I believe employees in any field should:
1. Provide any service require/valued by the company with a positive attitude. Even if such service is outside the scope of one's title.
2. Excel within in their career.
Just to clarify, "any service" in point #1 assumes that the service is an ethical one.
If an employee is in an environment that is allowing them to grow professionally, then occasionally performing tasks outside of scope should not be taken as such a big deal.
Problems can arise when one has to take on so many out-of-scope tasks that their career advancement is reduced to a halt.
And perhaps those who are quick to say 'no' to out-of-scope tasks are just trying to avoid that situation? Managing people's expectations?
Reply to this
I see a few issues facing testing. One issue is that testing, as a profession, has done a piss poor job of explaining what exactly it offers as value to business people. I have so much to say on this topic, it will have to become a blog.
Secondly, are the bugs we write important to our business? They should be if they are important to the users, but how do we know that? The feedback loop between the users and the business is way too long. Also, the loop between the poor schmuck using the application and the person who buys it for them, makes the decision, and never has to use the dang stuff is also unreasonably long. So, how can it be solved? I've seen some terrible attempts at making our output hard science and trying to s show RIA which turns into snake oil sales and dudes who come in to a company, start expensive initiatives, and leave with tons of money for the next place claiming great results while NONE of the changes actual stick and no user benifitted.
We talk about people being change resistant. They SHOULD be. I call it being right, or having experience. It only takes a few failed "initiatives" until you have whiplash and realize the changes are often poorly disguised scams. In fact, there is one pyramid scheme scam where you get ranking belts. The presentations are kind of like Amway. You get martial arts metaphors with none of the health benefits.
Well, I gotta run. Bitter, party of 1, your table's ready. My goal is super simple. 1 tester still working doing testing. The more of those we see who are valued, the happier I am. I just want to work in testing, and help others who want to.
Reply to this
I sounds like you've done an effective job at combining testing responsibilities with what are commonly considered product management tasks. This is an excellent practice from the view point that the tester is the user advocate within the engineering team. The problem I encounter with job definition is that of the developers wanting you to do some of their work for them. Often I hear, "I'm busy, can't you just fix that bug for me" or "You should be writing unit test for my code, that's TDD". Do you think that some of the value of having an independent tester is lost on having a coding-centric focus in place of a user-centric focus?
Reply to this
Very nice post! I have found myself recently using the saying that testers provide information and not assure quality. I think Mr. Bolton planted that in my head. I also may use the phrase a defense mechanism because testers get blamed for everything. It really is everyone's responsibility to focus on quality. I have been chanting that at every available opportunity.
I like your perspective in that we should be challenged to do whatever is necessary to make better products.
Thanks for the reminder!
Reply to this
Great, I like this post. Thanks for shraing this article.I am also intrested to know the actual roles and responsiblities of a QA & Testing Expert.
Reply to this