Are testers considered low profile? [closed]

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

Update after reading other answers: There are a lot of QA professionals who love the job they do. Just to give another perspective if you haven't come across any respected QA positions, one example here: Embedded apps/ mobile apps testing for leading automakers. They make sure the business requirements are completely met before a vehicle is released to the market and no user experience a slow or unresponsive car dashboard. They work closely with managers and higher level management, and also the developers starting from planning the QA process to live hands-on testing on simulators in the design facility. I can't think of them being low profile, they handle huge responsibilities and ownership and they are among the best engineers.

now my earlier answer, the flip side:

I have observed that engineering graduates hate getting allocated to testing units (context:India, large software services firms where everything is driven by 'business requirements') , 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. These allocations are purely based on organization's requirements, and a fresher, most of the time, does not have the power to negotiate his career path. So if you are a job seeker aiming at such a big IT company, you have been warned. You cannot do much, practically, except getting out of the company at the right time.

Unless there are opportunities to learn automated testing , load/performance testing etc, the career is stagnant to an extent.Personally I know the opportunities for onsite assignments (=loads of money from an offshore programmer point of view) are more for testing unit in my organization than any other unit. They work with all industry verticals as a filler or glue, as testing is inevitable in projects in all domains.

If you are confident you can drive your career the way you want, testing is nothing low-profile. With 4-5 years of experience and a bit of luck you can get a very good exposure, sometimes interacting with the top-level business users. You also can have a good grasp of the industry/domain you are working in (compared to a developer who would mostly focus on some piece of the system). At this point one can choose to switch to a business analyst kindof role too.

Answer 6

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.

Answer 7

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