Software Testing - Increasing a Tester's Usefulness
This discussion is a bit old, but you will still find it relevant if you have not read it earlier on sqaforum. Original question from Elfriede was as follows
 
I am preparing for a feature presentation on the topic of "Increasing a tester's usefulness as QA becomes less valued."

Right before the year 2000 testers were in high demand. However, after the big hype, the .com bust and given the current state of the economy, software testing is now outsourced and is often seen as unnecessary overhead.

How do you increase your perceived value as a tester in this current market? Are you still in the testing field? Some of my tester friends are now doing Sys Admin and other type of work. How has work life as a tester changed for you?

Here are some of my suggestion - the more detailed reasoning for these suggestion is provided in my presentation:

Take software development courses, i.e. C#, ASP.net, Perl, Java, etc.
Become an automated tool expert, i.e. QuickTestPro, Robot, etc.
Specialize - Become a performance testing expert.
Become a white box and gray box tester - black box testing is only a very small part of the testing effort
Understand networks and system administration, take a networking/sys admin course
Understand firewalls and firewall rules
Understand databases and sql
Help out in the requirements gathering process
...
...
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mstei15631
I really have not seen a difference in perception pre and post 2000. Jobs in general are down, so there are not as many QA openings. But to me that seems tied more to the economy in general than the perceived value of testing. I have worked in QA and Testing for close to 20 years and in my opinion this discipline has always been undervalued and always seen as somewhat unnecessary overhead. Perceived a little better perhaps in a commercial software development environment rather than an internal IT department. On top of that, every company that I have worked for has a different opinion of what QA and/or testing is all about, and who should be responsible for it. And those opinions are usually very hard, if not impossible to change. So I've found it best to adapt to the company, that is to find a niche doing something that they see as valuable. In my current position, that is automating regression testing and also performing some project management tasks. In other places it has been strictly functional testing, in yet others more of an EDP audit role. I've counted function points, defined lifecycle methodlogies, created departement budgets, been in charge of configuration management and the list goes on and on. To be cynical, sometimes I think that QA gets dumped whatever the rest of the organization does not want to deal with.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael Hovan
Good question!
I have been "alternatively" employed since May of 01. That is 2.5 years of contracting and temping and scrambling.
My current contract is due to be extended again. It will have gone from 3 months to 18 months. Maybe I got a bit lucky.
The shop hired me to be a "technical writer". Seems that means requirements, design, and validation scripts to them. They have NO software process. It is a medical device company! [Eek!]

Well, having been trained in and practiced good process - I simply applied my knowledge and ability to the job at hand. The project managers consider me to be an integral part of the team. They are lobbying heavily with upper management to get me on board full time. "Validation Manager" is how they describe what I offer and do.

Yes, I had to eat a great deal of poo. The original hiring manager saw me as her personal secretary. It was a chance to get even with men. Thankfully she moved up the ladder and I avoided going with her. I was amazed at how many other folks commented on the added value once that shake out occurred.

Long answer - so sorry - feeling chatty. ;-)

I guess the end result is to do what you do to the best that you can do it. I have learned from my mistakes. Every project has seen incremental improvement. I was nice when others weren't - that one has payed off with great dividends.

Be nice. Be competent. If those traits aren't valued, the place may not be worth working for.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
KBEE01
Hi Elfriede,

Perhaps the largest impact I have felt in recent years has been more to do with changing the country I live and work in as opposed to the changes from any other aspect.
However, I will try to be more "international" in my observations.

As I have discussed in several threads on these forums, one major problem is demonstrable value for money or ROV (return on investment). In some ways we are our own worst enemy in concentrating on improving our methodology and ignoring the politics of "selling" our services.

Although I see the value in your suggestions, I would strongly argue against all of them as policy. Why?
It depends on your aims – to make more jobs available to an individual, or to address the problem of undervaluing QA/Test. Your suggestions are good for the former only.
Taking that path is pandering to the image that QA/Test are insufficient skills by themselves to be of value! To me, a professional tester that has none of your suggested skill sets is still an extremely valuable commodity!
(I have several of those skill sets myself, have used them, so I am not arguing from self-interest or ignorance) [Smile] (We have been recruiting over here for many months, and the trouble we have had finding someone with "just" those skills has been a nightmare) [Frown]
Your suggestions may well be extremely valuable when applying for a specific job, or may increase the number of potential jobs you can apply for. But, they do not address the most important aspect of your initial theme "QA becomes less valued".
"QA is being less valued, lets add some more skills to make it more valuable" is not the answer.

