Skip to main content

QA

QA, you gotta love them.  The have the job of finding issues with the code that engineers write.  This should be a very good thing, but there are times where developers view QA as something akin to goblins that live in a haunted forest and should be avoided.  This view is totally without merit.

This may be related to thinking that it's a Development -vs- QA world with and "end sum" view where for every winner there must be a loser.  This thinking is very harmful as developers and QA have the same goal, to deliver great software.

Staff that works in QA is the last line of defense between what we code (and test?) before the end user (expecting a fault free experience) uses it.   QA's only fault is that they point out our faults, that deep down we already know we have.  Developers could preview if we did our own QA screening, but our minds and ego prevent us from doing so.   We like to think that when we finish code, it's finished, done, ready, complete, but it's really not finished. We are finished when QA is finished with it and we should do what ever we can to help QA finish it.  One way is to do some QA our selfs (not just our unit and integration tests) but user, installation, messing up tests.

We could:
  • Just perform all (related and non-related) feature operations at the completion of coding.   "But my changes should not have effected that!"
  • Have other developers (that don't know the feature) try all of the feature operations.  "No, it does not work that way!"
  • Pretend to be a toddler and just type and click away.  "No one would ever do that, it only expects numbers!"  
These basic steps could avoid so many bugs and time.  If developers performed steps like this then the bug/fix cycle would shorten to minutes instead of going through QA and another build / verify cycle and QA could focus on more complex threading, data, integration issues and help deliver a more robust product.

Just a side note:  Take time to walk over to QA, to talk to QA and encourage them to ask for questions.  They learn how to better test the product and you gain an understanding how end users may visualize and operate the product.   

One habit I've picked up is when ever anybody comes to my desk I use the phrase: "Hi , how can I help you?".   This places the person at ease and places the discussions on open basis.  Give it a try.

Next Post: Agile!



Comments

Post a Comment

Popular posts from this blog

My Current Desktop and Happy Vining.

It's been a big switch when I quit my old procession (Software Engineer) and ventured into the unknown.  So this is my current desktop.   First it's a REAL desktop and not a computer screen. Second, I've had to learn a whole new set of tools.  You would think a pencil is just a pencil and a paint brush is just a paint brush, but noooooo, they are tools into you mind and that's what needs re-tooling. The tactual nature of these tools and operation as much more rewarding (and frustrating too) than typing code in an IDE.   That had it's incentive but that well went dry and life changes,  so I changed. The pleasure of creating colors (no RGB involved) ad hoc wise is interesting.  Getting the technique to merge them on paper is very tough.  You do not know what you're going to get, so you just have to go with it. I'm glad that I can do a lot of other things instead of Software, but I hope that others in my past procession work on other pa...
Post a Comment
Read more

3rd Try is a Charm

I've been trying to draw / paint these barns for a couple of years but never felt or got them right.  This time I think they turned out right. So What went wrong before and what's right now with this drawing?  This time, the light was right.  It's coming from the upper right and the shadows just looked right.  The other thing is the corn field on the left had to "be in season", otherwise it's just a plowed field.  I had taken other photos from different angles but they never felt right.  This angle has the road, power lines, corn field, etc. all leading to the right.  The shadows on the lower right helps fill in that corner (don't forget about the corners!).  The last part is trying to draw (ink paint maybe) the trees in the background.  Not so easy when they are kind of a blob is green shades. So yeah, it's composition that is king.  Many times I just don't see it until the drawing / painting is finished and when it's right it feels goo...
Post a Comment
Read more

Thought Patterns

I know how I work.  How a think about, visualize a problem and go about mentally design a solution and implement it in code.  My thought pattern works pretty well for me on most occasions, but not always. There are times when I have a force myself to change my thought pattern because of the problem I'm solving requires a different mindset.  Anyway, this posting is about how I work most of the time.  Here is goes. I quickly break down a feature into operations that are required to exists and tackle that code first.  My thinking is that, if I can solve the primary issues first, then secondary features will fall into "known knowns" and I can address those at anytime (and sometimes at my leisure) and this allows me to meet my internal timeline. If I addressed features and operations that are not primary first, then I feel I risk my (and the projects) timeline without addressing issues that allow the feature to operate.  You may have seen this occur where...
Post a Comment
Read more