Liquiddark, how does the new process prevent "bug fixes" that don't really fix the bug? and/or prevent fixing things that aren't really bugs?
...
You're right, that was mostly chaff; I'm disillusioned with the company I currently work for and it negatively influences my views on process. I do think the developers need to be involved with the end-users; even here we have sit-down meetings with the grunts that use the systems we build, otherwise you have the "telephone" game effect.
If QA is checking high-level user requirements, why do they need to wait for a finished product from the development team? Are they checking that the software team actually built what they were told to (this is the mickey mouse testing that our QA department does) or checking that the system engineering work (that produced the requirements given to software) meets user needs (which can/should be done before given them to software)?
I think I've work on projects like yours, every week or two you release the software an bump the version and at that point in time all previous version become obsolete? If there's a problem, the first recourse is to update to the latest and greatest. (Surf mentality). Big companies don't seem work like that (drop-anchor mentality). New features mean contract mods and money needs to be secured to fund the development; they go to the next major version. If there's a problem you fix it in the old code and release a bug-fix version (aka patch level).
* My sister is a mechanical engineer and she calls things 'mickey mouse' for what we typically use more vulgar terms; the quality department doesn't sufficently verify the functionality, they just do cursory demonstrations. It's almost insulting really, as someone above mentioned if it doesn't work at all why it leaving software?
[Edited by - Magmai Kai Holmlor on October 4, 2004 1:43:20 PM]
Process from the trenches
Author
AP:
That sounds pretty much exactly like our system, except that the practical consequence is that upper management is continually trying to push for more severe bugs to be allowed in a release. I'm not even kidding, this is what a lot of companies do in my experience, but it has been refined to almost an art form here.
We're very capital-A Agile in this regard - we rely on developer courage and responsibility. Problem being, of course, that this is pretty much the only agile process tool in use right now, and it's one of the worst to have in isolation.
I understand, sir. As I've tried to make clear above, our process is pretty much pathological.
The more the better. In my line of work, sadly, what usually happens is that there are a bunch of "stakeholder meetings" wherein the actual stakeholders - that is, the users of our product at the client corporation - aren't usually present.
They're doing both, hopefully. This is the multi-mindset - the product should meet the specification, the specification should meet the requirements, and the requirements should make sense from a user PoV. In the trenches, the list gets prioritized, and consequently the third part almost never gets mentioned. However, a few developers who actually care about the product and/or hate admitting that bugs are actually bugs can go a long way in provoking discussions of this topic in the course of fulfilling the other two goals.
You've pretty much hit the nail on the head. We play by both sets of rules, except that we're perfectly willing to mod any version of the system for some ready cash. We might even make money on the work. Maybe.
Let me take this from the PoV of our QA department, since our development effort is self-contained and far enough from management to be able to see their external problems better than their internal ones. Basically, QA here does exactly what you just mentioned. We have an automated testing kit capable of exercising our entire application, but the testers aren't allowed to develop tests with it because that is viewed as intrusive to the primary goal, testing the application. Every version has thousands of regression tests that must be run, so QA has to decide what to test first, and they always start with functional "smoke tests" - forms open, user and admin-level tasks work, data can be sent in and out. Clearly, this should be automated to the largest extent possible, but it isn't because they're not allowed to do so.
Meanwhile, our programming process suffers from some classic big-design-up-front flaws - vague specifications (beautiful oxymoron, that), even vaguer requirements, zero user feedback to the development office, etc. Our IT guy likes to say we're all mushrooms - kept in the dark and fed bullshit to keep us warm and happy.
So we continue to produce bugs, QA continues to find them, they post anything that they really really want fixed as a high-priority bug and then leave anything else to wallow in the hell that is low priority defect existence.
Does that sound familiar? I don't blame QA, although certainly a little more courage on the matter wouldn't hurt. Management decisions are the killer, and they're also the reason why Agile development is such a powerful paradigm, because Agile cuts management's heart out and leaves them pulling rather thinner puppet strings, whereupon they can barely fuck things up at all.
That's process in the trenches, from my perspective. I work to improve our situation, and nothing sticks. Everyone here would love to see a positive outlook for an upturn, but there are external forces at work, and internal resources haven't revolted sufficiently to make the changes that need to be made.
That sounds pretty much exactly like our system, except that the practical consequence is that upper management is continually trying to push for more severe bugs to be allowed in a release. I'm not even kidding, this is what a lot of companies do in my experience, but it has been refined to almost an art form here.
Quote:Original post by Magmai Kai Holmlor
Liquiddark, how does the new process prevent "bug fixes" that don't really fix the bug? and/or prevent fixing things that aren't really bugs?
We're very capital-A Agile in this regard - we rely on developer courage and responsibility. Problem being, of course, that this is pretty much the only agile process tool in use right now, and it's one of the worst to have in isolation.
Quote:You're right, that was mostly chaff; I'm disillusioned with the company I currently work for and it negatively influences my views on process.
I understand, sir. As I've tried to make clear above, our process is pretty much pathological.
Quote:I do think the developers need to be involved with the end-users; even here we have sit-down meetings with the grunts that use the systems we build, otherwise you have the "telephone" game effect.
The more the better. In my line of work, sadly, what usually happens is that there are a bunch of "stakeholder meetings" wherein the actual stakeholders - that is, the users of our product at the client corporation - aren't usually present.
Quote:If QA is checking high-level user requirements, why do they need to wait for a finished product from the development team? Are they checking that the software team actually built what they were told to (this is the mickey mouse testing that our QA department does) or checking that the system engineering work (that produced the requirements given to software) meets user needs (which can/should be done before given them to software)?
They're doing both, hopefully. This is the multi-mindset - the product should meet the specification, the specification should meet the requirements, and the requirements should make sense from a user PoV. In the trenches, the list gets prioritized, and consequently the third part almost never gets mentioned. However, a few developers who actually care about the product and/or hate admitting that bugs are actually bugs can go a long way in provoking discussions of this topic in the course of fulfilling the other two goals.
Quote:(Surf mentality)...(drop-anchor mentality).
You've pretty much hit the nail on the head. We play by both sets of rules, except that we're perfectly willing to mod any version of the system for some ready cash. We might even make money on the work. Maybe.
Quote:the quality department doesn't sufficently verify the functionality, they just do cursory demonstrations. It's almost insulting really, as someone above mentioned if it doesn't work at all why it leaving software?
Let me take this from the PoV of our QA department, since our development effort is self-contained and far enough from management to be able to see their external problems better than their internal ones. Basically, QA here does exactly what you just mentioned. We have an automated testing kit capable of exercising our entire application, but the testers aren't allowed to develop tests with it because that is viewed as intrusive to the primary goal, testing the application. Every version has thousands of regression tests that must be run, so QA has to decide what to test first, and they always start with functional "smoke tests" - forms open, user and admin-level tasks work, data can be sent in and out. Clearly, this should be automated to the largest extent possible, but it isn't because they're not allowed to do so.
Meanwhile, our programming process suffers from some classic big-design-up-front flaws - vague specifications (beautiful oxymoron, that), even vaguer requirements, zero user feedback to the development office, etc. Our IT guy likes to say we're all mushrooms - kept in the dark and fed bullshit to keep us warm and happy.
So we continue to produce bugs, QA continues to find them, they post anything that they really really want fixed as a high-priority bug and then leave anything else to wallow in the hell that is low priority defect existence.
Does that sound familiar? I don't blame QA, although certainly a little more courage on the matter wouldn't hurt. Management decisions are the killer, and they're also the reason why Agile development is such a powerful paradigm, because Agile cuts management's heart out and leaves them pulling rather thinner puppet strings, whereupon they can barely fuck things up at all.
That's process in the trenches, from my perspective. I work to improve our situation, and nothing sticks. Everyone here would love to see a positive outlook for an upturn, but there are external forces at work, and internal resources haven't revolted sufficiently to make the changes that need to be made.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
