INTRODUCCIÓN INGENIERÍA DE PRUEBAS DE

SOFTWARE

Carlos Fernando Arenas

Ingeniería de Sistemas
Electiva IV
2023-01
Agenda
1. Ejercicio preliminar
2. Introducción de las pruebas de software
3. Historia de las pruebas de software
4. Aplicación profesional de las pruebas de software
5. Ejercicio final
Ejercicio preliminar
 Ejercicio preliminar
• 27 de agosto de 2018. Una mujer cruzaba a pie con una
bicicleta una calle de la localidad de Tempe, Arizona, y
fue atropellada por un vehículo autónomo de Uber.
• Los sistemas del coche, cuya conductora de respaldo en
ese momento estaba distraída mirando un programa de
televisión en su móvil, detectaron a la peatón 5,6
segundos antes del choque pero no detuvieron el
vehículo ya que no pudieron determinar si era un
ciclista, un peatón o un objeto desconocido, o si se
dirigía hacia el camino del vehículo.
• Este accidente obligó a Uber y a otras empresas a frenar
lo que había sido una rápida marcha hacia los servicios
autónomos de transporte en las carreteras públicas.
 Ejercicio preliminar (2)
• Determine quien tiene responsabilidad en el
accidente:
• La conductora de respaldo
• La peaton/ciclista
• Uber
• El gobierno de EEUU
• Otro
 Ejercicio preliminar (3)
• Si seleccionó como respuesta “Otro” mencione
a quien considera como responsable.

• ¿Será que el software de conducción

autónoma tendrá que ver con este accidente?
¿Si es así quien debe asumir la responsabilidad
por el software?

• ¿De ser así que cree que se hubiese podido

hacer para evitar este tipo de accidentes?
Introducción a las pruebas de software
De donde vienen los problemas en el
software?
• La gente comete errores los cuales crean defectos en
el sistema:
• Requisitos y especificaciones de diseño
• Código (lógica de negocios e interfaz de usuario)
• Documentación (electrónica e impresa)
• Cuando un código defectuoso es ejecutado ocurren
fallas
• Si estas fallas son visibles a los clientes, usuarios u
otros interesados, podrían resultar en insatisfacción
con la calidad del sistema
De donde vienen los problemas en el
software? (2)
• En un proyecto de desarrollo de software los errores
puede presentarse en cualquiera de las etapas del
ciclo de vida del software
• Aún cuando se intente detectarlos después de cada
fase utilizando técnicas como la inspección, algunos
errores permanecen sin ser descubiertos.
• Por lo tanto es muy probable que el código final
contenga errores de requerimientos y diseño,
adicionales a los introducidos en la codificación
De que forma podría definir las pruebas
de SW?
Qué son las pruebas de SW?
• El proceso consistente en demostrar que el sistema no presenta
errores
• El proceso de verificar que el programa hace lo que debería
hacer
• “Las pruebas de Software (Software Testing) son el proceso de
evaluar un Sistema o Componente de un Sistema de forma
manual o automática para verificar que satisface los requisitos
esperados, o para identificar diferencias entre los Resultados
esperados y los reales.” (IEEE)
• “el testing de software puede probar la presencia de errores
pero no la ausencia de ellos” (Dijkstra)
• Las pruebas de software fracasan cuando NO se encuentra
Qué son las pruebas de SW? (2)
• Prueba es una actividad realizada para evaluar la calidad
del producto y mejorarla, identificando defectos y
problemas.
• La prueba de software (testing) es la verificación dinámica
del comportamiento de un programa contra el
comportamiento esperado, usando un conjunto finito de
casos de prueba, seleccionados de manera adecuada
desde el dominio infinito de ejecución.
Qué aportan las pruebas de SW?
• Calidad durante todo el proceso
• Disminución de costos
• Reducción de riesgos
• Optimización de recursos
• El seguimiento de estándares
• En síntesis Aumentar, administrar y monitorear la calidad de
los entregables del producto y el proceso del desarrollo de
software
Historia de las pruebas de software
 Evolución de las pruebas de SW
Debugging Destrucción

(1947/56 (1957/58 (1979/82 (1983/84 (1985/HOY

) ) ) ) ) Prevención

