ARTÍCULOS

Análisis exploratorio en la adopción de prácticas de pruebas de software de la ISO/IEC 29119-2 en organizaciones de Lima, Perú

Exploratory analysis in adopted software testing practices of ISO/IEC 29119-2 in organizations in Lima, Peru

Abraham Dávila¹, Cecilia García², Sandra Cóndor³

^1,2 Departamento de Ingeniería, Pontificia Universidad Católica del Perú, Lima, Lima 32, Perú, abraham.davila@pucp.edu.pe, garcia.cecilia@pucp.edu.pe

³ Escuela Profesional de Ingeniería de Software Universidad Nacional Mayor de San Marcos, Lima, Lima 1, Perú, sandra.condor@unmsm.edu.pe

---

 

RESUMEN: Se espera que la ISO/IEC 29119 tenga un impacto favorable en el dominio de las pruebas de software. Sin embargo, en pequeñas empresas en Lima, se ha observado que las pruebas son desordenadas, no logran una adecuada cobertura y el software presenta errores en su operación. En este estudio se hizo una investigación exploratoria en organizaciones que prueban software, para determinar factores de entorno que influyen en el grado de adopción de prácticas de pruebas de software. El análisis se realizó usando un estudio de caso múltiple de cuatro unidades de análisis, considerando dos tipos de organizaciones. Las organizaciones que actuaron como fábricas de software en un esquema contractual (exigente) presentaron un mayor nivel de adhesión a las prácticas del estándar que aquellas que actuaron como parte de un equipo de desarrollo de software. Además el factor Presión Externa es uno de influencia positivo para el primer grupo y de manera negativa para el segundo grupo.

Palabras-clave: pruebas de software, mejora de procesos, ISO/IEC/IEEE 29119, ISO/IEC 33063.

---

 

ABSTRACT: It is expected for the ISO/IEC/IEEE 29119 to have a favorable impact on this software testing domain. However, in small businesses in Lima, these activities are performed in uncontrolled way, tests do not achieve adequate coverage and the software operates with errors. In this study an exploratory research was performed in organizations conducting software testing, the objective was to determine environment factors to affect the extent of adoption of software testing practices. The analysis was performed using a multiple case study analysis of four units, considering two types of organizations. Organizations that acted as software factories under a contractual scheme presented a higher level of adherence to standard practices than those who acted as part of a software development team. In addition, the External Pressure factor is one of positive influence for the first group and negatively for the second group.

Keywords: Enter up to five keywords, separated by semicolons.

---

 

1. Introducción

Las pruebas de software han evolucionado desde actividades realizadas por los propios equipos de desarrollo de software (Myers, 1979; Vasconcelos et al., 2017) hacia las que se ofrecen como servicios (Martin, Rooksby, Rouncefield, & Sommerville, 2007 ) e incluso bajo un esquema masivo (crowdsourced testing) (Yuan-Hsin & Tsenga, 2013).

Desde la perspectiva del proceso de pruebas, se ha desarrollado modelos como TPI (Visser, y otros, 2013), TMMI (TMMI Foundation, 2009), TestPAI (Sanz, Saldaña, Garcia, & Gaitero, 2008), MTP (Carvalho Cavalcanti Furtado, Wanderley Gomes, Carneiro Andrade, & Honório de Farias Junior, 2012) y alrededor de otros 20 modelos relacionados con las pruebas de software (García, Dávila, & Pessoa, 2014). En particular, la ISO/IEC 29119 (ISO/IEC, 2013) representa un esfuerzo internacional que busca marcar un norte para organizar este dominio. Sin embargo, según (Nayyar & M. Rizwan, 2013), algunos problemas críticos en las pruebas de software son: (i) los gestores las consideran difíciles, (ii) las actividades de desarrollo se extienden consumiendo el tiempo de pruebas, (iii) la planificación pobre de las pruebas, (iv) la falta de participación de usuarios y (v) la falta de soporte de la dirección; entre otros. En (Martin, Rooksby, Rouncefield, & Sommerville, 2007 ) y (Kaner, 2006) se reportan también problemas en el proceso de pruebas de software. Asimismo, durante el proyecto COMPETISOFT-Perú (Dávila, y otros, 2012), se observó que las prácticas de desarrollo de software, incluyendo las de pruebas de software, se realizan de manera inadecuada; por lo que las actividades de pruebas resultan desordenadas, no se logra una adecuada cobertura del producto y el producto final presenta errores en la operación.

Estudios sobre prácticas de pruebas han sido desarrollados para obtener información de la industria de software canadiense (Vahid & Junji, 2013) y sobre temas relacionados en (Martin, Rooksby, Rouncefield, & Sommerville, 2007 ) y (Causevic, Sundmark, & Punnekkat, 2010). Los resultados obtenidos refieren a prácticas genéricas o temas conexos sin analizar un modelo en particular. Asimismo, el trabajo de (Van Veenendaal & Bath) presenta los factores críticos de éxito en la mejora de proceso en pruebas de software.

En este artículo se presenta una investigación exploratoria sobre el grado de adopción de las prácticas de la ISO/IEC 29119 en organizaciones que realizan pruebas de software y la identificación de factores de entorno que influyen. La investigación está basada en un estudio de caso con múltiples unidades de análisis. En lo que sigue el artículo se organiza de la siguiente manera: en la Sección 2, se presentan los modelos considerados; en la Sección 3, muestra trabajos relacionados; en la Sección 4, se describe el protocolo de investigación del estudio de caso; en la Sección 5, se presentan los resultados obtenidos; y en la Sección 4, se presentan la discusión final y trabajo futuro.

2. Conocimiento base

En esta Sección se presenta los modelos considerados para este análisis como la ISO/IEC/IEEE 29119, la ISO/IEC 33063 y el de Hammed; así como con trabajos previos relevantes. Se debe señalar que dentro del Proyecto ProCal-ProSer (Dávila, 2013) se optó por utilizar estándares internacionales.

2.1. ISO/IEC/IEEE 29119-2

La ISO/IEC/IEEE 29119 es el nuevo estándar internacional desarrollado por la ISO/IEC referido a las pruebas de software (ISO/IEC, 2013) y está constituido a la fecha por (ISO/IEC, 2013): 4 publicaciones (Conceptos y definiciones, Procesos, Documentación y Técnicas) y otras 3 en desarrollo (Pruebas dirigidas por palabras clave, Modelo de evaluación de procesos, y Revisión de productos de trabajo). La Parte 2 presenta un modelo de proceso de referencia (PRM del inglés Process Reference Model) para pruebas de software; que es evaluado utilizando la ISO/IEC 33063 (ISO/IEC, 2015) que presenta el respectivo modelo de evaluación de proceso (PAM del inglés Process Assessment Model). Asimismo, la Parte 2 (ISO/IEC, 2013) presenta ocho procesos organizados en tres categorías (capas), que cubren los tres niveles organizacionales usuales (alta dirección, dirección intermedia y la operación) tal como se aprecia en la Figura 1; y para cada proceso del PRM presenta al menos su identificador, nombre, propósito y resultados del proceso. En la ISO/IEC 33063 se presenta además las prácticas base asociadas a cada resultado de proceso y las entradas y salidas de cada proceso; entre otros elementos.

 

 

2.2. ISO/IEC 15504 e ISO/IEC 33063

La serie de normas internacionales ISO/IEC 15504 es un referente para la evaluación de procesos de software (ISO/IEC, 2003). En la actualidad este estándar presenta tres partes (ISO, 2016) y existe un nuevo proyecto de serie de normas bajo el patrón de identificadores ISO/IEC 330xx donde se redefine algunos paradigmas de la serie ISO/IEC 15504 (ISO/IEC, 2015). En lo que sigue se explican algunos aspectos de la ISO/IEC15504 y se hará referencia, en caso amerite, a la norma respectiva de la familia ISO/IEC 330xx; pues la migración sigue en proceso.

La ISO/IEC 15504-2 (ISO/IEC, 2003) establece un proceso de evaluación que permite el uso de un PAM para evaluar un PRM y establece un conjunto de requisitos que se tienen que cumplir tanto para el PAM como para el PRM. Estos requisitos han sido incorporados y ajustados en la ISO/IEC 33002 (ISO/IEC, 2015), pero ello no afecta el trabajo que hemos realizado. El proceso de la ISO/IEC 15504 para la evaluación y los requisitos establecidos contribuyen a un evaluación objetiva, repetible y fiable, tal como se señala en (Simon, Emam, Rousseau, Jacquet, & Babey, 1997).

El proceso de evaluación permite (ISO/IEC, 2003): (i) determinar la capacidad del proceso; (ii) calificar atributos de proceso (AP) que contribuyen con lo indicado en (i); y (iii) usar una escala de calificación de AP basada en el logro del propósito del proceso y cuya escala es: N (no logrado), P (parcialmente logrado), L (del inglés largely o ampliamente logrado) y F (del inglés fully o totalmente logrado). Un AP es una característica medible de la capacidad de un proceso (ISO/IEC, 2004), y en particular hemos considerado el AP.1.1 que refiere al atributo proceso realizado, el cual es evaluado a través de indicadores de nivel 1 como: entradas, salidas y prácticas base. Los indicadores específicos para evaluar la ISO/IEC/IEEE 29119 están contenidos en la ISO/IEC 33063 (que es el PAM correspondiente).

