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.
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