How to organize a QA Process/Department?
I am in a 10 man team, and I am the only QA in the team. I am new to the team and I have already put a QA process in place.
My process is this:
- Development (will wait till the development phase is done)
- QA will do the testing
- QA will create test cases off of the developer's story and what I see on the existing app(yes, the team does not have any documentation at all, including requirements)
- QA will then execute test cases
- QA will assign bugs to developers; developers reassign bugs for a retest to QA
- QA will certify an app
- QA will report the summary to the Project manager and developer, giving the 'go' sign for production deployment
Then repeat the process to the next project.
I know, for a fact, that I still lack something in the process. Since documentation is not there, which is the business documents/process documents, is it practical for me to create these documents first before creating all these test cases? We don't have a business analyst/writer. Is there anything I could improve on the process? Feel free to comment on my existing process.
There are some major red flags here.
You're only going to any testing after development is completely done? If this is development of a single feature, that's fine. If this is for an entire sprint worth of data, that's dangerous. You do not want to wait two weeks before sending a bug report to a developer. When I was developing I could barely remember what I worked on a day or two ago, much less weeks ago.
The process of assigning bugs to developers doesn't seem like it should be QA's responsibility. Rather, you should send bug reports to development and let them decide who is going to work on a certain bug. That's for the development manager to decide, not QA.
You don't make any mention of any formalized testing to be done by the development team. Are they going to be crafting unit tests around bugs you send back? The most common place for a bug to crop up is where one has already cropped up before, so get your developers to create unit tests. Ideally they're creating unit tests as they develop (or even before) but we know the world isn't ideal.