2.3. Factores en mejora de procesos

Se han realizado diversos trabajos sobre factores y modelos de factores entre los cuales se puede mencionar: (i) un estudio sobre motivaciones del equipo de proyectos y la mejora de procesos (Baddoo & Hall, 2002); (ii) un estudio basado en un modelo de madurez para determinar el impacto de factores críticos de éxito en la mejora de procesos (Rainer & Hall, 2002); (iii) un marco de trabajo de factores situacionales propuesto en el desarrollo de software (Clarke & O’Connor, 2012); (iv) un marco de trabajo propuesto de factores de éxito de la mejora de procesos en empresas Web pequeñas y medianas (Sulayman, Mendes, Urquhart, Riaz, & Tempero, 2014); (v) un estudio de factores críticos de éxito sobre 34 implementadores de mejora de procesos (Niazi, Wilson, & Zowghi, 2006); una encuesta que analiza los factores organizacionales sobre 120 organizaciones (Dyba, 2005); y el trabajo de (Van Veenendaal & Bath) que presenta los factores críticos de éxito en la mejora de proceso en pruebas de software cuando se busca introducir un modelo en concreto a una organización.

Para el caso del Proyecto ProCal-ProSer se ha trabjado (Dávila & Pessoa, 2015) con el modelo de factores de Hammed (Hameed, Counsell, & Swift, 2012) y que presenta a los factores organizados por categoría y estos a su vez aplicados en distintos momentos de la adopción, como se presenta en la Figura 2.

 

(clique para ampliar ! click to enlarge)

 

2.4. Trabajos relacionados

En la industria de software se han desarrollado algunos trabajos relacionados a nuestra investigación. En particular se puede mencionar: (i) el artículo de (Vahid & Junji, 2013), presenta una encuesta que busca caracterizar las prácticas de pruebas de software en Canadá basada en las respuestas de 246 profesionales, siendo los principales hallazgos sobre las empresas: (i) el entrenamiento relacionado a las pruebas de software está en crecimiento; (ii) predomina el estilo tradicional de hacer las pruebas después del desarrollo y pocas usan enfoques más actuales; (iii) en la mayoría el número de desarrolladores es mucho mayor al de los probadores de software, con ratios que oscilan desde 1:2 hasta 1:5; (iv) se gasta hasta el 40% del presupuesto del proyecto en realizar pruebas de software, entre otros. Y (ii) el artículo de (Causevic, Sundmark, & Punnekkat, 2010) presenta una encuesta enfocada en percepciones de 83 profesionales de la industria europea sobre el proceso de pruebas de software. Los encuestados son categorizados en relación a aspectos contemporáneos de la disciplina de ingeniería de software: criticidad y seguridad de los productos software, agilidad del proceso de desarrollo de software, distribución del desarrollo, dominio de las aplicaciones y la cantidad de pruebas realizada por el encuestado. Los hallazgos de este trabajo revelan discrepancias entre las prácticas actuales de pruebas de software y las que son percibidas como buenas prácticas. De su análisis cuantitativo, el uso del enfoque TDD es donde se halló la mayor diferencia entre la práctica actual y la práctica deseada por los encuestados.

4. Protocolo de investigación

La investigación exploratoria se orienta a identificar las diferencias que existen en la adopción de prácticas entre organizaciones que están obligadas por contexto (de manera contractual) a ser más formales y otras que se dan como parte de un equipo de desarrollo de software, por lo que el protocolo de investigación utilizado es el de Estudio de Caso. Para nuestro trabajo se usó el esquema presentado por Runeson y Höst (Runeson & Höst, 2009) y Genero et al. (Genero Bocco, Cruz-Lemus, & Piattini Velthuis, 2014); así como las directrices internas del Proyecto ProCal-ProSer (Dávila, 2013). El protocolo seguido se muestran en la Tabla 1, donde P es Planificación, E es Ejecución y R es Reporte.

 

 

A continuación se presenta la descripción de las etapas de planificación:

· Etapa P1-2, se estudia cuatro organizaciones (unidades de análisis) que realizan pruebas de software y que se pueden agrupar en dos tipos de organizaciones: una como unidad de negocios independiente del equipo de desarrollo (Tipo A TA) y otra como parte del equipo de desarrollo de software (TipoB TB). Las empresas participantes fueron las que respondieron a una invitación realizada a través del proyecto ProCal-ProSer (Dávila, 2013) y a empresas de la Asociación de Productores de Software (APESOFT), que se describen en la Sección 5.1.

· Etapa P1-3, la teoría requerida, que se presenta en Secciones 1 y 2.

· Etapa P1-4, la pregunta de investigación de este estudio es ¿qué prácticas de la ISO/IEC 29119-2 (descritas como prácticas base en la ISO/IEC 33063) pueden considerarse como adoptadas en cada tipo de organización estudiada y qué factores de entorno influyeron?

·  Etapa P1-5, los métodos de recolección establecido son de dos tipos: (i) datos obtenidos mediante un proceso formal y riguroso de evaluación de procesos, basado en un único proyecto representativo en cada organización, utilizando la ISO/IEC 15504-2 y la ISO/IEC 33063; y (ii) una revisión de los resultados obtenidos con miembros del Proyecto ProCal-ProSer considerando las características de cada unidad de análisis, los tipos de proyectos y el tamaño de las organizaciones. Para lo indicado en (i) se puede considerar la recolección como de primer grado según lo señala Genero et al. (Genero Bocco, Cruz-Lemus, & Piattini Velthuis, 2014), pues los investigadores estuvimos involucrados de manera directa y en tiempo real en la recogida de datos; y para lo indicado en (ii) se establecieron discusiones con otros miembros del Proyecto y el equipo evaluador, que según Genero et al. (Genero Bocco, Cruz-Lemus, & Piattini Velthuis, 2014) pueden ser consideradas como del tipo “No estructurada”.

· Etapa P1-6, la selección de datos se realizó considerando la fuente: (i) para el primer caso, un informe que presenta el perfil de proceso y además se obtiene la calificación de las prácticas base de todos los procesos del modelo que denominaremos un perfil de prácticas adoptadas, calificadas con N, P, L o F según lo indicado en la Sección 2.2; (ii) para el segundo caso, se analizó si se justificaba o no alguna variación al perfil de prácticas adoptadas tomando en cuenta las características de cada unidad de análisis. Se debe señalar que el perfil de prácticas adoptadas se obtuvo en la evaluación con la ISO/IEC 15504 a pesar de no ser un resultado formal de este proceso. La elaboración de este perfil se incluyó para contar con una herramienta de análisis dentro del Proyecto ProCal-ProSer.

· Etapa P2-1, la definición de cómo se realiza la recolección está asociada a lo definido en P1-5 y P1-6, siendo para: (i) el primer caso un proceso formal y riguroso (como se indicó), realizada por evaluadores calificados, siguiendo el protocolo establecido en la ISO/IEC 15504-2 (ISO/IEC, 2003), que incluyó la planificación de las reuniones con las personas encargadas de los procesos, la revisión de evidencias proporcionadas, la calificación de los procesos y la elaboración del informe de evaluación; así como la verificación de la conformidad del proceso seguido; (ii) el segundo caso, mediante un proceso de discusión con miembros del Proyecto sobre los resultados obtenidos. Estas dos acciones fueron consecutivas.

5. Resultados obtenidos

Para realizar el análisis se trabajó con cuatro empresas (o unidades de análisis) que se describen a continuación para poder contextualizar algunos hallazgos. Asimismo, se presentan los resultados individuales y agrupados de las evaluaciones realizadas, el análisis de los mismos y su interpretación.

5.1. Instancias de estudio

Las empresas participantes, como se indicó en la Sección 4, etapa P1-2, son cuatro organizaciones agrupadas en dos tipos de organizaciones. Un primer grupo (Tipo A o TA) son dos unidades de análisis corresponden a empresas que tienen al grupo de pruebas dedicado de manera exclusiva a un proyecto de un cliente en sus instalaciones siendo el resultado relevante el reporte de prueba. Un segundo grupo (Tipo B o TB) son dos unidades de análisis que corresponden a grupos de prueba que son parte de un proyecto mayor siendo el resultado relevante el software. A continuación se presentan las organizaciones participantes usando un alias para cumplir con los acuerdos de confidencialidad.

· Caso Rho (R): Se trata de una unidad de negocios de una empresa transnacional desarrolladora de software y de tecnologías de información. La Unidad ha sido contratada como una fábrica de pruebas software, mediante un proceso de licitación con el Estado. La entidad del gobierno tiene como responsabilidad el manejo de información y dinero de trabajadores del país por lo que requiere formalidad del proveedor del servicio de pruebas establecidas en el contrato.

