Documentos de Académico
Documentos de Profesional
Documentos de Cultura
1482-Article Text-3592-2-10-20170131 PDF
1482-Article Text-3592-2-10-20170131 PDF
http://dx.doi.org/10.16925/in.v12i20.1482
1
MsC. en Dirección Estratégica de Telecomunicaciones. Docente e investigador de la Facultad
de Ingeniería de Sistemas de la Universidad Cooperativa de Colombia, sede Popayán, Colombia
Correo electrónico: julian_mera_paz@campusucc.edu.co
Cómo citar este artículo: J. A. Mera-Paz, “Análisis del proceso de pruebas de calidad de software”, Ingeniería Solidaria,
vol. 12, no. 20, pp. 163-176, oct. 2016. doi: http://dx.doi.org/10.16925/in.v12i20.1482
BY NC ND
BY NC ND
Análisis del proceso de pruebas de calidad de software 165
3.5.3 Pruebas de sistema llevarse a cabo en todos los niveles de prueba” [29].
Hacen referencia al sistema como un todo; se Es importante mencionar que se orientan en el
debe elaborar un plan de pruebas de forma clara comportamiento externo de un producto o aplica-
y bien estructurada. Diseño de casos de pruebas: tivo software, en las pruebas de caja negra.
“Requisitos del usuario, requisitos del sistema,
casos de uso, procesos de negocio, informes de 3.6.2 Pruebas no funcionales
análisis de riesgo. Se deben tener en cuenta los Hacen referencia a las pruebas necesarias “para
objetos de prueba típicos: 1. Procesos de negocio medir las características de los sistemas y software
en sistema completamente integrado, 2. Procesos que pueden cuantificarse según una escala varia-
operativos y de mantenimiento, 3. Procedimientos ble [36]”. Se debe tener en cuenta que se orientan
de usuario, 4. Formularios, 5. Informes, 6. Datos de hacia el comportamiento externo del software y en
configuración”. [29] la mayoría de los casos utilizan técnicas de diseño
de pruebas de caja negra.
3.5.4 Pruebas de aceptación
Se enfocan en la aceptación de los criterios pre- 3.6.3 Pruebas estructurales
vistos en un contrato de desarrollo de software,
Pueden realizarse en todos los niveles de prueba.
acordado entre la fábrica de software y el cliente.
Son las más idóneas, después de las técnicas basa-
“Las pruebas de aceptación del sistema por parte
das en la especificación, “para ayudar a medir la
de los administradores del sistema, entre las que se
exhaustividad de las pruebas mediante una evalua-
incluyen” [34]:
ción de la cobertura de un tipo de estructura” [29].
Para todo proceso de pruebas se debe tener
3.5.5 Pruebas de backup / restauración claridad sobre la diferencia al clasificar los tipos
Recuperación de desastres; gestión de usuarios; de pruebas, esto contribuye a un análisis sólido del
tareas de mantenimiento; carga de datos y tareas plan de pruebas y a estructurar los casos de pruebas
de migración; comprobaciones periódicas de vul- y creación de la respectiva matriz; se tributa ade-
nerabilidades de seguridad; pruebas de aceptación más a la eficiencia en el proceso de calidad del pro-
contractual y normativa; pruebas alfa y beta. ducto software.
Es importante para aplicar el modelo V que se
tenga claro por parte de los probadores o tester la 3.7 Técnicas de prueba
definición de equivocación, defecto o falta y falla.
En la norma iso / iec / ieee 24765: 2010 se hace Se puede evidenciar en la figura 2 que existen varias
referencia a lo siguiente: técnicas de prueba, que se agrupan de la siguiente
“Equivocación (mistake): Acción del ser manera:
humano que produce un resultado incorrecto”. Agrupación Técnicas
“Defecto o falta (fault): Un paso, proceso o Técnicas de caja negra Partición de equivalencia
definición de dato incorrecto en un programa de Análisis del valor límite
computadora. El resultado de una equivocación Tablas de decisión
potencialmente origina una falla”. [28] Máquinas de estado finito
Grafo causa efecto
“Falla (failure): Resultado incorrecto, el resul- Prueba de dominios
tado de una falta”. Técnicas de caja blanca Basadas en el flujo de control
Basadas en el flujo de los datos
3.6 Clasificaciones de las pruebas Mutantes
Técnicas según quién Pruebas de aceptación
Según Whittaker [35], se propone clasificar hace la prueba Pruebas alfa y beta
Pruebas de usuario
las pruebas en funcionales, no funcionales y Pruebas en pares
estructurales. Técnicas basadas Prueba ad hoc
en la experiencia Conjetura de errores
3.6.1 Pruebas funcionales Testing exploratorio
3.8 Técnicas de caja negra Máquinas de estado finito: “Un sistema puede
tener distintas respuestas dependiendo de las con-
Partición de equivalencia: “Puede utilizarse para diciones actuales o de su estado. En ese caso, el sis-
lograr objetivos de cobertura de entrada y salida, tema se puede mostrar como máquinas de estado.
con entradas humanas, vía interfaces a un sistema, Esta forma de modelar permite ver el software en
o parámetros de interfaz de las pruebas de integra- términos de sus estados, las transiciones entre los
ción” [29]. En esta técnica es importante identificar estados, las entradas o los acontecimientos que dis-
las clases de equivalencia, por ejemplo, rango de paran el cambio de estado y las acciones que pue-
valores entre 1 y 10 serán las clases de equivalencia, den resultar de esas transiciones”. [29]
es decir que todo valor menor a 1 y todo valor mayor Grafo causa efecto: “Ayuda a seleccionar,
a 10 serán valores inválidos. Luego se generan los de una manera sistemática los casos de prueba.
casos de prueba con diferentes valores para asegu- Una causa es una condición de entrada o una clase
rar que la aplicación solo acepte valores entre 1 y 10. de equivalencia de las condiciones de la entrada.
Análisis de valor límite: “Las condiciones Un efecto es una condición de salida o una trans-
límite son situaciones en los bordes, por arriba, y formación del sistema”. [43]
por debajo de las clases de equivalencia para los Prueba de caso de uso: “Las pruebas pueden
valores de la entrada y de la salida” [37]. En esta derivarse de casos de uso. Un caso de uso des-
técnica se identifica la clase de equivalencia válida; cribe las interacciones entre los actores, incluyendo
por ejemplo, 0 <= J <= 10 000 si 0 es menor o igual usuarios y el sistema” [38]. Los casos de uso se pue-
que J, el numero – 1 no debería ser tomado por la den definir a nivel abstracto o a nivel del sistema.
aplicación, pero el numero 0 es igual a 0, por tanto Prueba de dominios: “Un dominio es un con-
debería ser un valor válido para la aplicación; si se junto que incluye todos los posibles valores de una
toma como dato de entrada 10 001 tampoco debe- variable para una función. En la prueba de domi-
ría tomarlo la aplicación ya que la variable J debe ser nio se identifican las variables y las funciones.
menor o igual que 10 000. Las variables pueden ser de entrada o de salida.
Tabla de decisión: “Las tablas de decisión Para cada una, se toman pocos valores representa-
representan relaciones lógicas entre las condiciones tivos de los posibles de la clase de equivalencia (típi-
y las acciones. Los casos de prueba son derivados camente casos bordes) para cada clase” [39].
sistemáticamente considerando cada combinación
posible de condiciones y acciones” [26]. Para el uso 3.9 Técnicas de caja blanca
de esta técnica se deben generar condiciones, accio-
nes y reglas para estas. Se basan en una estructura identificada del soft-
ware o del sistema, según unos niveles específicos.
• Condiciones: todas las situaciones que puedan Niveles: “Nivel de componente: estructura
presentarse. de un componente software. Ejemplos: sentencias,
• Reglas de las condiciones: indican el valor que decisiones, caminos distintos.
debe asociarse a cada condición. Nivel de integración: la estructura se basa
• Acciones: lista del conjunto de los pasos por se- en un árbol de llamadas, diagrama en el que un
guir cuando se presente una condición. módulo llama a los otros módulos.
• Reglas de acciones: muestran las acciones espe- Nivel de sistema: la estructura puede ser
cíficas del conjunto que deben emprenderse da- por menús, ejemplo: proceso de negocio, páginas
dos los valores que toman las condiciones. web” [29].
Basadas en el flujo de control: “Se cubren todas
Como ejemplo se tiene: las sentencias o bloques de sentencias en un pro-
grama, o combinaciones especificadas de ellas.
• Condición: cliente de la empresa La adecuación de tales pruebas se mide en por-
• Regla de la condición: sí es cliente – no es cliente centajes; por ejemplo, se dice haber alcanzado una
• Acción: aplicar factura con descuento cobertura de sentencia del 100 % cuando las senten-
• Regla de la acción: será las n veces que la acción cias han sido ejecutadas por lo menos una vez por
se adapte a la condición las pruebas” [46].
172 Artículos de reflexión Ingeniería Solidaria / Volumen 12, Número 20 / octubre 2016
Basadas en el flujo de los datos: “El criterio Conjetura de errores: “La idea básica es enu-
más fuerte, all definition-use, requiere que para merar una lista de errores y después escribir los
cada variable, cada segmento de la trayectoria del casos de prueba basados en la lista. Otra idea es
flujo de control desde una definición de esa variable identificar los casos de prueba asociados a asuncio-
hasta su uso sea ejecutado. Para reducir el número nes que el programador pudo haber hecho cuando
de las trayectorias requeridas se utilizan estrategias leía la especificación” [26].
más débiles como all-definitions” [29]. Testing exploratorio: el término fue introdu-
Pruebas mutantes: “Un mutante es una ver- cido por Kaner, y se trata de “ejecutar las pruebas a
sión levemente modificada del programa a pro- medida que se piensa en ellas, sin gastar demasiado
bar, diferenciado de él por un cambio sintáctico tiempo en preparar o explicar las pruebas, con-
pequeño. Puede ser usado para evaluar un conjunto fiando en los instintos. Se define como el aprendi-
de prueba o criterio de prueba en sí mismo. Para zaje, el diseño de casos de prueba y la ejecución de
que la técnica sea eficaz, se deben derivar automá- las pruebas en forma simultánea” [40].
ticamente de manera sistemática gran cantidad de
mutantes” [26].
Técnicas según quien hace la prueba: existen 4. Resultados
algunas técnicas de prueba que dependen de quién
realiza las pruebas; este es el caso de las pruebas de Por la naturaleza del artículo, la discusión de los
aceptación, las alfa y beta, las de usuario y las prue- resultados se fundamenta en referencias bibliográ-
bas en pares [40]. ficas, es decir, lo que aparece detallado constituye
Pruebas de aceptación: “Es el proceso de un marco teórico, que fundamenta una guía teó-
comparar el programa contra sus requerimientos rica para que las empresas de desarrollo de software
iniciales y las necesidades reales de los usuarios. y universidades adapten los conceptos a la imple-
Realizado generalmente por el cliente o el usuario mentación del proceso de pruebas. Se debe tener en
final”. cuenta que los procesos de pruebas se desarrollan
Pruebas alfa y beta: “Antes de que el soft- por personas, son susceptibles a errores y por eso se
ware se libere, se distribuye a un pequeño grupo deben reforzar bibliográficamente.
representativo de los usuarios potenciales para el Como lo plantean Banerjee, Chattopadhyay
uso interno (alfa) o externo (beta). Estos usuarios y Roychoudhury [41], en el capítulo 3 del libro
reportan problemas con el producto”. Los avances en informática: “Para las últimas
Prueba de usuarios: “Es la prueba realizada décadas, los sistemas integrados han ampliado su
por el tipo de persona que usará el producto. Puede alcance en los principales aspectos de las vidas
ser realizado en cualquier momento durante el humanas. A partir de pequeños dispositivos por-
desarrollo, en el lugar del cliente o en el de desarro- tátiles (teléfonos inteligentes), como a los sistemas
llo, en ejercicios completamente dirigidos o a la dis- de automoción avanzadas (como los sistemas anti-
creción del usuario”. bloqueo de frenos), el uso de sistemas embebidos
Prueba en pares: “Consiste en que dos tester ha aumentado a un ritmo dramático. El software
trabajan juntos para encontrar errores. Comparten integrado se especializó en software que se pretende
una computadora e intercambian el control de la que funcione en dispositivos embebidos. Además,
misma mientras prueban” [26]. los sistemas embebidos a menudo se requieren
Técnicas basadas en la experiencia: existen para operar en la interacción con el medio físico, la
técnicas de prueba que se basan en la intuición, obtención de los componentes a factores ambienta-
el conocimiento o la experiencia de la persona que les (tales como la temperatura o la presión del aire).
realiza las pruebas. La necesidad de interactuar con un entorno físico
Pruebas ad hoc: “Quizás la técnica más prac- dinámico, a menudo no determinista, aumenta aún
ticada, las pruebas son derivadas confiando en la más los problemas asociados con las pruebas y vali-
habilidad, intuición, y experiencia con programas dación de software embebido”. Se demuestra una
similares. Puede ser útil para identificar pruebas vez más que es una necesidad vital enfocarse en los
que no son fácilmente encontradas por técnicas procesos de pruebas de calidad de software, ya que
más formales” [26]. los sistemas están en la mayoría de los dispositivos
Análisis del proceso de pruebas de calidad de software 173
tecnológicos y muchos de ellos están presentes en para el desarrollo de software móvil y la implemen-
las actividades humanas; por ende, el proceso de tación de un laboratorio para prácticas de estu-
calidad debe ser sólido. dio e investigación en la facultad de Ingenierías,
Las empresas y universidades han descuidado de la Universidad Cooperativa de Colombia, sede
el proceso de pruebas de calidad de software y la Popayán.
esencia e importancia de la afectación en las activi-
dades cotidianas. Un adecuado proceso de pruebas
de calidad de software mitiga la generación de ries- 5. Discusión
gos, más cuando hoy se habla de la implicación de
software en procesos tan críticos como las cirugías Se evidencia que hay un gran número de temáti-
o procedimientos de diagnóstico médico. cas y terminología sobre el proceso de pruebas de
Es primordial recordar que los productos de calidad de software pero es poca la valoración que
desarrollo software y los casos de prueba son elabo- se le está haciendo a la importancia e impacto en
rados por seres humanos y que se pueden presen- las fábricas o empresas de software y en la acade-
tar equivocaciones; por lo tanto, es útil conocer la mia. Con este artículo se analiza la importancia del
información y el proceso de pruebas de calidad de proceso de pruebas de calidad de software con la
software, para que dentro del ciclo de producción se finalidad de que estas apunten a mejorar el rendi-
establezcan las instrucciones, roles y responsabili- miento, efectividad y optimización en la calidad de
dades de forma clara. los productos software.
El equipo de desarrollo o producción debe Este artículo tributa a los equipos de desarro-
tener claras las condiciones de funcionabilidad y llo software, con el fin de que se les entregue una
usabilidad del producto software; además, es reco- valoración importante a las pruebas de calidad y se
mendable realizar comparaciones con otros pro- conozca el estado del producto en cuanto a faltas o
yectos o módulos desarrollados, no con el objetivo defectos encontrados, y una comparación entre las
de medir la efectividad laboral, sino para tener refe- etapas o avances del proyecto o, si es posible, res-
rentes en la estructura, la organización, los tiempos pecto a otros proyectos. De esta manera, se busca
y la calidad. consolidar unos niveles altos de calidad y optimi-
El director o gerente del proyecto debe estar zar recursos. Se ayuda al director y otros responsa-
centrado en que los clientes buscan productos que bles del proyecto. Además, se puede dimensionar
satisfagan sus necesidades, y la calidad es el factor la importancia del proceso de pruebas de calidad,
principal; por eso se tienen que seguir unos prin- para con ello estructurar de forma adecuada tiem-
cipios y clasificaciones, que a través de un plan de pos, roles, responsabilidades y asignaciones que lle-
pruebas, sean guía para el equipo de desarrollo, y ven a un software de calidad.
que este realice una optimización de las herramien- Elaborar procesos de pruebas de calidad de
tas, técnicas y conocimientos. software sin un orden definido o sin conocimiento
Al cliente como elemento valioso de todo pro- previo no es recomendable, ya que va a dificultar la
yecto se le involucra en el proceso de pruebas de comprobación de la funcionabilidad y usabilidad de
calidad, para que esté enterado de los avances, para un producto de desarrollo software. Se podría argu-
que conozca los posibles fallos y qué no es un fallo; mentar que la finalidad de la calidad va a ser el uso y
asimismo, para que tenga los medios para reportar el contexto de este que le brinde el cliente o usuario
los fallos. Es importante que en esa relación con el final, pero ello se puede refutar, ya que quien desa-
cliente el equipo de desarrollo y el gerente del pro- rrolla el producto puede tener una concepción dife-
yecto transmitan seguridad y franqueza, aspecto rente y argumentada sobre el funcionamiento de
que permitirá tener un cliente satisfecho y una ima- un producto software, como el rendimiento, capa-
gen corporativa sólida. cidad de almacenamiento, etc.
En este artículo se evidencia que hay un Como lo mencionaron Mota, Carmo,
camino por recorrer y gran cantidad de infor- Mcgre gor, Santana y Romero, “en el desarrollo
mación y temáticas que se derivan del proceso de de software, la prueba es un mecanismo impor-
pruebas de software. Como trabajo futuro se plan- tante tanto para identificar defectos y asegurar
tea el estudio de pruebas de calidad de software que los productos bajo la conformidad con las
174 Artículos de reflexión Ingeniería Solidaria / Volumen 12, Número 20 / octubre 2016
especificaciones. Esta es una práctica común en colaboren con la actualización y mejora continua
el desarrollo de un solo sistema” [42]. Así pues, se de un proceso de pruebas de calidad de software.
puede ahondar más en el tema de las pruebas como
un factor de identificación de defectos, ya que este
artículo apunta a la importancia de pruebas de cali- 6. Conclusiones
dad de software con un enfoque hacia el asegura-
miento de esa calidad. Se observa que el proceso de pruebas impacta en
Varios de los autores seleccionados en este los riesgos del producto software; por ende, para las
artículo mencionan, de diferentes formas, que no empresas de software es vital formular y adecuar
existe una calidad perfecta o absoluta, y esto se un buen proceso de pruebas de calidad de software.
determina por los principios de las pruebas de soft- La mayoría de las universidades en Latinoamé
ware; por tanto, es recomendable que los equipos de rica han estado aisladas en cuanto a la imple-
desarrollo sustenten sus pruebas en observaciones mentación de pruebas de calidad de software y la
dadas por la programación entre pares, las expe- generación de espacios de laboratorio para el desa-
riencias adquiridas y las apreciaciones del cliente. rrollo de técnicas, métricas, indagaciones e inves-
Con ello se puede acercar a una calidad óptima, tigación en las áreas de informática, sistemas o
adecuada al contexto funcional. afines, que permitan afianzar el aseguramiento de
Como especifica Kuhn en su artículo: la calidad de los productos software.
“Investigamos informes de error de dos proyectos Este artículo describe un resumen del aná-
de software de código abierto grandes, un navega- lisis de la importancia del proceso de pruebas de
dor y el servidor web, para proporcionar respues- calidad de software, como guía de estudio y análi-
tas preliminares a tres preguntas: ¿Hay un punto sis para equipos de desarrollo software, directores y
de rendimientos decrecientes en el que la genera- responsables de proyectos, clientes y usuarios fina-
ción de todas las combinaciones de grado n es casi les, docentes y estudiantes, demás comunidad inte-
tan eficaz como las n + combinaciones de 1 grado? resada para implementar, revisar y consolidar un
¿Cuál es el valor apropiado de n para clases particu- adecuado proceso de pruebas de calidad software.
lares de software? ¿Este valor difiere para diferentes Con la claridad de la importancia del proceso
tipos de software, y por cuánto? Nuestros hallazgos de pruebas de calidad en los productos software se
sugieren que más del 95 % de los errores en el soft- eleva la calidad y fiabilidad dentro del ciclo de vida
ware estudiado serían detectados por los casos de de un proyecto. Asimismo, al implementar un pro-
prueba que cubren todas las combinaciones de 4 ceso de pruebas de calidad de software se genera un
vías de valores, y que el software del navegador y el control y seguimiento a los defectos o faltas y a los
servidor fueron similares en el porcentaje de errores fallos, de manera que las soluciones que se generen
detectables por combinaciones de grado 2 a 6” [43]. tengan un mayor nivel de calidad.
Por otro lado, en el caso planteado, se evi- Es importante que los diferentes roles en una
dencia que un 95 % de los errores fueron detecta- empresa de desarrollo software o en un equipo de
dos gracias a los casos de prueba, lo que respalda trabajo tengan un conocimiento básico sobre el
que con este artículo se coadyuva a los potenciales proceso de pruebas de calidad. Esto permite que
clientes y usuarios finales, ya que son estos en reali- en cada etapa del ciclo del proyecto se manejen
dad los que interactúan con los productos software, mejores estándares de producción y por ende de
pues ellos son los que detectan en su mayoría los calidad.
defectos y pueden dar su percepción de los resul- En un sentido general, la implementación de
tados de las pruebas finales, que ya es la puesta en un proceso de pruebas de calidad de software en las
producción de un producto software. empresas o universidades instituye un gran avance
Los docentes, estudiantes, investigadores, en el intento por garantizar márgenes de calidad en
empresas de desarrollo software y comunidad inte- los productos de desarrollo software, y es un ele-
resada podrán, a través de este artículo, iniciar pro- mento estratégico para la imagen corporativa o
cesos de ejercicio académico y de investigación que institucional.
Análisis del proceso de pruebas de calidad de software 175
grado enfocados al desarrollo de software de la insti- [32] D. R. Kuhn, D. R. Wallace y A. M. Gallo, “Software
tución universitaria colegio mayor del Cauca”, Tesis Fault Interactions and Implications for Software Tes-
de grado, Prog. Ing. Infor., Institución Universitaria ting”, en: ieee Transactions On Software Engineering,
Colegio Mayor del Cauca, Colombia, 2009 [docu- Vol. 30, no. 6, pp. 418-421, junio 2004 [en línea].
mento impreso]. doi: http://doi.ieeecomputersociety.org/10.1109/
[22] C. Pardo, J. A. Hurtado y C. A. Collazos, “Mejora TSE.2004.24
de procesos de software ágil con Agile spi Process”, [33] Sh. Lawrence Pfleeger y J. M. Atlee, Software Engin-
Revista dyna, vol. 77, n.º 1 164, pp. 251-263, dic. nering. Estados Unidos: Pearson; 2009.
2010. Disponible en: http://www.revistas.unal.edu. [34] M. G. Merayo y E. Montes de Oca, “Testing Softwa-
co/index.php/dyna/article/view/25595 re and Systems”, en: International Conference, ictss
[23] A. Bertolino, “Software Testing Research: Achieve- 2014, Madrid, España, 23-25, septiembre 2014 [en
ments, Challenges, Dreams”, en Future of Software línea]. Disponible en: http://www.springer.com/la/
Engineering. L. Briand y A. Wolf, Eds. Washing- book/9783662448564#
ton: ieee Computer Society, 2007, pp. 85-103 [en [35] J. Whittaker, “What is Software Testing? And Why Is
línea]. Disponible en: http://dl.acm.org/citation. It so hard?”, ieee Software, vol. 17, no. 1, pp. 70-79,
cfm?id=1254712 ene.-feb., 2000. doi: 10.1109/52.819971
[24] B. Hetzel, The Complete Guide to Software Testing,
[36] ieee, “Software Engineering. Product quality. Part
Estados Unidos: John Wiley & Sons; 1993.
1: Quality Model”, iso/iec 9126-1:2001. 2001 [en
[25] E. W. Dijkstra, “Notes on Structures Programming”, línea]. Disponible en: http://www.iso.org/iso/cata-
Technical University Eindhoven, The Netherlands, logue_detail.htm?csnumber=22749
departamento de Matemáticas, Technical Report
[37] Myers G, T. Badgett y C. Sanders, The art of software
70-WSK-03 1970, pp. 15-64 [en línea]. Disponible
testing. New Jersey, Estados Unidos: John Wiley &
en: https://www.cs.utexas.edu/users/EWD/ew-
Sons Inc., 2004, p. 254.
d02xx/EWD249.PDF
[26] ieee Computer Society, “Guide to the Software En- [38] I. Jacobson, G. Booch y J. Rumbaugh, The Unified
gineering Body of Knowledge Swebok”, ieee Com- Software Development Process”. Boston, Estados
puter Society, pp. 10-40, 2004 [en línea]. Disponible Unidos: Addison Wesley, 1999, pp. 185-190.
en: https://www.computer.org/web/swebok/v3 [39] C. Kaner, J. Bach J. y B. Pretichord, Lessons Learned
[27] International Software Testing Qualifications Board in Software Testing, Wiley & Sons Inc, 2001.
[istqb], “Oficinas principals”, pp. 28-40, 2011. Bru- [40] C. Kaner, J. Falk y H. Nuyen. Testing Computer
selas, Bélgica [en línea]. Disponible en: http://www. Software. Nueva York, Estados Unidos: 1999, p.
istqb.org/downloads/category/2-foundation-le- 286. [en línea]. Disponible en: http://www.ama-
vel-documents.html zon.com/Testing-Computer-Software-2nd-Kaner/
[28] ieee Explore, 24765-Systems and software enginee- dp/0471358460
ring. Vocabulary, 2010 [en línea]. doi: 10.1109/IEE- [41] A. Banerjee, S. Chattopadhyay y A. Roychoudhury,
ESTD.2010.5733835 “On Testing Embedded Software”, Advances in Com-
[29] T. Müller, Libro Programa de Estudio de Nivel Bási- puters, vol. 101, pp. 121-153, 2016 [en línea]. Dis-
co para Probador Certificado, istqb, Version 2013, ponible en: http://www.sciencedirect.com/science/
p. 14. Disponible en: http://www.istqb.org/down- article/pii/S0065245815000662. doi: 10.1016/bs.ad-
loads/send/2-foundation-level-documents/3-foun- com.2015.11.005
dation-level-syllabus-2011.html4 [42] P. A. da Mota Silveira Neto, I. do Carmo Machado,
[30] International Software Testing Qualifications Board J. D. McGregor, E. Santana de Almeida y S. R. de Le-
[istqb], “Certified Tester Foundation Level Sylla- mos Meira, “A Systematic Mapping Study of Softwa-
bus. Released version 2013”, 2013 [en línea]. Dispo- re Product Lines Testing”, Information and Software
nible en: http://www.istqb.org/downloads/syllabi/ Technology, vol. 53, no. 5, pp. 407-423, may. 2011
foundation-level-syllabus.html [en línea]. Disponible en: http://www.sciencedirect.
[31] International Software Testing Qualifications Board com/science/article/pii/S0950584910002193. doi:
[istqb], “Certified Tester Foundation Level Syllabus. 10.1016/j.infsof.2010.12.003
Released version 2011”, 2011 [en línea]. Disponible [43] D. R. Kuhn y M. J. Reilly, “Una investigación de la
en: http://www.istqb.org/downloads/send/2-foun- aplicabilidad de diseño de experimentos para prue-
dation-level-documents/3-foundation-level-sylla- bas de software”, Software Ingeniería Taller. Actas 27,
bus-2011.html4 Anual de la nasa Goddard / ieee, 2002, pp. 91-95.