¿Está bien hacer una prueba de seguridad en paralelo con una prueba de control de calidad?

4

Puede que esta no sea una pregunta muy técnica en sí misma, así que siéntase libre de moverla al foro / pila correspondiente. Sin embargo, realmente agradecería a cualquiera que haya experimentado o que haya experimentado una situación similar y las soluciones que se están adoptando.

Por lo tanto, estoy trabajando como ingeniero de seguridad con una pequeña puesta en marcha. Ahora, en mi organización anterior, una empresa típica, tenía a mi jefe para que se encargara de hacer lo convincente, etc. con la administración de alto nivel y lograr que las cosas requeridas para que trabajemos sin problemas. Sin embargo, en mi función actual, siendo una empresa nueva, soy el único ingeniero responsable de la seguridad de la información de toda la empresa. Ahora, por abrumador que sea, se está convirtiendo en una curva de aprendizaje increíble para mí cada día. Estoy captando diferentes aspectos de la seguridad como pasos pequeños, uno a la vez, comenzando con los activos más importantes que deben protegerse y que se encuentran en el riesgo máximo / en la zona de amenaza. Estoy tratando de priorizar las cosas y ver dónde se necesita una prueba de pluma y dónde se necesita una VA.

Me enfrento a muchos desafíos que me gustaría discutir a continuación: Ahora, dada la situación anterior en la que me encuentro, uno de los principales desafíos a los que me enfrento ahora es que constantemente estoy presionando a los conductores técnicos para asegurarme de que cada nueva característica que se supone que debo probar necesita primero verificar la calidad del control antes Puedo recogerlo para un VA / PT / pruebas de seguridad. La razón es que ha habido un par de casos en los que, debido a un control de calidad incompleto en la función, mis casos de prueba de seguridad dieron falsos negativos, ya que la función en sí se rompió en contra de lo esperado. Ahora, esto es algo que los conductores de tecnología no encuentran lo suficientemente convincente como para permitir las pruebas de seguridad solo después de la aprobación de control de calidad. Necesitan más ejemplos / casos de prueba para respaldar esto . Sus argumentos son,

  

la prueba de seguridad se puede realizar en paralelo al control de calidad y no necesito esperar realmente en el control de calidad, ya que simplemente está empujando la fecha de lanzamiento de forma no necesariamente.

¿Estoy en lo cierto en mi argumento? En caso afirmativo, ¿qué más puedo hacer para convencerlos de mis puntos? Si no estoy en lo cierto, ayúdeme a entender por qué mi argumento es incorrecto.

    
pregunta qre0ct 18.05.2016 - 12:24
fuente

2 respuestas

2

Actualmente trabajo como desarrollador, con cierta responsabilidad en la planificación del sprint, etc., por lo que mi respuesta se basa principalmente en un enfoque de "cómo se deben tener en cuenta las pruebas". Voy a hablar de ágil aquí, pero se aplica el mismo principio.

No puedo ver nada malo en el principio con las pruebas en paralelo al control de calidad, suponiendo que se entienda que cualquier cosa que falla el control de calidad necesitará una nueva prueba.

Suponiendo que la empresa asigne estimaciones para funcionar (piense en desarrollo ágil), el tiempo de desarrollo, el tiempo de control de calidad y el tiempo de prueba de seguridad deben sumarse para dar el tiempo estimado total para que se complete una tarea. Sin profundizar demasiado en el desarrollo ágil, el sprint se compone de una serie de tareas (cartas), que se calculan en la longitud total del sprint.

Una vez que se completa una tarjeta, va a control de calidad y para pruebas de seguridad. Si cualquiera de estos dos pasos falla, volverá para volver a trabajar, etc.

Ahora, en un mundo ideal, todas las tarjetas pasarán el control de calidad y las pruebas de seguridad. Lo que realmente sucede es que algunas tarjetas pasan y otras fallarán (ya sea en el control de calidad o en las pruebas de seguridad). Suponiendo que el negocio no se dé la vuelta y simplemente acepte el riesgo, habrá algunos trabajos y la tarjeta debe volver a la garantía de calidad y la seguridad.

Al ejecutar sus pruebas en paralelo, debería ahorrar algo de tiempo en el sprint. Cuando las tarjetas fallan en el control de calidad, la empresa debe comprender / aceptar que la tarjeta requerirá una nueva prueba de control de calidad y seguridad. Puede terminar gastando el tiempo total estimado de reevaluación, o menos / más tiempo. Ese tiempo entonces afecta el sprint y la fecha de lanzamiento.

Para discutir cualquiera de los dos lados, debes mirar la cantidad de trabajo que normalmente obtienes. Si la mayoría de sus tarjetas fallan en el control de calidad, entonces tiene sentido que realice las pruebas de seguridad una vez que el control de calidad haya finalizado. Si la mayoría de sus tarjetas pasan el control de calidad, entonces tiene sentido ejecutar sus pruebas en paralelo.

He basado esta respuesta en ágil, donde todo debería tener una estimación, etc. El mismo principio se aplica independientemente, cada etapa de desarrollo tendrá un costo de tiempo asociado, incluso si no está escrito en ninguna parte.

Mi sugerencia sería observar cuántas tarjetas generalmente fallan en el control de calidad y calcular si es beneficioso realizar pruebas en paralelo o no.

    
respondido por el Jay 18.05.2016 - 13:34
fuente
1
  

"debido a un QA incompleto en la función, mis casos de prueba de seguridad dieron falsos negativos"

Realmente no entiendo lo que estás tratando de decir aquí. Las pruebas no cambian la funcionalidad, la seguridad, la capacidad o el rendimiento del sistema. Sin embargo, el objetivo principal de las pruebas es identificar dónde el sistema no cumple con alguno de estos aspectos (junto con otros atributos, como la facilidad de uso) que debería , a continuación, solicita cambios en el código / arquitectura / configuración. Los cambios deben volver al ciclo de prueba.

Los únicos argumentos realmente justificables para el orden en que se evalúa cada aspecto son los costos y el tiempo. Las pruebas anteriores pueden ahorrar costos más adelante en el proceso si fallan, pero deberán repetirse cuando se vuelva a trabajar el código. Por lo tanto, las pruebas que probablemente fallarán se deben realizar en una etapa temprana, en contra de favorecer las pruebas que son más baratas de realizar antes en el ciclo en comparación con la disponibilidad de recursos para realizar las pruebas.

Quien sea el último en el proceso antes de que una característica se active, siempre será impopular. El hecho de elegir deliberadamente este rol podría inferirse como un sentido inflado de importancia personal.

    
respondido por el symcbean 18.05.2016 - 13:37
fuente

Lea otras preguntas en las etiquetas