· Caso Phi (P): Se trata de una unidad de negocios de una empresa mediana especializada en pruebas de software. La Unidad ha sido contratada como una fábrica de pruebas software, mediante un proceso privado. La empresa contratante es una del sector financiero y requiere formalidad de parte del proveedor del servicio de pruebas establecidas en el contrato.

· Caso Xi (X): Se trata de un departamento de pruebas de software de una empresa mediana que desarrolla software y ofrece servicios de pruebas. La empresa ha sido contratada para el desarrollo de un software para el sector de cosméticos y tiene en su equipo de proyecto a un grupo de profesionales de pruebas (de su propio departamento). La empresa contratante es una del sector de cosméticos y presenta exigencias a nivel del software en general y nada en específico para el equipo de pruebas.

· Caso Mi (M): Se trata de un departamento de pruebas de software de una empresa pequeña que desarrolla software. La empresa ha sido contratada para el desarrollo de un software para la gestión de eventos y tiene en su equipo de proyecto a un grupo de profesionales de pruebas (de su propio departamento). La empresa contratante es una del sector servicios y presenta exigencias a nivel del software en general y nada en específico para el equipo de pruebas. Esta empresa presenta las características descritas en (Muñoz, Gasca, & Valtierra, 2014).

5.2. (E1-1) Recolección los datos

Los datos recopilados de las evaluaciones de proceso se presentan en la Tabla 2, consolidando los resultados de las calificaciones de las prácticas base del modelo ISO/IEC 29119-Parte 2 (ISO/IEC, 2013). Se trata de un total de 34 prácticas base distribuidos en 8 procesos definidos (ISO/IEC, 2015) y se usó las calificaciones N, P, L, F, basadas en la ISO/IEC 15504-2. De manera correspondiente se aprecia en la Figura 2 los resultados de las evaluaciones de las cuatro organizaciones. Las prácticas base mostradas en la Figura 2 y Tabla 2 corresponden a las descritas en la ISO/IEC 33063, y están precedidas por un identificador compuesto por el identificador de proceso (ver Figura 1), las letras BP (del inglés best practice) y un correlativo.

 

 

5.3. (E2-1) Análisis de los datos

Para determinar el grado de adopción de las prácticas se procedió a consolidar los resultados del proceso de evaluación para cada tipo (TA y TB) de modo que se puedan comparar y a partir de ello establecer interrogantes de investigación a futuro, análogo a lo presentado en (Baños, Melendez, & Dávila, 2016). Se ha considerado que las calificaciones N, P, L y F son consecutivas y las hemos hecho corresponder con 1, 2, 3 y 4 para determinados análisis más adelante. El criterio seguido para la consolidación de las calificaciones de cada par de organizaciones (unidades de análisis) se basa en un conjunto de reglas mínimas que toman en cuenta la realidad de las empresas en Lima y que se presentan a continuación:

· Si las calificaciones de ambas son idénticas entonces se da la misma calificación. En nuestro caso: N y N da N (representado por NN→N), PP →P, LL→L, FF→F.

· Si la calificación de ambas difieren en una unidad se le asigna el de menor valor. En nuestro caso: NP o PN →N, PL o LP → P, y LF o FL → L.

· Si no encaja en ninguna de las anteriores se le asigna indeterminado (I). En nuestro caso son: LN o NL → I, FN o NF → I, FP o PF → I

La consolidación de los datos se puede apreciar en el Apéndice A, donde las columnas R o P, son las calificaciones de las empresas del tipo TA (unidades de negocio como fábrica de pruebas) y cuya consolidación está en la columna R.P (Rho-Phi) con un comentario de la calificación obtenida. De manera correspondiente en el No texto: Apéndice B, se tiene para Xi o Mi, consolidado X.M (Xi-Mi) y comentario adicional en cada caso.

En el caso de los factores de entorno considerados en el análisis a partir del modelo utilizado se tiene en la Tabla 3 aquellos que se considera que sí influyeron. Se omite aquellos que no aplicaban a los casos analizados como: E03 Apoyo del gobierno, E04 Soporte del vendedor, E05 Soporte de los socios, E06 Disposición de socios, E08 Vinculación vertical, E09 Defensa de los socios, E11 Número de competidores, E14 Confianza en los socios, E15 Globalización y E16 Influencia social. En la Tabla 3 se califica para cada factor con alta (A), media (M) o baja (B) influencia y positiva (+) o negativa (-) según sea el caso.

 

 

