Además de las revisiones de código por parte de otro desarrollador y al confiar en que sus desarrolladores no harán nada nefasto o estúpido, ¿hay alguna forma de garantizar que cuando lanza una compilación a producción o incluso un control de calidad que no incluye ningún código adicional que no es parte del requerimiento asignado?
Hay muchas cosas que puede hacer para garantizar que el código haga lo que se supone que debe hacer, pero además de confiar en las personas que lo desarrollan (incluidos sus revisores), básicamente no hay forma de asegurarse de que no haga más .
Pero todo se reduce a esa confianza en cualquier otro trabajo también. En algún nivel, necesitas confiar en la gente. Si no puede, consiga otros en los que pueda confiar.
El uso de un enfoque de Desarrollo impulsado por el comportamiento (BDD) o Desarrollo impulsado por pruebas de aceptación (ATDD) significa que el código se autodocumenta. Por lo tanto, introducir funcionalidad más allá de los requisitos originales sería obvio para cualquiera que prestara atención al código base.
Lo que constituye un 'código extra' es una pregunta mucho más difícil. Es muy posible que se agregue código:
Es probable que solo alguien que esté profundamente comprometido con el equipo de desarrollo comprenda la importancia de todo el código que se agrega.
La funcionalidad no deseada puede convertirse en un riesgo significativo para la seguridad del software. La ausencia de arquitectura, diseño, requisitos formales, especificaciones, casos de prueba e infraestructura puede convertir un huevo de Pascua inofensivo en una violación masiva de datos. En algunas organizaciones, esto es un delito de tiroteo.
Se recomienda revisar el código, pero no es suficiente para aplicaciones más grandes con presupuestos limitados. Las pruebas positivas, como las practican la mayoría de los evaluadores de control de calidad, tendrán dificultades para identificar la funcionalidad no deseada. Dicha funcionalidad está, por definición, ausente de las especificaciones del software o de los casos de prueba resultantes.
El análisis de código estático (SCA como Fortify, Veracode, etc.) detectará "código muerto", es decir, código que no se ejecuta durante el análisis de flujo de datos. (Esto va mucho más allá de la compilación). Luego puede revisar los hallazgos para determinar qué está sucediendo y qué hacer. SCA también encontrará otras preocupaciones que podrían ser igualmente graves.
El análisis de código dinámico e integrado , como fuzzing, podría detectar funcionalidades no deseadas en la aplicación.
Respondiendo a esta pregunta de una manera agnóstica del producto/proyecto, de esto se tratan los procesos de calidad, específicamente el control de calidad. Inspecciones del producto antes de la entrega para verificar y validar que cumple con los requisitos y criterios de entrega. No debería importar si el producto es una solución de TI o un baño remodelado o un cono de helado. Inspeccione, ejercite el producto, use una lista de verificación y luego firme o no.
Entendí que está buscando un proceso de desarrollo en el que el código no debe requerir funcionalidades adicionales, excepto las que se solicitan.
Déjame intentar escribir un enfoque simple aquí
Taller de requisitos: una vez que el cliente firma el documento de requisitos, organice una reunión del taller de requisitos con el proveedor de requisitos/experto en TI (desarrollador)/ingeniero de pruebas: esto ayuda a garantizar que haya un entendimiento común con las tres partes interesadas
Estructura de desglose del trabajo: después del taller de requisitos, configure una fase para que el experto en TI proporcione una estructura de desglose del trabajo para el requisito dado y sea revisado por el revisor. Esto ayuda al experto en TI a centrarse en los requisitos y analizar las dependencias.
Escenarios de prueba: después del taller de requisitos, configure una fase para que el ingeniero de pruebas proporcione escenarios de prueba y obtenga la revisión y aprobación del proveedor de requisitos. El experto en TI ejecutará los mismos escenarios de prueba como parte de las pruebas unitarias. Esto ayuda a que todos los equipos tengan un entendimiento común.
Mejor,
Tiago Cardoso
pato de goma
sahan de silva