There are two huge hurdles that most organizations must overcome if they want to produce a quality product. These two hurdles are going to sound so idiotically simple, that you may stop reading, but please bare with me, as I explain. One hurdle is time, the second is terminology. I know those sound kind of silly but hear me out.
Time
We all know that there are deadlines that must be met. Sometimes we absolutely positively MUST get a deliverable out the door. The thing is, this does not happen in a vacuum. Working more hours, eating into testing time, sacrificing writing unit tests, throwing in hacks that will be "fixed later" all ends up sacrificing code quality.
I'm sure as developers we've all at least heard of the mythical man month. The idea that throwing more developers at a project actually makes the project last longer. Yet this same phenomenon seems to be completely ignored when it comes time to complete Quality or User Testing! You cannot compress testing time and throw more testers at a problem and expect a quality result! It doesn't work that way! Have you ever seen a large group of testers testing functionality? It's a logistical fucking nightmare to begin with. Duplicate bugs are regularly reported leading to multiple developers trying to fix the same code from multiple different spots, which either leads to wasted time and duplicate effort and frustrations by both developers and testers!
Yet it seems in many places when a testers say we need two weeks to test some critical part of the system, it's viewed as a nice to have. This is simply not the case! Good testers understand that what they are doing is making sure that user doesn't have a "what the fuck" moment. Ultimately I hope you realize what a user with too many "what the fuck" moments can also be a called an "ex-user".
Terminology
This brings me to my next point which is terminology. I purposely used the word "tester" in my previous section, but you know what, that's the wrong word. In Software Engineering we are so fortunate to have a vocabulary that allows us to express abstract concepts to quickly convey meaning. Language, Object Oriented, Classes, Methods, Interfaces, Factories, Constructors, Compiler, Scripts all great words, and for the most part universal for developers. These words are important in their own ways, and yet it seems for some reason when it comes to code quality and testing we don't have quite the same vocabulary.
I absolutely abhor the word "Tester" to describe what these individuals do. Oh sure, they run tests, but that just makes it sound like something a monkey could do, and quite frankly that's just very, very wrong. Likewise I dislike the term Quality Assurance as that term seems to express the idea that quality is something that should be bolted on to the end of a project. Which in turn leads to the perception that you are "testing" the deliverable. This too is wrong.
Quality should be the focus throughout the process. Quality of the code written. Quality of the design and architecture. Quality of the final deliverable. This is not an process that can happen at the end, but a process that should happen THROUGHOUT the cycle! So since this is something that should happen throughout the process, the job description and name should change. I personally like the term that my friend and boss Pat Richards uses: Quality Engineering. After all that is what this process is aiming to do!
Most importantly though, by changing the name to Quality Engineering you change what it is you are actually trying to accomplish. You are engineering quality right into the process. It makes much more sense to have someone who is called a Quality Engineer being a part of the initial design and estimation sessions, and that is a huge part of why Terminology is so important!
Changing what you call something can totally revamp the way you look at its function. Equally important is making sure that everyone uses the SAME terminology. I have had a developer say to me "I am in the process of unit testing my code." That to me meant they were writing automated unit tests, since that's the terminology I use. What they meant was that they were doing developer testing on the module they had just wrote. They weren't wrong with how they phrased it, but because we weren't on the same page with terminology, I made some very wrong assumptions on the code base.
The same problems can arise on the transition from Development to Testing cycles. This too is why it is so important that Quality Engineers be involved in the whole process from beginning to end. By being embedded with the team that is developing a module, they come to use the same common terminology as the team, thereby decreasing communication problems and increasing understanding and thereby productivity. After all not having to circle back to make sure you think you understand whats going on is a huge time saver.
So bottom line is if you want to make sure you are delivering quality products, you have to be sure that you have a process in place that supports it. Robbing Peter to pay Paul by giving developers more time to write code and sacrificing final testing time is a quick way to failure. Likewise treating testing like it is something that CAN be sliced and sacrificed is a quick way to doom you deliverable to failure (or at least poor results). Never underestimate the importance of your choice in wording, and naming. Names have power that create preconceived notions in others. If you want to ensure quality, make sure the terminology that you use empowers that agenda. In addition make sure everyone is on the same page and speaking the same language. Anything short of that is a quick road to a bad result.
No comments:
Post a Comment