5.4. (E2-2) Interpretación de los datos

En la Tabla 4 se presentan los conteos y porcentajes respectivamente de las calificaciones de las evaluaciones de las organizaciones de manera individual y agrupada. Estos conteos se obtienen de las tablas de los Apéndices A y B. En base a los datos de la Tabla 4, se puede apreciar que Rho y Phi, que han sido agrupadas en TA, Fábrica de Software, tienen un mayor nivel de adhesión a las prácticas de la ISO/IEC/IEEE 29119-2, pues ambas están bajo un contrato con dedicación exclusiva y reglas exigentes sobre resultados del proceso de pruebas. De otro lado, para el TB, se puede observar que Xi y Mi (ver Tabla 4) tienen un menor grado de adhesión pues sus equipos de trabajo de pruebas son en realidad parte de un equipo mayor preocupado en el desarrollo de un software. Indagando más para el TA se confirmó que los jefes de proyecto le prestan menos atención del tema de pruebas de software.

 

 

Además, tomándonos una licencia, sobre el uso de las calificaciones como valores numéricos, se calculó que la adhesión promedio para Rho= 3.2, Phi= 3.3, Xi= 2.5, Mi= 1.5; y para los pares Rho-Phi = 3.3 y para Xi-Mi = 2.0; lo que confirma de manera preliminar es que las organizaciones del TA presentan un mejor nivel de adhesión que las del TB.

A nivel de proceso organizacional (OT1), ver Figura 1 (para ver el nombre del proceso), se puede señalar que las prácticas del proceso son poco consideradas en las organizaciones. En el caso de OT1.BP1 existen razones externas (el contrato en Rho y Phi) que influyen en una calificación de L; y de manera excepcional en Xi que es una empresa que busca crecer en este mercado.

A nivel de los procesos de gestión de pruebas (TM.1, TM.2, TM.3), se hace notoria la diferencia entre ambos Tipos de Organizaciones. Para el caso de Rho-Phi es superior en casi todas las características a Xi-Mi. La excepción es en la práctica TM.1.BP1, para el caso de Xi; situación que se justifica en alguna medida pues Xi es una mediana empresa y está en crecimiento.

En los procesos de pruebas dinámicas (DT.1, DT.2, DT.3, DT4) las cuales son más a nivel operativo, se nota que hay en los cuatro casos una mejor calificación de sus procesos.

 

 

 

De la Tabla 3 se puede apreciar que la Presión Externa (E02) es uno de los que más influye para las empresas del tipo TA (Rho y Phi) y tiene sentido pues existe un contrato que le da un marco de trabajo específico para pruebas de software. Para el caso de las empresas del tipo TB (Xi y Mi) es negativo para el grupo de pruebas pues dicha presión se traslada al equipo de desarrollo y éstos al incumplir con el proyecto terminan por sacrificar las actividades del equipo de pruebas. Además en el caso de Xi y Mi existen diferencias, pues Xi sí ha tenido un interés en hacer mejor las cosas y por ello hay pocas coincidencias en los factores influyentes.

6. Discusión final y trabajo futuro

Las observaciones iniciales, en proyectos anteriores, permitió plantear esta investigación exploratoria con la percepción inicial que las organizaciones tendrían muy baja adhesión a las prácticas de la ISO/IEC/IEEE 29119-2 y que las unidades que actuaban como fábricas de software tendrían un mejor desempeño. Durante este estudio exploratorio se comprueba, de manera preliminar, que los dos tipos de organización (TA y TB) tienen distinto nivel de adopción de las prácticas del estándar y que existen variaciones menores en cada caso.

Un aspecto influyente para los del TA es que los contratos configuran un escenario que fuerza al cumplimiento de ciertas prácticas y que al usar herramientas de gestión, se logra un buen nivel adopción; esto tiene sentido con el impacto positivo del factor Presión Externa. Sin embargo, también se detectó que las organizaciones cumplen lo mínimo establecido en dichos contratos y no aprovechan los beneficios de algunas prácticas de la ISO/IEC 29119-2 que pueden contribuir a su calidad y productividad como equipos de pruebas de software.

Un aspecto que influye de manera negativa en los casos del TB es que ser parte de un proyecto mayor, los subordina a la buena predisposición que pueda tener el Jefe de Proyecto y los desarrolladores con respecto al equipo de pruebas, siendo recurrente que si hay demoras en desarrollo, se sacrifique el tiempo del equipo de pruebas. Esto también se condice con el hecho que el factor Presión Externa llega como algo negativo para el equipo de pruebas.