So, how do we address the underlying problem?

Let's look at the real problems:
1. Money is tight
2. The horrendous attrition rate with new projects
3. Promising the customer heaven/ pricing before we fully understand the requirements
4. Competition is high, time to market is critical
5. Corner cutting is not always immediately punished
6. A culture of "get it out the door, deal with the problems later"
7. A culture of "range of features is more important than quality of each feature"
8. Prevention is always harder to cost justify than cure
9. Fully implementing total SDLC QA/QC/Test is expensive
10. Waterfall is dead, XP/Agile is the future. Who needs separate testers now we do test driven development?
11. So many involved in QA/Test see it as a bug hunt and fail to value pragmatism.

Some of these we in QA/Test can try to deal with, some we will have to continue living with!

I think I have some answers, but certainly no blanket solution, no silver bullet.

I have been trying to generate discussion along these lines with some of the more “controversial” themes I have kicked of on these forums.
Perhaps one or two high profile major financial disasters directly attributable to poor/absent QA/Test would solve this problem for us! [Cool]
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Jeanj
How do you increase your perceived value as a tester in this current market?

Since the market downturn, I have sought and achieved two certifications.

I take every class and seminar I can, that is QA related that I can afford or get discounted rates by volunteer work.

I attend as many QA user group meetings as I can to learn and to network.

I am active in on-line QA discussions.

I watch all openings for QA personnel, and try to match my learning objectives to the needs of the market, and to tailor my resume to reflect most the current needs of the market.

I continue to communicate with all possible contacts for job openings, giving and receiving information about current QA market trends and needs.

Are you still in the testing field? Some of my tester friends are now doing Sys Admin and other work.

My title is still Tester/QA Analyst, but my duties are now a bit broader than just testing. I find that I am performing some of the duties of a BA, PM, Tech writer, trainer, as well as requirements gathering, metrics analysis and testing.

How has work life as a tester changed for you?

In some ways the life of a tester is a little easier because some of the corners are again being cut due to monetary issues. “Again” meaning that some processes an philosophies of testing that have only been put in place since the mid-90’s have been reduced in volume to make testing occur in some of the same types of environments that testing occurred in the 80’s. Less paperwork, fewer steps in the testing etc.

Although this may be described as “easier” as I did above, in the long run, the products being produced are not of the quality that would cause me, as a tester, to be satisfied with my work. In the 80’s, we may not have known what we could do to help improve testing to the point of better quality software. Towards the end of the 90’s, we learned and implemented a lot of safeties and checks. Economic frailty in 2002-2003 has caused us to discard some of the best ideas of the growth of QA in pre-Y2K studies. I hope we learn soon that we are not saving anything in the long run.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Jeff Nyman
Agreeing with Daniel's point, I am speaking to the methodological assumptions that are inherent in this kind of questioning or this kind of poll, which leads to flawed correlations often being drawn. For example, the general theme here is: "Increasing a tester's usefulness as QA becomes less valued."

Now this presumes that the notion "QA becomes less valued" (by which I assume you mean the perceived value of QA) is normalized. Does every organization do this? To the same degree? What does "less valued" actually mean? And what is the context in which that "less valued" plays a part? (Is it because of money crunches? Is it because one manager simply "does not believe in QA"?) Likewise, does this include organizations that view QA as "just testing"? Might it be that some organizations place little emphasis on strict QA but still place great emphasis on testing? What about those organizations who believe that more testing should fall to the developers and so structure teams that way, without as much reliance on separate test teams?

Also, you say: "software testing is now outsourced and is often seen as unnecessary overhead."

