MobiDev Webinar: on Handling Post-Release Bugs

San Francisco, CA, December 15, 2013 --(PR.com)-- MobiDev Corporation, a software development company, has recently conducted the second in the series of in-house webinars dedicated to the company's main spheres of activities. It was called 'On Handling Post-Release Bugs'; such a topic is useful for employees who communicate directly with clients. It explains the problems (bugs) which may appear after the release, who is responsible for them and how they can be handled.

The general reasons for complexity of software development are insufficiency and vagueness of requirements and measurements, rapidly changing technologies, and inevitable risks that concern third-party software. Therefore it is extremely hard, or almost impossible, to foresee everything at once. While developing a software product, software developers have to be ready for bugs, which may appear both during the development process and after the release of the product.

But why do bugs appear after the release? The development cycle presupposes that testing has checked everything? There are three reasons why:

1) Other testing conditions. The software is tested on an agreed list of devices, under certain conditions. What can be possibly not taken into account? The answer is: other mobile devices, current conditions of Internet connection, apps installed on these devices;
2) Other sequences of actions. QA engineers test positive scenarios and make sure that the software works under perfect testing conditions. The most important negative scenarios are also tested to see whether the software works smoothly without Internet connection;
3) New OS versions and third-party APIs. A precise list of supported OS versions is agreed beforehand. A typical problem is an update in Facebook or Twitter API; after such updates the software simply might not run or constantly crash.

The recommended approach to work after the release (bugfixing, project support, and adding new features) works in the following way. A minimal team continues implementing features, in case of need instantly switching to bugfixing and support. Therefore the project will develop further, and sudden problems will be eliminated immediately. The client can be sure that users will quickly receive the software update.

If the budget for the post-release works is limited, it is possible to involve developers in case of necessity. Here it's preferable to involve the developers that worked on the project previously. They know more details about the project than anyone, and they are able to perform the needed work as quick as possible. They might not be immediately involved, since they work on other projects. It takes time to switch to the project; as well there must be gathered a number of tasks for implementation for a minimum of 1 week (40 hours). Warranty and SLA shouldn't be provided, because they would raise the budget of the project, which is not preferable for the client. Post-release works are performed on a regular hourly basis - the client pays for the time spent by the developer.

But here the client might have reasonable questions:
- Why should he/she pay for bugfixing in the software that had been tested by the QA team?
- The more hours developers work, the more money they receive. So is there an incentive for them to create high-quality software with minimum bugs?
- Is the development company responsible for its work?

These are good, reasonable questions from a client who analyses the situation. Bugs after the release are inevitable. Everything cannot be foreseen, and the client should be ready to spend the budget after the release. At the same time the company must always aim at developing high-quality software. What does incentivize them to create quality?

- The company isn't interested in protracting the development process. It's always better to be recommended as a competent contractor and get new clients and new projects.
- The company isn't interested in deterring the client at the pre-sales stage by huge estimations, which include all risks;
- The company is interested in implementing projects with speed and quality, finding the balance that will be perfect for the client. If the client's product is successful, the company is successful. That's the matter of self-motivation and the company's personal vision of success;
- Finally, any good company treasures reputation, is interested in long-term collaboration with clients on their new projects, and values recommendations given by clients.

The company's responsibility includes:
- maintaining development infrastructure;
- keeping a stable working team. If a developer is sick (or for some other reason cannot work on the project), or if the developer does not suit the client's requirements for some reason, another qualified specialist can always be found;
- meeting the task deadlines (not of the whole project). Excessive estimations can take place only for intrinsic reasons (such as the risks of third-party APIs).
- the result of work - the software.

Means of avoiding and reducing risks after the release:
1. Test cases, approved by the client;
2. Usage of logging/tracking systems (such as bugsense);
3. Testing on an extensive list of devices; usage of deviceanywhere.com;
4. Beta testing in real-use environment;
5. Usage of automatic testing.

The company must accustom to the needs of a peculiar project and to the requirements and suggestions of the client. These means of handling bug risks are applied after the client's approval.