Are testing guys considered low profilers?

Question

I happened to know some system admin and according to him - testing guys are not given preferences in an organization in comparison to developers. No doubt software releases are not possible without testers but I've never laid my hands on testing so not much aware of it . No offense intended.

Answer 1

In my experience, unfortunately, they are often treated like second class employees and even worse a frivolous perk for programmers.

It stems from a number of things:

1. When the testers are doing their jobs correctly, it is easy for everyone but the programmers to forget they even exist. Much like a network admin, you only notice them when they are not doing their jobs, or doing them badly. So from the perspective of the rest of the organization, they are remembered only for their mistakes.

2. It is mistakenly seen as an entry-level job for people who aspire to be programmers, but aren't qualified yet for those jobs. In fact, at one company I worked they were given Jr. Programmer job titles despite their pleas to get a Q&A job title. Even the fact that they were in a QA department wasn't enough to get HR to budge on that.

3. Because of #2, it is assumed that testers are all entry-level folks, and should be paid accordingly.

4. Nobody likes to be criticized, and it is all too common for defensive programmers to dislike testers because their jobs require them to point out programmer mistakes all day. As a manager, I was constantly on a PR mission to remind programmers that the QA team was there to make them look good, not narc them out.

5. It tends to be a job people get into by accident and not choice, at least initially. I don't remember any degree plan at any of the schools I attended that prepared people for software Q&A. They do exist, but usually at the lower-end vocational schools, which only contributes to the idea that they are less skilled professionals.

6. Testing jobs are much more likely than programming jobs to be sent offshore. At least the programmers can argue that it is more efficient to communicate design needs locally and that it is valuable to keep the knowledge of how the company's flagship app works inside the company. Testing, however, is much easier to modularize and thus easier to outsource.

7. For all of the reasons above, testers tend to see the writing on the wall and move into other jobs (like programming), especially the really good ones. This means that most testing jobs tend to get staffed with more entry level people who haven't burned out on it yet or moved on to other things, which unfortunately reinforces several of the above ideas.

Answer 2

It depends on the company, but usually. They're often seen as second class citizens, and in many companies, testing is seen as an entry-level position from which you would then move on to becoming a real developer.

This is, of course, crap. Having worked with some good testers, I can say that they are both valuable and hard to come by. Someone with a mind that is creative enough to find non-obvious bugs and methodical enough to do a thorough job.

One exception, though: I've known a few Microsoft test guys, and I hear that testers there are first-class citizens.

Answer 3

I've worked as a functional tester for a year on a fairly large project. Each team of about 10 members had 2-3 were testers. I must say that we were treated as equally important to the project as the developers.

Finding bugs is not easy. First, the testers have to understand what the code is suppose to do. That means reading and understanding the requirements. Key here is understanding the requirements - if the testers can't understand the requirements well enough to know how to to write positive test cases, you should be worried. This means that the developers have written some code that does what they've assumed it to do. Is this assumption the right one? You don't know until you've sorted out the requirements, and you can thank your testers for finding that flaw.

Second, the testers have to write false test cases, which ensures that the code does not what it's not supposed to do. A reasonable rule of thumb is that you write 5-10 false test cases for every positive test case. This means understanding the requirements even further, and often this information is, or was at least in our project, confusing and ambiguous. (And it wasn't because of low effort on gathering requirements - we had something like 13,000 in our team alone.) Again, the developers will have written their code using their assumptions, or even worse, not even considered this at all. So what does the code do under these conditions which are not normal? You don't know until you've tested it. Maybe the program doesn't respond; maybe it just crashes; maybe it destroys data; maybe it allows the user to run commands as root user. Whatever it does, you want to know. Otherwise you may find yourself reading the following headline in the newspaper one day - BUG IN [YOUR COMPANY NAME]'S FLAGSHIP PROGRAM LEAKS CLIENTS' CREDIT CARD NUMBERS. You can thank your testers if this doesn't happen.

So treat your testers good. Treat them well. After all, they are the ones who root out the bugs in your software and make your, and our, life easier.

Answer 4

Good testers who can analyse problems efficiently and can do decent test automation are worth their weight in gold as there are so many cowboy testers out there (when interviewing one "tester" once he actually burst out laughing as he realised that we knew he was making stuff up on the spot whilst being quizzed on his CV).

In my team the tester is treated as an equal - which includes responsibility and salary. If you want a tester that clicks next all day - outsource them to somewhere cheap (we also do that).

Answer 5

some things that i have observed:

engineering graduates hate getting allocated to testing units (of large software vendor firms) , since they consider it a a non-technical work environment, they are given excel sheets with instructions like 'click all the links in the webpage and verify', are forced to work with graduates from non-technical streams(science, arts) which they consider as a humiliation and feels like their tech skills are not utilized. But these allocations are purely based on organization's requirements. so if you are a job seeker aiming at such a big software company, beware, your career at such a firm is decided almost single sided by the firm. You cannot do much, practically, except getting out of the company at the right time.

unless there is opportunities to learn automated testing etc, the career is stagnant to an extent in testing. But i have heard from more experienced folk that good profiles in specialization in testing gets high compensation, and personally i know the opportunities for onsite assignments (simply put, in the offshore model, it fetches more money for you as compensation) are more for testing unit in my organization than any other unit. They work with all industry verticals as a filler or glue, and testing is inevitable.

so if you are sure you can drive your career the way you want, testing is nothing low-profile. But the general public, its a pain to convince them. and why do you have to?

Answer 6

Yes. Like it or leave it they are equally important but are always less preferred. May be because they are easy to replace.

Answer 7

I know companies where the QA team is responsible for releases. This means that they have the power to block a release due to lack of quality. If an issue is reported in the field, they are the first in the line of fire (well right after the field engineer).

Typically they have higher domain knowledge. They tend to know the overall functionality of the product better while developers concentrate on their module/features.

Also I know of QA orgs where they have to write their own test tools. Not to mention automating the whole stuff. I am a developer, and have always valued QA guys who test my features.

At least in my organization, QA are treated equally with developers. I think it is because of the domain (telecom) where protocol and network architecture knowledge is equally valued with programming skills.