In my workplace we use scenario based testing. However whenever somethign is fixed or a new patch is added new scenarios are added as a result the list keeps getting longer and longer and takes 3 days plus to test the application. Is there a way to do proper testing without taking a long long time? What do you use?
Thanks
On
Only 3 days to test your application ! We've got test jobs that run for maybe 15 days. And I guess other lurkers around here can tell you that they have even bigger test jobs; you know the drill -- when I were a lad we didn't even have a hole in't' road to live in.
But seriously, 3 days to fully test a release candidate with a benefit stream worth O(USD10^7) doesn't seem outrageous to me. On the other hand, if it's taking you 3 days to test changing one field on a GUI from 12 characters to 24 characters, then that does seem a bit too much. I think your question might be better phrased as 'How much of our development time should be spent on testing ?' and the answer might be anything from 10% -- 50% (possibly higher for safety-critical systems). If you are spending 2 days developing a patch, then testing should probably take no more than 1/2 day.
And yes, the scenario where as your application expands your test suite expands too, is very familiar. However if we add a new bit of functionality we tend to add new tests; a better approach, -- one we never have time for though we always have time to deal with not taking it -- is to modify existing tests. Modify code -> modify tests; add new code -> add new tests.
Yes, we use automated testing as much as we can; we use a lash-up of bash scripts, python programs and make to drive our automated tests. The processors we use never complain that testing is boring and repetitive, so we have no ethical qualms about working the poor dawgs close to heat-death. Sadly local labour laws prevent the same robust management principles being applied to the carbon-based life forms in our offices.
On
I also do believe that u should go for Agile . As agile is a combination of iterative & incremental process therefore the Story Points shared by client i.e. requirements & updates. u can sort the Requirement in the order of priority & can plan for sprints i.e. all requirements should be ordered in high to low order as product backlog and sprints can be prepared from the product backlog . Therefore By the time development is in progress for sprint 1 , u can prepare scenarios for testing of sprint 1 in this span . after the sprint delivery if there is any change request in any process follow the same can be managed easily and with the help of scrum & sprint retrospective meetings the process can be improved in the upcoming projects.Thus Project can be delivered in the sprints easily & in a short span of time.
On
Why don’t you automate your application Test suit? Whenever there is a gap between the current and next release, you can automate the existing test cases in the meanwhile. This will not only save the Testing cycle time but also the Regression Testing will be more accurate without skipping or missing any test scenario.
You can automate at least 60-70% of your total test cases which will save test execution time by a good margin and can be run overnight.
CI can help you to achieve that, automation is the key word. For testing process, you have to do is automation testing, UT, interface testing, UIbased testing and performance testing. But there is a root concept needs to be accepted, quality is not equal to testing. UT can be created by RD before coding is finish; UIbased testing and interface testing are develped by QA in the whole coding process. When the new feather finished, there is a test suite to ensure the quality. The only thing you have to do is functional testing which automation testing can not be covered.