Como trabajo futuro se propone realizar un estudio de caso con múltiples organizaciones y usando otros factores que permita identificar cuáles de ellos han contribuido de manera favorable y cuáles han representado una barrera para la adopción de las prácticas de la norma ISO/IEC 29119-2.

 

REFERENCIAS

Baddoo, N., & Hall, T. (2002). Motivators of Software Process Improvement: ananalysis of practitioners' view. Journal of Systems and Software, 62(2), 85-96.         [ Links ]

Baños, G., Melendez, K., & Dávila, A. (12 de 2016). Prácticas adoptadas de la ISO/IEC 20000 en pequeñas organizaciones desarrolladoras de software que ofrecen mesa de servicios. Un estudio de caso. Revista Ibérica de Sistemas y Tecnologías de Información, 20(12), 1-17.         [ Links ]

Carvalho Cavalcanti Furtado, A., Wanderley Gomes, M., Carneiro Andrade, E., & Honório de Farias Junior, I. (2012). MPT.BR: A Brazilian Maturity Model for Testing. 12th International Conference on Quality Software. Xi'an, Shaanxi: IEEE.

Causevic, A., Sundmark, D., & Punnekkat, S. (2010). An Industrial Survey on Contemporary Aspects of Software Testing. 2010 Third International Conference on Software Testing, Verification and Validation (págs. 393 - 401). Paris: IEEE.

Clarke, P., & O’Connor, R. (2012). The situational factors that affect the software development process: Towards a comprehensive reference framework. Information and Software Technology, 54(5), 433-447.         [ Links ]

Dávila, A. (01 de Diciembre de 2013). Presentación. ProCal-ProSer. Recuperado el 14 de Marzo de 2015, de sitio web de ProCal-ProSer: https://sites.google.com/a/pucp.pe/procal-proser/         [ Links ]

Dávila, A., & Pessoa, M. (2015). Aplicación de 29110 en micro empresa. CLEI- Simposion (págs. 1-33). Aqp: SPC.

Dávila, A., & Pessoa, M. (2015). Factors driving the adoption of ISO/IEC 29110: A case study of a small software enterprise. Latin American Computing Conference (CLEI) (págs. 1 - 8). Arequipa, Peru: IEEE.

Dávila, A., Barsuto, C., Flores, L., Manrique, R., Arisaca, R., Sanchez, J., y otros. (2012). The peruvian component of Competisoft project: Lesson learned from academic perspective. En IEEE (Ed.), 2012 XXXVIII Conferencia Latinoamericana En Informatica (CLEI) (págs. 1 - 7). Medellín, Colombia: IEEE Conference.

Dyba, T. (2005). An empirical investigation of the key factors for success in software process improvement. IEEE Transactions on Software Engineering, 31(5), 410-424.         [ Links ]

García, C., Dávila, A., & Pessoa, M. (2014). Test Process Models: Systematic Literature Review. Communications in Computer and Information Science. 477, págs. 84-93. Vilnius, Lithuania: Springer.

Genero Bocco, M. F., Cruz-Lemus, J. A., & Piattini Velthuis, M. G. (2014). Métodos de Investigación en Ingeniería de Software (Primera ed.). Madrid, España: RA-MA.         [ Links ]

Hameed, M., Counsell, S., & Swift, S. (2012). A conceptual model for the process of IT innovation adoption in organizations. Journal of Engineering and Technology Management, 29(358-390).

ISO. (2016). ISO Web Site. Recuperado el 10 de 06 de 2016, de http://www.iso.org/iso/home.html        [ Links ]

ISO/IEC. (2003). ISO/IEC 15504-2:2003 Information technology - Process assessment - Part 2: Performing an assessment. Geneva, Switzerland: International Organization for Standarization.         [ Links ]

ISO/IEC. (2004). ISO/IEC 15504-1:2004 Information technology Process assessment Part 1: Concepts and vocabulary. Geneva, Switzerland: International Organization for Standardization.         [ Links ]

ISO/IEC. (2013). ISO/IEC/IEEE 29119-1:2013 Software and systems engineering - Software testing - Part 1: Concepts and definitions. Geneva, Switzerland: International Organization for Standardization.         [ Links ]

ISO/IEC. (2013). ISO/IEC/IEEE 29119-2:2013 Software and systems engineering - Software testing - Part 2: Test processes. Geneva, Switzerland: International Organization for Standardization.         [ Links ]

ISO/IEC. (2015). ISO/IEC 33002:2015 Information technology - Process assessment - Requirements for performing process assessment. Geneva, Switzerland: International Organization for Standardization.         [ Links ]

