Tester's view on software maintainability

    I want to share thoughts about one of the qualities of software: maintainability.



    Projects do not always pay attention to maintainability. As a result, with the change of command, difficulties begin. Especially if the team is changing unexpectedly and a large composition.

    On projects, I played the role of QA. Among other qualities, one had to take care of maintainability. On the programmer’s side, code maintenance is implied: comments and a good structure. Meanwhile, maintainability is something more. Good maintainability allows you to benefit the manufacturer of the software product. Not for nothing in large companies can be found the ancient programs that have not the most friendly interface, but good maintainability. Due to this, they are not in a hurry to replace them with the designs of competing firms.

    There is an analogy with the laying of electricians in the building:



    • A good electrician before laying the wiring will provide you with its scheme. It will not be necessary even after many years to contact him in order to understand what leads where and how he works. There will be no problems during operation.
    • If an electrician does not make the wiring diagram, the next time they only apply to him, because except him, no one knows how everything works - then you should think about whether you should do business with him.

    As a tester, I can offer to pay attention to the following aspects to increase maintainability.

    Documented functionality.


    Documentation is needed not only for “users somewhere out there,” but also so that at 12 at night any person unfamiliar with the product can use it without asking others for help. For example:

    • the programmer hired yesterday could debug the feature,
    • technical support officer could answer the user's question
    • the tester could check if something was broken in an unfamiliar feature.

    Infrastructure Documentation


    Most likely many tools are used to create the product. Among them:

    • build system. It may consist of several machines, each of which has many settings;
    • other infrastructure services, such as file servers, code storage system (especially if there are library dependencies on other systems), etc .;
    • test benches. Their settings and description should be in test plans.

    All this is tied to the project. And it would be nice to have a detailed description of the structure, so that you can easily restore it when a hard drive fails with the machines of the structure. Or so that you can effortlessly make changes to the infrastructure, without spending time studying every little thing.

    Documentation of problems and risks


    In the process of creating and operating a product, problems are likely to arise. They can be classified and describe the base solutions.

    Some defects may have a workaround. If the defect is serious, then it should be possible to find a way to bypass it in the database of problems. For example, if any settings can be set only in a specific browser.

    If the development reveals information that problems may arise in the future, then such information should be described as risks. For example, if in a system with 100 users a module is used, it will surely break down with 500 users.

    The presence of comments and code descriptions




    There may be a document with a technical description of all modules, including including all architectural schemes.

    Availability of information about the tools used


    For example, about what tools and how to use for debugging and testing.

    Sometimes a programmer may need tester tools to debug functionality. Or, the tester may need information about the developer tools to gather information when a defect is found.

    Including pay attention to the prevalence of tools. Even if some tool is well suited for the problem to be solved, but it is old and not supported, it can cause difficulties.

    Completion of tasks




    As the Pareto principle states: it takes 80% of time to do 20% of the work.

    And if something is not completed, then surely there was a reason. Most likely, it was expensive.

    Also popular now: