I love your description of the different roles...right now I work for a small group of a large company...I am a fiarly new employee and up until now the test process has been almost exclusively QC and manual...I am starting to work with developers to implement some automated tests to free test personnel to do more exploratory testing...it's quite the adventure!
Test Engineering method is nothing but W-Model (Not waterfall). In W-Model verification and validation process go hand in hand. Reviews play a major role and helps in getting the concrete, strong and stable requirements, whcih will be base for strong future development process. Everyone knows the impact of fixing any defect at the later stage of the project life cycle and also the benefit of identifying the issues at the beginning of the project life cycle. Give more importance to Review and Analysis process, this will help in building strong Base. If the base is strong, anything can be built on that.I also tell my team members to spend qaulity time doing analysis of the work they do. Do not spend the entire day in just doing testing. Spending everyday sometime on Analysis will help them to move in the right direction in the work and also helps them to see in a bigger and broader perspective of the work.Finally, just spend good amount of time in planning, reviews and analysis, the execution will be done like in no time.Lest build and grow the Quality and Testing community stronger across the world.
Thanks for the clarification about QA, QC, and Test Engineering.Any suggestion for regression testing? That might be the reason to do most of repetitive testing.
hmm..great info for me, anyway..:)
Your blog provides sufficient information on QA and QC but testing, I suppose, hasn't been given enough emphasis. It would be appreciable if you post more on Testing and the process you follow for the same.
Hi Allan, Jay,Your defintion of QA is a little off, ok, way off base. It is NOT tied to testing or QC and is NOT applied to the product. It is assurance of the quality of a process, which may produce a lousy product if the process is weak. See this article to help clear things up: http://spistuff.blogspot.com/2007/09/qa-vs-qc.html
Thanks for the this clear and succinct definition. I was recently hired as a "QC manager," a role I haven't held before, and was adrift in conflicting expectations. The actual role I hold is more QA than QC, although I suspect I will do both, along with a little testing. There is another with the title of QA lead, but his actual role is more QC. So we have a lot of alignment and setting of expectations to do. This will help.
The actual definitions of QA and QC can better be explained in context of the place they work. As matter of fact Testing is done at in-house or by a third party testing team. Tester at in-house do more of QC rather than QA as they do have a set of requirements and they validate the software against requirements. When coming to third party testers, they are involved in lot of process improvements which will actually help the clients to deliver best software.
i don't agree with"We use the QC process to verify a product does what we think it does, and we use the QA process to give us confidence that the product will meet the needs of customers. "Qc : is the process of testing the quality of a product.Qa : measures the quality of processes used to create quality product.
I think the disconnect is where the terms QA and QC are often used interchangeably. I definitely work as a test engineer at my company, but my title is QA engineer. The title is closer to what the author is saying here, but I think the industry as a whole uses disparate terms to mean similar things sometimes.
What is the main idea qa in Google?
One wonders, what is the thin line between automation and human intervention.
Only just read this article, and noticed date! Feels even more relevant in 2016 :) "Test engineering" best describes what I do now, and what should be happening more. Within that scope, I can have influence/effect on overall project quality, from requirements through to the build pipeline. This was more effective and useful QA "power", than when I held management roles. You can over-analyse these things of course :) Whatever we are within large scope of Quality Assurance, we are part of a team and a common goal.
The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.