ISO/IEC. (2015). ISO/IEC FDIS 33063 Information technology - Process assessment - Process assessment model for software testing. Geneva, Switzerland: International Organization for Standardization.         [ Links ]

Kaner, C. (2006). Inefficiency and Ineffectiveness of Software Testing:A Key Problem in Software Engineering.         [ Links ] Washington DC: National Defense Industrial Association Workshop: Top 5 Software Engineering Problems or Issues Prevalent Within the Defense Industry.

Martin, D., Rooksby, J., Rouncefield, M., & Sommerville, I. (2007 ). ‘Good’ Organisational Reasons for ‘Bad’ Software Testing: An Ethnographic Study of Testing in a Small Software Company. ICSE '07 Proceedings of the 29th international conference on Software Engineering (págs. Pages 602-611 ). Washington, DC, USA: IEEE Computer Society.

Muñoz, M., Gasca, G., & Valtierra, C. (2014). Caracterizando las Necesidades de las Pymes para. Revista Ibérica de Sistemas y Tecnologías de Información, E1(03), 1-15.         [ Links ]

Myers, G. J. (1979). Art of Software Testing. New York, USA: John Wiley & Sons, Inc.         [ Links ]

Nayyar, I., & M. Rizwan, J. Q. (2013). Improvement of Key Problems of Software Testing In Quality Assurance. International Journal of Engineering Development and Research (IJEDR).

Niazi, M., Wilson, D., & Zowghi, D. (2006). Critical success factors for software process improvement implementation: an empirical study. Software Process: Improvement and Practice, 11(2), 193-211.         [ Links ]

Rainer, A., & Hall, T. (May de 2002). Key success factors for implementing software process improvement: a maturity-based analysis. Journal of Systems and Software, 62(2), 71-84.         [ Links ]

Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14(2), 131-164.         [ Links ]

Sanz, A., Saldaña, J., Garcia, J., & Gaitero, D. (Diciembre de 2008). TestPAI Un área de proceso de pruebas integrada con CMMI. Revista Española de Innovación, Calidad e Ingeniería del Software REICIS, Volumen 4(No 4).         [ Links ]

Simon, J.-M., Emam, K. E., Rousseau, S., Jacquet, E., & Babey, F. (1997). The Reliability of ISO/IEC PDTR 15504 Assessments. Software Process: Improvement and Practice, 3(3), 177-188.         [ Links ]

Sulayman, M., Mendes, E., Urquhart, C., Riaz, M., & Tempero, E. (2014). Towards a theoretical framework of SPI success factors for small and medium web companies. Information and Software Technolog, 56(7), 807-820.         [ Links ]

TMMI Foundation. (2009). Test Maturity Model Integration (TMMi) Version 2.0 . Ireland: TMMI Foundation.         [ Links ]

Vahid, G., & Junji, Z. (My de 2013). A survey of software testing practices in Canada. Journal of Systems and Software, Volume 86(Issue 5), págs. Pages 1354-1376.

Van Veenendaal, E., & Bath, G. (s.f.). Critical Success Factors for Test Process Improvement. Recuperado el 28 de 02 de 2017, de EuroStar Software Testing Conference: https://huddle.eurostarsoftwaretesting.com/

Vasconcelos, J. B., Kimble, C., Carreteiro, P., & Rocha, Á. (2017). The application of knowledge management to software evolution. International Journal of Information Management, 37(1), 1499-1506.         [ Links ]

Visser, B., de Vries, G., Linker, B., Wilhelmus, L., van Ewijk, A., & van Oosterwijk, M. (2013). TPI® NEXT - Business Driven Test Process Improvement (1 edition (November 17, 2009) ed.). UTN Publishers.         [ Links ]

Yuan-Hsin, T., & Tsenga, S.-S. (August de 2013). A novel approach to collaborative testing in a crowdsourcing environment. Journal of Systems and Software, Volume 86(Issue 8), págs. Pages 2143-2153.         [ Links ]

 

Agradecimientos

Este trabajo ha sido realizado dentro del proyecto ProCal-ProSer financiado por Innóvate Perú bajo el Contrato 210-FINCYT-IA-2013 y parcialmente soportado por el Departamento de Ingeniería y el Grupo de Investigación y Desarrollo de Ingeniería de Software (GIDIS) de la Pontificia Universidad Católica  del Perú.

 

Recebido/Submission: 24/03/2016

Aceitação/Acceptance: 24/04/2016

 

Apéndice A

 

Apéndice B