Is this "and" an inclusive "and"? In other words, are you suggesting a causal relationship between the two statements? Methodologically, that needs to be clear. In any event, it seems we are talking about strict testing instead of overall QA? (And do we include hardware testing or just software?) And if testing is outsourced, there is still value seen in it, apparently. If there were no value at all, my guess is no outsourcing would take place at all. The connection between "being outsourced" and "perceived as unnecessary overhead" normalizes another issue.

Regarding the question: "How do you increase your perceived value as a tester in this current market?"

For myself, I do this a couple of ways:

* By showing that I can apply a variety of test types and test techniques that are adaptable to any given situation in which I find myself.
* By showing I understand that testing is contextual and situational. There is not necessarily "one answer" or a "best answer" and thus I look at things that way and show that I am after the answers that make sense relative to the organization.
* By writing white papers at the company I work at or publishing papers that attempt to show I have given thought to various issues relative to the notions of Quality Assurance and Testing.
* By developing a Web site that I take seriously and try to showcase that I treat the field as more than just a job I do.
* Increasing my skills at debate and communication as well as keeping up on my writing skills.
* By learning programming skills. Not only does this help in dealing with developers, but it means I can leverage unit test tools, automated tools, write custom applications or scripts, participate in (or at least get value out of) code reviews and inspections, etc.


These are just some of the ways. Increasing your "perceived value" is a tricky way to ask that question because it presupposes you know how your value is perceived by others. Likewise, what is of value to one perceiver may not be to another. Now, if we are talking about our own perceived value, then that is what my list above speaks to. My goal is then to show why my value (as I perceive it) should be translated to an employer's notion of value (as they perceive it). And that is really one of the fundamental questions in a tight job market: how do you determine what is perceived value? (It is really a corollary to that question we often get asked when we are inside an organization: "What is the value of QA?") A follow on to that is: how do you translate your notion of perceived value into a notion that is palatable to employers?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Scott Barber
I
've read this thread about three times and I finally figured out what bothers me about it. "Perceived value" to whom?1? I can increase my "percieved value" to a perspective employer by spell checking my resume. I can increase my "percieved value" to my current employer by getting my contract extended. I can increase my "percieved value" to the QA industry as a whole by publishing articles, speaking at conferences and answering questions smartly and politely on forums.

I think "perception" and "value" are two seperate issues. A better question might be...

