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 primarily meant: the presence of 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 ancient programs that have not the most friendly interface, but good maintenance. 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:
As a tester, I can offer to pay attention to the following aspects to increase maintainability.
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:
For creation of a product for certain many tools are used. Among them:
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.
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 a system is used in a system with 100 users, it will surely break down with 500 users.
There may be a document with a technical description of all modules, including including all architectural schemes.
For example, about what tools and how to use for debugging and testing.
Sometimes the programmer may need tester tools to debug the 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.
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.
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 primarily meant: the presence of 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 ancient programs that have not the most friendly interface, but good maintenance. 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 the electrician does not make the wiring diagram, the next time they only apply to him, since 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 had broken in an unfamiliar feature.
Infrastructure Documentation
For creation of a product for certain many tools are used. 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 a system is used in a system with 100 users, 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 the programmer may need tester tools to debug the 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.
Source: https://habr.com/ru/post/431732/
All Articles