2

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?

Improve this question

3 Answers 3

Reset to default
0

In addition to above answers, My check list for better test strategy for Stable system

  • As the system become stable the tests need to be more deep dive (Integration tests) to identify bugs which are not easy UI / basic failures
  • A check list of bugs released during earlier fix would help to gauge the level testing / possible areas bugs injected by the devs
  • I am totally for automation at early stages, My approach was developing reusable DB scripts, data loading scripts, SOAP UI scripts for Web Service calls which finally provided clarity on automation approach. My suggestion is start developing scripts to simplify tasks before betting for a full fledged automation suite
  • A little bit more white box testing / Dev Discussions always helps to learn more on implementation and think where it can fail
  • Use tools for checking exceptions in logs / windows events / DB Errors. These could be overlooked while testing so a tool's usage to monitor / capture exceptions errors would be useful
Improve this answer
6

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.

Improve this answer
2
  • Good answer. Focus on automated regression suite is more effective, once the system stabilizes.
    – Joe Strazzere
    Oct 8, 2013 at 12:05
  • That's been my experience, too, @JoeStrazzere. It's a little difficult to automate regression against a moving target.
    – Kate Paulk ♦
    Oct 8, 2013 at 16:42
4

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..

In Summary:

  1. Always plan your regression strategy early (preferably before you start)
  2. Always have an idea of what will happen "After" planned sprints complete (for risk management and future planning)
  3. Build your tests to match independent chunks of modular code (easier to plan future testing for changes)
  4. Be Awesome and never 'trust' things are stable.... ever

Hope that helps!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.