Lessons Learned From Being in the Shoes of QA
At work we have a huge product release coming up very soon. There are a lot of new features to the application, which means that there has been a ton of changes to the code, which has meant a lot of hours for testing. As a result, I’ve been having to help test–in volumes I don’t think I have yet in my software development career. I’ve had to run the application through a variety of test scenarios as well as going back to bugs and verifying that they, in fact, have been fixed. In the last week or so, that’s where 90% of my time has been spent. While I’m a little sad about not being able to code nearly as much as I’d like to at work, I’m glad for the lessons I’ve been able to learn in my very brief stint as a QA personnel/software tester. One thing I’ve been realizing is just how incredibly expensive writing buggy code is.
Having to devote so much of my time towards verifying bugs that have been fixed has given me a rather fresh awareness of just how expensive writing buggy code is. If a developer (say, Developer X) writes code that isn’t quite right (or extremely wrong) in the first place and commits his/her code, well what happens? Since QAs do not tend to test code that have been committed right away this means that once the code has been committed, chances are pretty decent that the at least 1 other developer on the team (say, Developer Y) will start making use of the code that Developer X has committed.
Fast forward a few weeks and now it’s time for some testing by the QA (Tester A). Tester A finds some issues with Developer X’s code and files a new bug (expense). And the expense comes from more than simply identifying the bug. You see, often times it’s much easier & faster to see that something works than to see that something doesn’t work. Unless Developer X is just a horrendous developer and most of the code he writes is buggy (in which case he should be doing something else…) QA will most likely give the developer some benefit of the doubt, which can amount to be an expensive “task”. I’ve been noticing this a lot in my own testing. When I come across buggy code, the first thing on my mind is not that there is something wrong with the code, but rather, that I must not be seeing something correctly. At this point, I will almost always re-perform my testing (expense) and my understanding is that this is true for other, more seasoned software testers as well. When a code a person is testing does not quite work right the first time around, that same piece of code may very well be tested at least 2 or 3 times before a bug is eventually filed. Again, expensive.
Okay, so after the bug is filed, Developer X then has to go back to the code that he wrote a few weeks ago and try to remember what he did (expense). There is also the hidden expense of disruption to his flow of work. And of course, unless the code that was written was super simple, it’s going to take some time to recollect why the code was changed. Thanks to source control, seeing what changed is a simple task. Trying to figure out and/or remember why something changed can be a pretty tricky task. The Developer X thinks, thinks, and thinks (expense) and looks through not only his code but code that others have written which may very well have changed since the time he originally wrote his code (expense). After some time, the developer figures out what’s wrong and fixes up the code. Developer X commits his code. Updates the bug that was filed in the bug tracking system (expense)–a process which often takes more time than one would like. It tends to take a lot of time because trying to write something that is both concise & informative can be a tricky thing. You don’t ever want to write (or read) an essay in the bug tracking system.
Once the code has been committed and Tester A has been notified, he may need to drop everything that he was working on in order to test this code, which means disruption to his flow of work (expense). Re-testing code can be a very disruptive thing. Once Tester A tests the code and verifies that it is working (hopefully) Tester A has to go back to the bug he filed into the bug system and make updates to the bug ticket (expense). And once this takes place, there will have to be, at some point in the future, yet another test to verify that the bug has been fixed (expense). While this last step isn’t completely necessary, I think it’s much too risky to leave this step out.
Obviously, if upon re-testing the code Tester A sees that either the bug hasn’t been fixed or worse yet, more bugs have been created as a result of fixing the original bug, well… that just means more and more expense. And honestly, having to re-re-test code sucks. BIG time.
At any rate, let’s say that Tester A finds that the code has been fixed and things are working correctly. Not all may be done at this point, however. Remember Developer Y? The developer who made use of Developer X’s buggy code? Developer X’s buggy code may mean that Developer Y has to go back to the code he wrote (expense). Bug(s) may be filed against code that Developer Y wrote to no fault of his own (expense). Developer Y may get really frustrated at Developer X (expense). And if this kind of thing becomes a pattern, this will mean more & more expense for the entire team since other developers are going to become growingly weary of any code that Developer X writes, no matter how simple it is.
So, to sum it up: As developers, it is critical that we write code that works the very first time around. Code that works results in efficiency, happy developers, happy testers, happy managers, and less money wasted. Writing buggy code results in slow-downs, demoralized developers, cranky testers, angry managers, and a lot of money wasted.
wow this was kind of interesting insight into software development