Quality Assurance Approach and methods/
Hello experts and gru's of QA, I am working on a Data Warehousing project and I would like your input on how should approach testing, this project has some front-end Business objects like reporting etc... and a huge back-end process for converting data from different source feeds to Oracle database, my delima is should i just write Test plan for overall project and then write test cases or should i write sepeate test plan for Business objects and back-end process aand also write seperatetest plan for performance testing for front-end and seperate for back-end, also, if if you can tell me is there industry standard for the contents of Test Plan, if some can tell me the details of should go in a test plan, and a industry standard document that talks about the Software Quality Assurance approach. Also do you think I should write Seperate Documents for BO and Back-end Test apprach, or it should be just a part of Test plan, please backup your comments with industry standard document.
Thanks for all your help
Re: Quality Assurance Approach and methods/
My approach is to go with the big picture and drill down further. Reason is schedules are quite hectic for most of us, and you don't want to end up spending 1 month of your 6 month project cycle on 10% of the functionality, only to discover that you are only getting 2 months, because a big account is threatening to kick you out, because you are lagging behind a competitor. (And other similar reasons like functionality sneaking in, and other tasks getting in the way.)
My personal approach is write a test case that exercises the entire full path. What you refer as business case. You want to make sure that the test case focus on a good 'sanity' test cases to ensure that customers will not run into an obvious bugs. (Mainly positive test cases with few obvious error conditions.) If you have the tool, you want to do load testing as well. Performance comes at the very end of this. This one is mainly "Let's make sure we don't have an embarrasing bug".
Second phase is to drill down futher into individual functionality in depth. In this section, you want to isolate and focus on specific functionality. At this point, you want to really start beating on each area by passing bad data including truncated, padded, and corrupt data, (max strings + 1). Make sure to prioritize them in order by talking to the product manager for customer requirements, and to dev. manager to figure out which pieces are stable first. Break them down into several cycles, so you don't have one section that is really thoroughly tested while another section gets no attention. Some areas may be OK to skip, if people feel it won't be used at all, but it should be included in the first phase. You can do more load testing, but you should focus mainly on performance of particular piece.
API and other 'unit' level test cases. Sometimes, it's easier to find defects and catch regressions this way. You'll probably never make it at this level. If you do, you can do threading tests, and various api over-load testing.
That's how I'd approach it to mitigate the risk of hectic schedules and ever moving project functionality list.