I have been testing a application in agile methodology where requirements change frequently. So, now the application has become stable.So , what are the extra skills to test a stable system?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
In addition to above answers, My check list for better test strategy for Stable system
In my opinion, there aren't any extra skills need to test a stable system. What tends to happen once the system is stable and not under continuous development is that the proportion of time spent on exploratory testing drops compared to the proportion of time spent on regression and checking.
I'm assuming here that by "stable" you mean that the requirements are no longer changing, and the application is not being actively developed, although bug fixes and minor feature development may continue.
In this scenario, if an automated regression suite hadn't been built to cover the critical functionality of the application (precisely how much gets automated varies depending on the application and its targeted user base), I'd be starting there. The automated regression would supplement unit and integration tests built into the build process.
Once a stable regression suite is running on at least a daily basis, I'd be looking at expanding the regression to cover reported bugs, less critical functionality on the basis of how much benefit it offers compared to the time to automate (not every feature of every application can be automated, and many that can be automated aren't worth automating - which is its own question). I'd also be looking at the edges of the application, particularly where it interacts with other systems (defined input/outputs - you don't want to be trying to automate third party commercial applications if you can avoid it) and ways to streamline and improve the automated regression.
Finally, always allocate time to maintain the automated regression. This is the one thing that isn't optional. If you don't have maintenance time built into your scheduling it will bite you, usually when you can least afford it.
Well, firstly I hope you've been building up a decent test library as you've been going else there's a lot of work in re-building a regression test pack. Better still, I'd hope that while working with the Dev's you built up an automation framework (or at least 'bunches of scripts' that could be used in a future framework) per sprint.
Not doing this correctly has bitten me hard in the past, as has not being able to convince people to do so when starting somewhere new ;)
Skills wise, you just need to be your normal awesome self.
General rules, Keep checking the little things, it's only as stable as the last test run, every change requires you to be either all-encompassing and retesting entire suites of tests OR you're using your risk management and analysis skills to measure and build testing suites needed for the changes being made to it.
All of that is made easier by thinking about the end-game early in the process. Next time you run through an Agile project, If you build suites in the right way, along with building low-dependency modular code, then you should be on the path to maintaining that stable system.
The only other concerns are how deeply you go into testing the infrastructure, load and performance testing, integrations and API's etc... all of those follow the same rules, but require a slightly different set of skills..
Hope that helps!