Home > Archive > Software Testing > October 2005 > How to run a QA department
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to run a QA department
|
|
|
| I am looking for suggestions on how to implement some policies and
procedures for a newly formed QA department in a fast growing software
development company. Today there are non existent. Any book, forms or
structure recommendations would be greatly appreciated.
| |
|
| QA wrote:
>I am looking for suggestions on how to implement some policies and
> procedures for a newly formed QA department in a fast growing software
> development company. Today there are non existent. Any book, forms or
> structure recommendations would be greatly appreciated.
Start with these principles:
- the developers, not the testers, should write most tests
- all tests should be automated. If you can't automate,
ask "why" five times
- the testers should collaborate with those who request
features to write acceptance tests. Developers
implement code to pass those tests
- the time between specifying a feature and letting
end users profit from it should be as short as possible
Those techniques avoid the mentality "just throw it over the wall when you
finish and QA will test it" that troubles so much of software engineering.
--
Phlip
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| gregmg@my-deja.com 2005-10-16, 7:00 pm |
| Are you really forming a "QA" department, or do you mean "Test"?
I suspect the latter.
The role of QA is to assure compliance with quality processes
throughout the development effort. One standard definition
describes quality assurance as:
"A planned and systematic set of activities to ensure that
variances in processes are clearly identified, assessed
and resolved. Improving defined processes for fulfilling
the requirements of customers and product makers."
People use QA (or QC) when the really mean test, in its various
forms. This is one of my pet peeves. For information concerning
setting up a test group, please check out my web site.
Greg G.
http://www.testengineering.info
| |
| Shrinik 2005-10-18, 7:58 am |
| Philip,
I whole heartedly support and appreciate last two points which seem to
have been influenced from "Agile development" school of thought.
However, I don't quite agree with first two.
1. If Developers were to write most of the tests (I suppose you meant -
in the lines of test driven development using xUNIT tools - written in
the same language as the application code) - then why do we need
testers - to do acceptance testing? For that we have users any or some
alpha or beta testers. Testers in independent functional Role are more
active and contribute to test the application form both compliance
(product doing what is requirement specs claim) and Robustness (product
crashing on intended or unintended abuse - not documented use of
product).
2. Are you suggesting 100% automation? By automating all tests (All I
mean including others including Non Unit test cases) - you are reducing
the entire activity of testing to mere test automation. Automation is
dumb - does only what it was programmed to do. There is no replacement
to Human intelligence and intuition. If you have not already read, I
suggest you read following articles to understand dangers of the notion
- 100% automation.
1. Test automation snake oil - James Bach -
http://www.satisfice.com/articles/t...n_snake_oil.pdf
2. Seven Steps to Test automation Success - Bret Pettichord
http://www.io.com/%7Ewazmo/papers/seven_steps.html
Finally, as was pointed out in the thread - main question - Are we
talking about a QA department or Test department? This more or less now
clear to most of the Software Engg community that - these two are
different things.
To give my version of difference --
QA - Does not touch the product being developed (touch - as in testing
the product). QA merely observes the process that is used for create
(possibly test) the product. QA persons do not get their hand dirty....
Test - Live with the product, touch it, use it, abuse it, and attempt
to break it - with an objective to extract information about how it
works and how it fails. See focus here the product not the process.
However while doing testing, testers do (need to) adhere to some set of
procedures (documented or otherwise) broadly referred as "Test
process".
Note: In some bigger organizations (IT services) - Test process
improvements are driven by QA dept with inputs from Test department.
Shrini Kulkarni
http://shrinik.blogspot.com
| |
|
| Thanks for the information. I am learning already. It would be a Test
department.
| |
| alexfdietz@yahoo.com 2005-10-25, 3:59 am |
| If you're totally new do the following.
1. Buy or borrow:
"Systematic Software Testing" by Rick Craig
"Managing the Test Process" by Rex Black
2. Attend StarWest next month.
3. Read this newsgroup
|
|
|
|
|