我想分享我对软件质量之一的看法：可维护性。
项目并不总是注意可维护性。 结果，随着团队的变化，困难开始了。 特别是如果团队发生意外变化并且组成很大。
在项目中，我担任质量检查的角色。 除其他素质外，还必须照顾好伴奏。 从程序员的角度来看，首先，这意味着代码应附带注释和良好的结构。 同时，伴奏更重要。 良好的可维护性使您受益于软件产品的制造商。 并非没有原因，在大型公司中，您会发现古老的程序与最友好的界面相去甚远，但具有良好的可维护性。 因此，他们不急于取代竞争性公司的发展。
您可以比喻在建筑物中铺设电气设备：
- 好的电工会在布线前为您提供电路。 即使多年后也没有必要求助于他，以了解是什么导致了它在哪里以及如何工作。 操作期间不会有任何问题。
- 如果电工没有做接线图，下一次他们只会联系他，因为 除了他以外，没有人知道所有的安排-然后您应该考虑是否值得与他做生意。
作为测试人员，我可以为您提供以下注意事项，以提高可维护性。
功能文档。
不仅需要为“那里的用户”提供文档，而且还需要文档，以便在12点中午十二点之前，不熟悉该产品的任何人都可以使用它，而无需其他人的帮助。 例如：
- 昨天雇用的程序员可以调试功能，
- 技术支持可以回答用户问题
- 测试人员可以检查陌生功能中的某些内容是否损坏。
基础架构文档
许多工具最有可能用于创建产品。 其中：
- 组装系统。 也许它由几台机器组成，每台机器都有许多设置。
- 其他基础结构服务，例如文件服务器，代码存储系统（尤其是在其他系统上有库依赖项的情况下）等；
- 测试台。 它们的设置和描述应在测试计划中。
所有这些都与项目相关。 并且最好对结构进行详细的描述，以便在具有该结构的计算机的硬盘驱动器发生故障时可以轻松地还原它。 或者，这样您就可以毫不费力地对基础结构进行更改，而无需花费时间研究每件事。
记录问题和风险
在创建和操作产品的过程中，肯定会出现问题。 它们可以分类并描述为解决方案基础。
某些缺陷可能有解决方法。 如果缺陷很严重，那么应该可以在问题数据库中找到解决它的方法。 例如，如果只能在特定的浏览器中设置任何设置。
如果事态发展表明未来可能会出现问题，则应将此类信息描述为风险。 例如，如果一个模块在有100个用户的系统中使用，则可能在500个用户时中断。
注释和代码说明
可能会有一个文档，其中包含所有模块的技术说明，包括所有架构方案。
有关所用工具的信息
例如，什么工具以及如何用于调试和测试。
有时，程序员可能需要测试器工具来调试功能。 或者，测试人员可能需要有关开发人员工具的信息，以便在发现缺陷时收集信息。
其中值得关注的是工具的普遍性。 即使某些工具非常适合手头的任务，但它既旧又不受支持，也可能会很困难。
任务完成
正如帕累托原则所说：完成20％的工作需要80％的时间。
如果某些事情没有完成，那一定是有原因的。 最有可能的是，它很昂贵。