"What have you done to become a better tester?"
++++++++++++++++++++++++++++++++++++++++++++++
Elfriede
To get this survey back on track and to summarize(also posted on http://www.softdim.com as my presentation summary):

During the tech boom software testers were in high demand, and it is a widely known fact that companies even hired people without a technical background to do the tester’s job. Yet in today’s market of lowered IT budgets, testing is often perceived as an unnecessary overhead and is often first on the list of required budget cuts. More than ever before, it is imperative that the tester is technically adept and that the real value the tester provides is understood and is communicated.

Admittedly, some test professionals haven’t seen much of a change from the days of the tech boom, especially those working for Government contractors, etc., or testing professionals overseas where the demand for testing professionals has increased due to outsourcing. However, many testing professionals here in the US have had no other choice but to move on to alternate fields or adapt otherwise.

“Perception is truth,” is what I have often heard my former boss say, who was responsible for managing a multi-billion dollar contract - and while this statement applies to many areas, it especially applies to the area of testing, because it is often difficult to quantify the value of testing.

My presentation – one of the reasons I started this survey - will discuss how testers can increase their perceived value, if needed. Gauging by some of the posts here and responses to my email account, this is the case for many.

Following are suggestions of how testers can improve their perceived value:

- Become proficient in software development: Gain experience in software development through various means, i.e. using books for self-teaching or working with the software developers writing small modules and then building on that knowledge.
- Become unit and gray box testers: By taking additional software development courses, testers can now execute unit tests and become gray box testers, for example. Black box testing is only one facet of the software testing effort, gray box testing can be much more effective. The usefulness of testers doing unit testing and the value of gray box testing are other topics to be discussed
- Use automated testing tools: After having some development courses under their belts, testers will be able to use automated testing tool scripting languages more efficiently and they can now develop their own testing utilities, whether in Java, PERL, or C++, etc. They will also be able to make better use of the GUI automation tools.
- Take network and sys admin courses: If testers understand networks and system administration they can help setup and tune networks, using network sniffers and performance testing tools, among other tools.
- Understand firewalls and firewall rules; understanding all parts of a system architecture; databases; SQL queries; understanding various OSs, etc.
- Wear many hats: For example, many commercial companies don't want to invest in the overhead of maintaining a separate requirements management team. The best people to develop requirements are the consumers of the requirements, testers being one of them. Being cross-trained and helping out in the requirements process can be very valuable to the testing professional.
- Adapt to your environment: Depending on the environment and the greatest need, testers can either specialize and become experts in a specific area, or focus on improving various parts that make up the software development lifecycle.
- Become certified in an area, i.e. various certifications in the IT field are offered, whether it’s a Microsoft, Security, PSQT, etc. certification. A certification, which relates to the tester’s area of responsibility, is another way to stand out from the rest of the crowd.
- Be involved and stay visible: It is important to network – don’t do the tester’s job isolated in a cube.
- Solve emergencies and become indispensable: For instance use test tools for loading ad-hoc data not just for testing, but for example for training data, or conduct an "emergency" speed load testing and isolate a performance problem.
- Mentor: Conduct knowledge sharing with junior testers and other groups. Conduct training sessions and brown bag lunches for parties interested in learning about testing.
- Conduct Lessons Learned: Document and communicate any testing successes.
- etc.

As the software tester's day-to-day work life changes, the most successful testers are the ones who are able to adapt to their surroundings and needs and thus can help increase not only their actual value but even more important also their perceived value.

Elfriede
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Scott Barber
I'm about to stir this up again...

In Oct my family and I up and moved to Central, FL from just outside of D.C. Through a long, bizarre and unexpected set of circumstances, my old company and I parted ways. Virtually everyone thought I was crazy - that I would never find a good job with similar pay, no travel, less than 30 min from my house, challenging, leading edge, wear jeans to work, etc. Well, crazy or not, I found one. It took me a week. In that same week I got contacted by not fewer than 12 recruiters, headhunters and placement agencies - all with jobs in Central FL.

Some would argue that this is because of things like my participation here, or my articles, or my website, but the truth is none of the people who contacted me had ever heard of me before, and none of them cared about any of that. All they saw was "Over 4 years of experience in various Software Quality Assurance roles including..." After that it was all about "I need these things, are you the right person?"

I got a new job that I am very excited about and is a good fit for me because of one thing and one thing only. Their belief that I have the potential to do a good job and accomplish the tasks they expect me to accomplish. It's not about my certs, competencies, or perceptions.

Oh, and just to stir the pot up some more, one of my first jobs is to hire another tester. You know what things I am not looking for on a resume? Certs, software testing experience, programming, nifty degrees or testing tools. What I am looking for is a "well organized, detail oriented, explorer with a strong work ethic, good communication skills and is comfortable working with computers." I'll teach the rest. Did I mention that the testing I expect this person to do will be embedded device, driver, dll and API integration, installation, configuration and biometric testing as well as security, usability and probably more - all while we determine, define and put into place the right methodology for this organization for everything from CM to patch release verification.

I don't know where all these little checkboxes are coming from, but even after job hunting and now finally having the chance to hire others, my opinion has not changed that I think the people looking for the checkboxes are looking for the wrong things.

Just like the folks here offered me a job that I didn't have all the little checkboxes for because they believed that I would do a good job, I will fill what is now my department with other folks that I believe will do a good job, not folks who happen to have the right blocks checked in their careerbuilder.com profile.

Sorry, but I just can't by into this whole "perceived value" thing. If I can't add real value to an organization, then I need to spend my time finding someplace where I can add real value, not worry about how to increase the perception of my value.
+++++++++++++++++++++++++++++++++++++++++++++++++++
Scott
How do you make people aware and increase their understanding of your value.

Take a vacation. If it takes more than that, maybe it's time to question how much value you are actually adding.

Maybe you want people to understand your role better, maybe you want them to understand how much time it really takes to do your job, or the resources it really takes - that is different.

Certification, training show devotion and interest and certainly undeniably a greater understanding.

I'm sorry, I just don't think that is true as a blanket statement. I have absolutely earned certifications that I think hurt my understanding more than helped it. I have earned certifications for the purpose of industry partnerships, as well as for the purpose of finding a way to show a skill on a resume that I have no professional experience in. I have other certs that I am proud of and learned a lot from. There are even more certs that I never bothered to memorize someone elses multiple-guess answers to stupid questions about where an item lives on a menu bar because I thought they were demeaning. Which of those increase other's understanding of my value?

I have attended training to learn something new, to gain a resume bullet about something I already knew, to have something to put on my timesheet between clients, to support the trainer, to observe training techniques, to heckle and to learn about competing products/services. Which of those increase other's understanding of my value?

Sure there are other necessary traits to being a good tester. Communication and personality are important. A talent for ferreting out information and disseminating it are great. But really how long an interview are you going to have? Can the interviewee get this from you in the short time, maybe and maybe not.

My last interview had a 2 hour phone screen, a 9 hour round-robin style interview and a 2 hour call back interview. Even if I had not been offered (or had not accepted) the position, it was a WONDERFUL experience. It was SOOOO much more rewarding than any 1 or 2 hour interview I have ever had. At the end, I felt like I really knew something about the company I was applying to work for and that they really knew something about me.

In my experience, full day interviews are not uncommon. I have also been involved in (giving and receiving) 1-2 hour technical screenings. That is entirely different. If that is the only part of the interview process, I think the interview process is flawed.

The resume needs to reflect you are aware of what is needed to be a good organized and efficient tester.

The resume needs to make the reader say "Hey, I'd like to talk to this person." Nothing more, nothing less. Maybe certifications catch the eye of some folks, maybe Java courses catch the eye of someone else.

One person called me because we had served in the same military unit. As it turned out I did get a job offer (that at the time I didn't accept because I found out it involved relocation) and the person told me they really didn't think that I was a fit for the job and just wanted to chat about the military, but once we started talking...

Sure you can train an eager person who is interested but why?

Why?!? Are you kidding? I'd rather devote the time to train someone who wants to be a good tester who has little or no experience, than untrain someone who thinks they are a good tester because they went to some seminars and answered some multiple-guess questions correctly. Yes, somewhere on my team I want a techno-geek, but I also want one of those people who is ready to throw away their home PC because "no matter what I do, it always messes up!", and I want a writer/editor, and parent of small children, a realistic representative of the actual user community, and who knows what all else.

It's hard to find all that stuff in a 2-3 person team, but the point is that if we are all "testers" first and "technogeeks" second then we are all going to have similar biases and blind spots. No thanks. Why hire another "me" - why not just give myself double the salary and work a few more hours to find the same ol' stuff?


It all comes down to this... Are we talking about "what makes a good resume bullet?", "What skills make a good tester?", or "What to do to make other people THINK you are a good tester?" These are vastly different, and if we are talking about perceptions, I believe the topic at hand is the third and that is the position I am arguing from.

Recent Updates
Flash Objects and Selenium
Continuous Integration
Selenium Workshop
Delicious Testing
Pattern for automated testing of web applications
Exploratory Testing
 
Read More
Accessibility API Testing Article Backword BigBang Blackbox Blog Bottomup Boundary CaseStudies Certification DefectReport DistanceTest Equivalence FitNesse Geeks Graybox Guerrilla Testing Tips GUI HTA Humor Hybrid Internationalization Installation Integration Is it done? JUnit Measurement Mercury Quality Centre News One CPU better than two Patent PatternForAutomation Performace Checklist Rational Test Suite Regression Requirement Verification Research Rational Functional Tester Security Selenium Selenium Workshop SilkTest System Testing Templates TestComplete Tools Testing Types Testing Tools In News Testing Terms In News Testometer Test Plan TG Tips For Automation Top Down Integration Trait UAT UI Testing CheckList Unit Testing Usability VMWare Web Application Security Web Application Testing Checklist Whitebox Testing
Disclaimer  |  Privacy Policy  |  g e e k AT T e s t i n g G e e k DOT c o m
© Copyright 2008, www.TestingGeek.com