General discussion

Locked

No QA, from programmer?s test to production, is this a trend?

By bdmore ·
In the company I work for software changes typically goes from the developers to production with minimal or no third party check. The worst part is that sometime software bugs are detected by the client or by the client?s client, and then all **** brake lose. When this happens, guess who is held accountable, the programmer who make the change. I?ve been very vocal about the need to have a proper QA but so far they hear but don?t listen. Occasionally, the users perform some kind of minimalist testing but there is not a formal sign off to it.

I?ve been in IT for almost all of my adult life and never seen this before. Is this is a trend? If so, I will not only be changing job but also career. If there is a new wave of programmers that can develop and QA their own code all the way to bug free status I?m definitely not one of them. So far I haven?t met one.

This conversation is currently closed to new comments.

6 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

this has always been a problem but it is getting worse

by j.lupo In reply to No QA, from programmer?s ...

because of downsizing and other issues. Documentation and QA are some of the quickest cost cutting measures by companies. They don't see the need and think that programmers that follow a PM methodology should unit test the software sufficiently. They forget that development is too close to the changes or development to test effectively.

QA does not mean what it used to and may never again thanks to the changing economy of IT.

Collapse -

Sad to say, it's true

First of all, IT gets nearly zero support (http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=2028551&id=292643. Second of all, release cycles get shorter and shorter (http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=2026209&id=292643.

In my last review (my first annual review with my current employer), one of the "dings" I received was regarding the fact that sometimes code or output gets to a customer with a bug in it. I have tried explaining a number of times that there is absolutely no way that I can catch every possible bug; I am just too close to the development. In the back of my head, I subconciously know, "don't click there!" and "don't try that input!"

Another problem that I frequently experience in testing, is that the only way to check to see if the results are correct (I do a lot of report programming) is to essentially rewrite my entire program, and see if I get identical numbers. There is no one else in my company with the experience or skill to review my code (I handle the tough projects or the long projects, as I am the only true developer there). As a result, the best I can hope for is for someone else to try generating the same results using their own code and see if it matches mine.

This is not just my current employer, either. At my previous employer, as a consumer of our IT department, I saw way too many things being sent to end users in a less than QA'ed state. When we were told that a new version was being deployed, we would also get an email with what features did not work quite right. I was raised with a different idea of "quality" than that, but this seems to be considered acceptable, especially on internal-use projects.

In fact, only once in my programming career have I had a QA team! Sadly, when cutbacks happened, they suffered first. But nonetheless, they were there.

I also see about 50 times more job ads for programmers as I see for QA people. This worries me as well. I would have to say that either QA people never leave their job, get hit by buses, and can handle any amount of work thrown at them... or companies are not hiring QA folks.

Business reality hurts.

J.Ja

Collapse -

Its always been like that in America

by propellerheadus In reply to Sad to say, it's true

One of the shortcomings about American business computing is that the concept of "Software Engineering" hasn't caught on in the vast majority of business (maybe some of the really large players do, but most don't).

Business leaders (read Dilbert's Manager) think that software is an art form, and not a science. They do not think in terms of iteratively reducing the percentage of errors in lines of code in a package. They think in terms of getting some junk out there so they can get paid.

Sad but true. This has been the case for as long as I have been in the field (since PC'S were being built in hobbiest basements, and dual floppy drives were all the rage for storage).

Kent

Collapse -

More of the same

by donsw In reply to Its always been like that ...

We have very few qa. Mostly when someone says the qa word we look around as if "Whats that word" out motto has become our customers are our best qa. Upper management will talk about qa but they will not do anything about it. Its the same as the others have already said.

Collapse -

I don't think so

by xitx In reply to More of the same

That's methodological issue. Even though the programmers focus on coding and fixing bugs,there should be enough integration tests to cover all the typical scenarios the clients are going to use. Do only QAs do the integration tests? Should the team have infrastructure to automate the integration tests and units tests?

Even though I myself am a developer, I always follow the extreme programming. One implementation one test. Every new implementation should not break old functionalities.

Dennis

Collapse -

There are no absolutes

by SaintGeorge In reply to No QA, from programmer?s ...

It all boils down to a cost/benefit equation, and Public Relations/Human Resources politics.

1. Cost/benefit
It is Management's job to ponder: How much does it cost to perform QA after programmers deliver? Also, how thorough should QA be? Meaning how deep, how long, how many people and resources involved?
Against this: How much revenue does the company actually lose from disgruntled clients?

2. PR
Enter the Public Relations people. PR main functions are to publicize products and services, and to take the heat off the company (and Management) when said products and services fail - as they are bound to do when QA is poor or inexistent.
Unless we are talking monopoly - in which case client opinion won't be worth a peace treaty in the Middle East - PR will take pulse and temperature of client reaction and pass it on to Management. The Powers That Be can then react and say ok, we chose this path, or unleash their wrath upon lesser beings.

3.HR
Enter HR politics and mores. I'm not talking here strictly about the Human Resources Dept people, who are no more than dummies in the way between Employees and Management (kind of an internal PR, trying to sell Management BS and at the same time avoid upper echelons disembowelment at the hands of the company's little people).
Actually, I'm talking about the interaction between bosses and bossed, dictated mostly by both their personalities and the country's Unions strength.
Employee (programmer in this case) incinerating will be an option for the weak minded manager who is actually responsible for the lack of QA.
The fact is, when **** hits the fan, it will spread around, but most of it will go downwards. Gravity, you know.

If this is your case, it's just the reality dealt to you by Chance, Fate, Karma, you name it. What to do?
* Kill your boss, take his place and order proper QAs. Not recommended. Even if CSI didn't catch up with you, you'll probably go to all that trouble just to look up and find another boss-of-you who won't sign for the money you'll need to QA properly (there, I just coined a verb)
* Talk your boss into it. Improbable. If he is not a moron, his decision will have solid foundations and you won't be able to shake them. And if he is a moron, he won't listen to reason. A reasonable moron is an oxymoron...
* If you have a strong character, or a strong Union, or both, stop your boss in his track reminding him it was not your decission or responsiblity.
* Try another company. You probably will, anyway, if you try the one above. If you are lucky, you might find the odd company who really cares about customer and programmer happiness.
* As you said, abandon all hope and choose another, more rewarding, career. Avoid dope dealing, though. Trying the stuff before delivering is frowned upon.

Good luck.

Back to IT Employment Forum
6 total posts (Page 1 of 1)  

Related Discussions

Related Forums