The new hotness in software development is Kanban. Kanban's like an assembly line. As soon as one person's done working on a thing, they shove it along the conveyor belt to the next, like manufacturing a car.
But sometimes things bottle neck at one station or another. So when that happens, you take the people who have free time and put them on something else. They don't do as good a job as the worker dedicated to that station, but it's better than nothing. In the software engineering world, that means Business Analysts can do QA and development. QA does development and software analysis. Developers do QA and build business requirements.
This is a mistake.
At least for developers. Business Analysts could be taught to QA -- they know what the software is supposed to do. QA could build business requirements -- they just need to know how to to make documentation. But no one can do development. People spend their college careers learning software engineering (like I did). It's a special skill, like writing a novel. It's what I was trained to do. I was not trained to do QA. I was not trained in Marketing Information Systems. I am the guy who does the coding.
And like writing a novel, I cannot proofread my own work. I am too close to the material. Things will slip my grasp because I am too close to the material. We're talking about small things in the big picture. They'll elude my eyesight because I'm not looking for them. I wrote the thing -- I know it's doing what I think it should do. But what's I think it should do may not be what the QA or BA thinks. That's okay, that's why we have those positions. And even they won't always catch everything. Just like you may not have caught the double "to" in the last paragraph.
And just so we're clear, we're not talking about a developer finishing code and sending it down the line without ever seeing if it runs. A good developer should check against the requirements. But we're talking about testing that comes before the code is approved for production. We're talking quality control. And that's rooted in how it might break.
 |
| I know why this works, why it's stupid, and how to make it one line. |
In a perfect world, we'd get it right the first time. But this is not a perfect world. All writers make mistakes (and they usually find them after the book has been published). In the publishing industry, a writer does not edit his/her own stuff. That is what an editor is for. An editor will see the plot holes and inconsistencies that did not occur to the writer. They will find the missing word and the misplaced apostrophe. Same as in development. No developer can spot everything because, if we had, we would have removed them. It's not like we make mistakes on purpose or because of laziness or lack of knowledge.
Development is a high level task. You are trying to translate a human set of instructions into computer-speak. The complexity of this means not thinking so much about the simple things -- they get reduced to generalizations. Just like how when you write, you don't think about how certain words are spelled. But in QA, that complexity is removed. If the developer tries to do QA, the brain will stay in that complex mindset. You can't trick it into pretending you're seeing this set of steps for the first time. We will always fall into the habit of testing it to the code. We test how it works instead of how it should work.
And then there's the things like misunderstanding requirements, the lack of objectivity, deadlines rushes. We are not the normal guy. A QA tests like a "normal guy".
It's too hard to be a good developer and QA and business analyst all in one. That's why they are separate jobs. It's not just about skill, it's about having different mindsets. A good developer thinks "how do I make this work". A good QA thinks "how can I break this?"Labels: computers, development, software engineering, work
