| || |
- 1 Post By katepaulk
- 1 Post By dlai
QA Process to implement IF one is not in place
If your company didn't have a QA process. What process would you implement and how would you implement it?
_There's_ a hole with no bottom... :-)
There's no one-size-fits-all QA process that could be applied to any company, you'll need to examine various aspects of your company and start to tailor a solution to your own particular needs.
Some questions to keep in mind:
- size of company?
- size of development team?
- budget to spend on QA tools, resources, etc?
- development methods? Agile, waterfall / V-model?
- range of products that require QA'ing? How diverse are their developments?
- type of products? Sensitive medical devices / Financial products / HR, or a hundred flakey iPhone apps in the hope of a "big hit"?
- urgency of QA required / speed to market of product?
- culture of company/developers/management towards QA - is it seen as a must-have, or a necessary evil? Would they be more responsive to baby steps or major changes?
- backing of major stakeholders in change - are QA processes being sought because the developers want change but management doesn't see the need? Or the other way around? Or both, or neither? (ties in with the culture above)
- what's the reason for looking for QA processes? To genuinely improve their products, or to be able to sign off an ISO cert or similar? Or a mixture?
- what QA processes do they already have in place? "None" is probably not the correct answer, dig deeper and you'll probably find that they do some form of unit testing at least. Do they peer review code? Version their source code and maintain branch code? Who reviews and signs off that the code is ready for release?
Talk to the people involved - developers, managers, senior stakeholders, to get a grasp of all of the above.
If you want a case study on introducing QA to a development team using Developers Exploratory Testing, there's a great series of blog posts by Sigge Birgisson starting here. I'm not advocating that DET is your solution, but the process followed is a good one: A new teams encounter with DET/TET as a framework for testing ? Part 1-Context | Happytesting
It would depend.
The QA process needs to meet the needs of the company. A startup producing casual games has different needs than an established organization producing enterprise software, which in turn has different needs than a company that produces software for medical devices.
The internal culture of the company also affects the process. The process for a company with a culture of rigorously unit-testing all code and cross-testing by developers in an agile environment will look very different than the process for a company working in a waterfall environment with an "over the wall" mentality - and that's just two of the many, many examples.
Regardless of what the process would look like, implementing would involve getting buy in from management and development as well as the test team because they are also heavily involved and invested in the quality of the product, and looking for minimum-impact ways to make every change needed. No matter what the environment, the test team can't operate in isolation. They need to have established common ground with the rest of the development team and with the overall management for anything to work, otherwise they run the risk of being viewed as an impediment.
I like the idea of living requirements. Biggest problem I see going into any new organization is people tend to start of writing requirement docs, then test cases in separate excel sheets, which later then are replaced with new requirements and new test case excel docs. So you have both requirements and test cases read like legal documents. Where you have a set of laws, then a sets of admendments that update the laws, then a set of by laws that cover special case scenarios, etc...
How I'd do things different is I'd instead of using excel and word docs for managing test cases and requirements, is I'll use a test case manager to manage requirements, one that supports test case versioning. Then let the test cases be the requirements, and instead of writing separate requirements for each project, have the requirements live in the test cases. Of course that alone doesn't manage prioritizing the work being done, so that would be the job of a proper change tracking system, and a good project manager.
I see too many start ups not use proper test case management and bug tracking system, then suffer for 2 years as they make the transition. They go through this so called, 'Archeology' period where they start discovering requirements they didn't realize they had, and realized their system was more complex than they imagined.
This is why Im asking I want to get in there and do things the right way going into it