Demostración Evaluación
Debugging: Origen de los “bugs” y su
depuración
• En 1947, se acuñan los términos “bug” y
“debugging”. Grace Murray Hopper, una
científica de la universidad de Harvard que
trabajaba con la computadora Mark II, detectó
que una polilla se había quedado pegada en un
relé provocando que éste no hiciera contacto. Es
por esto que el 9 de septiembre (fecha en la que
ocurrió este hecho) ha sido nombrado el Día
internacional del Tester de Software
• Detalló el incidente en la bitácora de trabajo,
pegando la polilla con cinta adhesiva como
evidencia y refiriéndose a la polilla como el “bug”
(bicho) causante del error, y a la acción de
eliminar el error como “debugging”.
Periodo de debugging
• Las pruebas que se realizaban estaban
enfocadas en el hardware debido a que no
estaba tan desarrollado como hoy en día y su
fiabilidad era imprescindible para el correcto
funcionamiento del software.
• El término debugging estaba asociado a la
aplicación de un parche para un determinado
fallo como fase dentro de la etapa de desarrollo
del software, y es por ello por lo que las pruebas
que se realizaban eran únicamente de índole
correctiva tomando ciertas medidas con el
propósito de hacer funcionar el programa.
Periodo de debugging: Turing test
• En 1949 cuando Alan Turing escribe su primer
artículo acerca de realizar comprobaciones sobre un
programa y después en 1950, en el artículo “Turing
test”, expone la situación de cómo un software debe
adaptarse a los requisitos de un proyecto y el
comportamiento de una máquina o un sistema de
referencia (lógica humana) debe ser indistinguible.
• El objetivo de este experimento es determinar si la
inteligencia artificial puede imitar las respuestas
humanas. Por ello, el humano hace preguntas tanto a
la otra persona como al computador y si no puede
identificar si alguno de los dos sujetos es o no una
máquina, la computadora pasa con éxito la prueba
de Turing.
Periodo de demostración
• En 1957, Charles Baker expone la necesidad de desarrollar pruebas que garanticen
que el software satisface los requisitos prediseñados (testing) además de la
funcionalidad del programa (debugging).
• El desarrollo de pruebas adquirió mayor importancia debido a que cada más
aplicaciones, más caras y complejas estaban siendo desarrolladas, y se puso especial
foco en aumento del número y la calidad de pruebas, y por primera vez se empezó a
relacionar la calidad de un producto con el estado de la fase de testing.
• El objetivo era demostrar que el programa hacía lo que anteriormente se había dicho
que debía hacer, usando parámetros esperados y reconocibles.
• Pero esta estrategia no funcionó, debido a que aumentó la probabilidad de que una
funcionalidad del software fallará a medida que se hacían más pruebas. Es decir,
entre más pruebas, más probable era que encontraras un bug.
Periodo de destrucción
• En 1979, Glenford J. Myers, con la definición que leíste al comienzo de este capítulo, cambia
radicalmente el procedimiento para la detección de fallos en el programa. Por lo anterior acuñó
la siguiente frase:
• “Las pruebas de software son el proceso de ejecutar un programa con la intención de encontrar
errores” — Glenford J. Myers.
• La tesis de Mryes se basaba en que al tratar de demostrar que un programa funcionaba, uno
podría inconscientemente seleccionar los datos de prueba con la menor probabilidad de causar
fallas en el programa.
• Mientras que, si el objetivo es demostrar que el programa es defectuoso, ibas a elegir datos de
prueba con una mayor probabilidad de lograr que el programa falle, y por tanto tendríamos más
éxito en las pruebas de software y en consecuencia en la calidad del software.
• Sin embargo, el enfoque orientado a la destrucción también falló porque el software nunca se
lograría lanzar si estamos encontrando un error tras otro. Sin contar con, que corregir un error
también podría conducir a otro error.
Periodo de evaluación
• En 1979, Glenford J. Myers, con la definición que leíste al comienzo de este capítulo, cambia
radicalmente el procedimiento para la detección de fallos en el programa. Por lo anterior acuñó
la siguiente frase:
• “Las pruebas de software son el proceso de ejecutar un programa con la intención de encontrar
errores” — Glenford J. Myers.
• La tesis de Mryes se basaba en que al tratar de demostrar que un programa funcionaba, uno
podría inconscientemente seleccionar los datos de prueba con la menor probabilidad de causar
fallas en el programa.
• Mientras que, si el objetivo es demostrar que el programa es defectuoso, ibas a elegir datos de
prueba con una mayor probabilidad de lograr que el programa falle, y por tanto tendríamos más
éxito en las pruebas de software y en consecuencia en la calidad del software.
• Sin embargo, el enfoque orientado a la destrucción también falló porque el software nunca se
lograría lanzar si estamos encontrando un error tras otro. Sin contar con, que corregir un error
también podría conducir a otro error.
Periodo de prevención
• En 1988, William Hetzel publicó un libro llamado “El crecimiento de las pruebas de software” en
el que redefinió el software testing como: la planeación, diseño, construcción, mantenimiento y
ejecución de pruebas de software con sus respectivos entornos de prueba.
• La revolución más evidente de este concepto se dio en la inclusión de las pruebas de software
desde la etapa más temprana de la elaboración de un producto de software, es decir, desde su
planeación.
• Finalizando nuestro viaje por el tiempo, en el principio de los 2000, se volvieron populares
terminos como: test driven development (TDD), o behavioural driven development (BDD) que son
metodologías de desarrollo de software en donde las pruebas de software, aparte de aparecer
desde las primeras etapas, adquieren un protagonismo especial durante todo el ciclo de vida del
producto de software.
• En los últimos años las pruebas de software han sido potenciadas con herramientas de
automatización que han ganado aceptación, e incluso comienzan a conocerse prácticas en las
que se hace uso de herramientas inteligencia artificial para aumentar su eficiencia.
Aplicación profesional de las pruebas de
software
Pruebas de software a nivel global
• Los sistemas y las aplicaciones son
fundamentales para las operaciones
comerciales, y es el trabajo de los
ingenieros, desarrolladores y evaluadores
de software garantizar que funcionen según
lo previsto.
• Las Mercado de pruebas de software se
valoró en más de USD 40 mil millones en
2020, y se espera que aumente a una tasa
de más del 7% para 2027.
• Inteligencia artificial, máquina de
aprendizaje, y CI/CD para el sector de TI
impulsarán el crecimiento de las pruebas de
software.
Pruebas de software a nivel Colombia
• De acuerdo con el estudio de brechas de capital
humano entorno de las competencias del sector
TIC de 2020, Las ocupaciones tradicionales de
procesos, proyectos, datos, aplicativos e
infraestructura como áreas de soporte están
volcándose a ocupaciones más integrales en
términos de relacionamiento y entendimiento del
negocio en toda la cadena de valor, el análisis
diagnóstico, predictivo y prescriptivo de
información.
• Nótese que aunque de manera incipiente aun tanto
la calidad del software como las pruebas ya se
reconocen como parte de los recursos Áreas o posiciones de recursos TIC que más demandan recursos en Colombia
especializados que se demandan en el Sector TIC Fuente: Estudio de brechas de capital humano entorno a las competencias del
sector TIC con enfoque en la explotación de datos, 2020.
en Colombia
Profesionalización de las pruebas de
software
• En el mundo se ha disparado la demanda de técnicos dedicados a hacer pruebas de Software.
• Hay un mercado creciente de oportunidades para el control de calidad del software, pero la
gente que lo realiza siendo perteneciendo a un segmento donde no existen muchas
oportunidades de profesionalización formal.
• La academia forma programadores, analistas de sistemas, jefes de proyecto, técnicos de
infraestructura, pero no Analistas de pruebas de software. La mayoría de quienes trabajan en
esta disciplina no poseen acreditaciones formales y sólo cuentan con el aporte su experiencia y
capacidad autodidacta como herramientas en el mercado laboral.
• El control de la calidad del software es una actividad que debe ser metódica, profesional y
eficiente para que cumpla su objetivo y aporte el valor que de ella se espera como parte de un
proceso de ingeniería.
Principales organizaciones certificadoras de
pruebas de software y sus certificaciones
• International Software Testing Qualifications Board (ISQTB)
• Nivel de fundamentos (Foundation).
• Nivel avanzado (Advanced) con 3 opciones de especialización: Test Manager, Test Analyst,
Technical Test Analyst.
• Nivel experto con 4 opciones de especialización: Improving Test Process, Test Management, Test
Automation, Security Testing.
• IIST (International Institute for Software Testing):
• Certified Software Test Professional (Associate, Practitioner, Master Levels).
• Certified Agile Software Test Professional.
• Certified Test Manager.
• Certified Software Quality Manager.
• Certified Software Test Automation Specialist.
• American Society for Quality (ASQ)
• CSQE (Certified Software Quality Engineer)
Principales organizaciones certificadoras
de pruebas de software (2)
• iSQI (International Software Quality Institute)
• CAT Certified Agile Tester (Foundation Level y Advanced Level)
• QAMP Quality Assurance Management Professional
• TTCN-3 Testing and Test Control Notation
• Certified V-Model XT Project and QA Manager
• British Computer Society / Information Systems Examinations Board (BCS/ISEB)
• Foundation, Advanced, Expert (en alianza con ISTQB)
• Intermediate Certificate in Software Testing.
• Certified Agile Tester (en alianza ISQI)
• TMap (Test Management Approach)
• TMAP NEXT Test Engineer
• TMAP NEXT Test Manager
Ejercicio final
Ejercicio final
• Realice el test visual de Turing que
está en el siguiente link:
https://umhsapiens.com/eres-un-
robot-aprueba-el-test-de-turing/
• Comparta con la clase su calificación,
para saber si es o no humano.
Actividad adicional
Actividad adicional
• Para la clase de mañana jueves por
favor haber leído el documento
disponible en la pestaña denominado
“Fundamentos de pruebas ISTQB –
Capítulo 1 y 2”.
• De igual manera agradezco investigar
por su cuenta las siguientes
temáticas que vamos a discutir el día
de mañana:
• Error, defecto y fallo
• Calidad en el software
• Definiciones relacionadas con las
pruebas
• Principios del proceso de pruebas
de software
 Referencias bibliográficas
• Carretero, J. et. Al. Sistemas operativos. Una visión aplicada. McGrawHill
• Tanenbaum, A. Sistemas operativos modernos. 3era Edición. Prentice Hall
• Silberschatz, A. Sistemas operativos. Addison-Wesley
• Stallings, W. Sistemas operativos. Prentice Hall
• Deitel, H. Sistemas operativos. Addison-Wesley
• Milenkovic, Milan. Sistemas operativos, conceptos y diseño. McGrawHill
• Tanenbaum, A. Sistemas operativos, diseño e implementación. Prentice Hall