Development, Operation and Maintenance of Software Systems: A Practical Approach
How to approach the full life of a software system: building it, running it in production, and maintaining it for years, with the testing that belongs at each stage and a checklist for app teams.
In this article
Most of a software system's life happens after the launch. The first version gets built in months. Then it runs, gets patched, gets new features and adapts to new phones and OS versions for years. Teams that plan only for development pay for it later in outages, slow releases and code nobody wants to touch.
This post looks at the three stages, development, operation and maintenance, and what each one needs, including the testing that belongs at every stage.
Stage 1: Development
The goal is to build the right thing in a way that's easy to change later.
- Clear requirements and expected results. A one-page product canvas and written acceptance criteria prevent most rework.
- Small, reviewed changes. Short pull requests are easier to review and safer to roll back, whether a person or an AI agent wrote them.
- Tests alongside the code. Unit and API tests run on every build.
- A release checklist. Including exploratory testing on real phones for new features and P1 flows.
Stage 2: Operation
Once the system is live, the goal is to keep it available and know quickly when something breaks.
- Monitoring and alerts. Error rates, crash rates, payment success rates and response times, with alerts that go to someone who can act.
- Staged rollouts. Release to a small share of users first and watch crash reports and Play Store reviews before widening.
- Runbooks. Short written steps for common incidents: payment provider down, OTP SMS delayed, database slow.
- User feedback as a signal. Store reviews and support tickets often show a bug before dashboards do.
Stage 3: Maintenance
Maintenance is more than fixing bugs. It usually falls into four types:
| Type | What it covers | Example |
|---|---|---|
| Corrective | Fixing bugs found in production | Duplicate debit on retry |
| Adaptive | Keeping up with platforms and rules | New Android version changes background limits |
| Perfective | Improving features and performance | Faster app start on budget phones |
| Preventive | Reducing future risk | Removing an outdated library before it breaks |
Adaptive maintenance is easy to underestimate for mobile apps. Every major Android or iOS release, and every new phone model with its own battery saver, can change how an app behaves without a single line of your code changing.
Testing across all three stages
- Development: unit, API and UI tests for new code, plus exploratory testing on real devices before release.
- Operation: smoke tests after each deployment and on staged rollouts.
- Maintenance: regression testing after every fix and platform update. A stable automated suite carries most of this. See what to automate.
A reusable test case library makes maintenance cheaper, because each release starts from a list instead of from memory. The free 99tests test case library covers 25 Indian app flows.
A checklist for app teams
- Do we know our crash rate and payment success rate today?
- Can we roll back a bad release within an hour?
- Do we test every new Android and iOS version before most users get it?
- Is there a regression suite that runs after every fix?
- Do we read Play Store reviews weekly for bug reports?
Where 99tests fits
When a new OS version, a new phone or a big feature lands, 99tests runs exploratory testing on real Android phones and iPhones across Indian cities and networks. You get a reproducible bug report in 3 business days, with packages from ₹9,999 + GST.
