¿Cuál es la mejor manera de asegurarse de que agregar nuevas funciones en un software no afecte las funciones existentes?

Las respuestas hasta ahora han cubierto las pruebas, pero hay algunas otras consideraciones que son al menos tan importantes.

Un software bien especificado y bien diseñado es mucho más fácil de modificar que un software mal especificado y mal diseñado. Algunos de ellos tienen buenas especificaciones, por lo que el implementador (y el usuario) saben lo que se supone que debe hacer el software. Mucho de esto es modularidad y ortogonalidad: las diferentes partes de un sistema de software deben interactuar entre sí solo de maneras específicas, con un mínimo de excepciones y efectos secundarios.

Los buenos procedimientos de revisión también ayudan. Los ingenieros experimentados pueden ver una especificación funcional o de diseño y detectar problemas antes de llegar al cliente. Lo mismo ocurre con la revisión de código.

La memoria institucional es importante. Puede ser demasiado esperar que un nuevo ingeniero (incluso uno bueno) diseñe e implemente una característica sin tener problemas. Las personas que han trabajado con el software por un tiempo pueden ayudar a las personas a ponerse al día. También es importante una cultura corporativa que fomente la cooperación: sin esto, la memoria institucional no vale mucho.

¡Pruebas automatizadas y aún más pruebas!

Servicios únicos cubiertos por pruebas unitarias y dependencias simuladas que incluyen datos buenos, perimetrales y malos.

Pruebas funcionales para un grupo de servicios que trabajan en DB de prueba en vivo, servicio de cola, etc.

Integración continua desde commit one.

Esta es una de las razones por las cuales las pruebas unitarias son obligatorias en el desarrollo de software.

Al realizar pruebas unitarias que cubren el porcentaje más alto de su software, se vuelve mucho más fácil agregar nuevas funciones sin romper el código existente. Agrega algún código nuevo, vuelve a ejecutar las pruebas unitarias y, si pasan, está n % seguro de que no romperá nada, donde n es el porcentaje de cobertura de su código (por ejemplo, si sus pruebas unitarias cubren el 90% de su código , si tienen éxito, está 90% seguro de que no rompió nada después de agregar más funciones).

RB./.

Pruebas de regresión automatizadas, aplicadas por medidas de cobertura de código y que requieren actualizaciones de pruebas de regresión que aborden los problemas descubiertos antes de cerrarlos.

Las pruebas automatizadas, tanto las pruebas de unidad como de integración son un requisito Desea tener una cobertura del 90% o más en su código en términos de pruebas automatizadas.