sistema erp: módulo de captación forcast, … · sistema erp: módulo de captación forcast,...
TRANSCRIPT
UNIVERSIDAD TECNOLÓGICA DE IZÚCAR DE MATAMOROS
Programa Educativo de Tecnologías de la Información y Comunicación
Sistema ERP: Módulo de captación Forcast,
cotizaciones, ventas y generación de contratos
Tesis que para obtener el Grado de
Ingeniero en Tecnologías de la Información
Presenta:
Yuridia Luna Marcos 11292094
Izúcar de Matamoros, Puebla, México. Fecha: Mayo 2015
DEDICATORIA
Quiero dedicar mi trabajo, esfuerzo y empeño expuesto en esta tesis a las personas que
me han apoyado siempre compañeros, amigos, maestros, a quienes me dieron la
confianza para seguir estudiando, quienes me alentaban a no flaquear por más difícil que
a veces se pusiera el camino, pero principalmente:
A mis padres Faustina Marcos Santos y Mauro Gómez Gracia
Gracias por el apoyo que me han brindado en todos los sentidos, pero más por la
paciencia, confianza, consejos, regaños y por querer siempre lo mejor para mí, muchas
veces se duda cuando se tienen motivos para hacerlo, pero espero haberles demostrado
que sí se podía y que sí puede.
A mis hermanas Renata Rescalvo Marcos, Yazmin Rescalvo Marcos y Rosalía Gómez
Marcos ya que son parte fundamental en mi vida.
Pero que fuera de una persona sin un motivo, sin una inspiración. A ti por tu paciencia y
comprensión, me inspiraste a ser mejor, ahora puedo decir que esta tesis lleva mucho de
ti, gracias por estar siempre a mi lado por los consejos, por cuidarme y por quererme.
AGRADECIMIENTOS
Primero que nada quiero expresar mi más sincero agradecimiento a mi tutora de tesis
M.I.A Verónica Gutiérrez Ocampo por haberme brindado la oportunidad de trabajar con
ella, por el tiempo y la paciencia.
Un agradecimiento muy especial a la profesora Angela Hernández Ríos por el apoyo
brindado en las opiniones, dudas, consejos por la revisión y observaciones hechas a este
trabajo, es una de las profesoras en quien confió enteramente.
Agradezco a la Mtra. Edith Vargas Morales por el apoyo brindado en la realización de esta
tesis, correcciones, observaciones y opiniones para la mejora de este trabajo.
Un agradecimiento a Víctor Hugo Martínez Vara por facilitarme el proyecto CODAP para la
ejemplificación de las pruebas.
ÍNDICE GENERAL
RESUMEN ............................................................................................................................................. i
ABSTRACT ............................................................................................................................................ ii
CAPÍTULO 1 ......................................................................................................................................... 1
INTRODUCCIÓN ................................................................................................................................... 1
Planteamiento del problema .......................................................................................................... 2
Objetivo general .............................................................................................................................. 3
Objetivos específicos ....................................................................................................................... 3
Justificación de la investigación ...................................................................................................... 3
Alcances y limitaciones ................................................................................................................... 4
Organización del estudio ................................................................................................................. 4
CAPÍTULO 2 ......................................................................................................................................... 6
MARCO TEÓRICO ................................................................................................................................. 6
Testing ............................................................................................................................................. 6
Tester............................................................................................................................................... 6
Falla ................................................................................................................................................. 6
Defecto ............................................................................................................................................ 6
Error ................................................................................................................................................ 7
Validación ........................................................................................................................................ 7
Verificación ...................................................................................................................................... 7
Pruebas ............................................................................................................................................ 7
PRUEBAS DE CAJA NEGRA ............................................................................................................... 8
2.10 DE SISTEMA ......................................................................................................................... 8
2.11 DE FIN A FIN......................................................................................................................... 9
2.12 PRUEBAS DE CAJA BLANCA ................................................................................................. 9
2.13 PRUEBAS MANUALES .......................................................................................................... 9
2.14 PRUEBAS AUTOMÁTICAS ........................................................................................................ 9
2.15 PRUEBAS UNITARIAS ............................................................................................................. 10
2.16 PRUEBAS DE INTEGRACIÓN ................................................................................................... 11
2.17 PRUEBAS DE ACEPTACIÓN .................................................................................................... 11
2.18 PRUEBAS ALFA ....................................................................................................................... 11
2.19 PRUEBAS BETA ...................................................................................................................... 11
2.20 PRUEBAS FUNCIONALES ........................................................................................................ 12
2.21 PRUEBAS DE SEGURIDAD ...................................................................................................... 12
2.22 PRUEBAS DE USABILIDAD ...................................................................................................... 12
2.23 PRUEBAS DE HUMO .............................................................................................................. 13
2.24 IEEE Standard for software unit testing, IEEE 1008-1987 ..................................................... 13
2.25 ANSI / IEEE Std 829-1983...................................................................................................... 13
2.26 Certificación del ISTQB .......................................................................................................... 14
2.27 HERRAMIENTAS PARA TESTING ............................................................................................ 14
2.27.1 Testopia .............................................................................................................................. 14
2.27 .2 Qabook .............................................................................................................................. 15
2.27.3 Squash Tm .......................................................................................................................... 15
2.27.4 Testitool.............................................................................................................................. 15
2.27.5 SELENIUM ........................................................................................................................... 15
2.27.6 WATIR ................................................................................................................................. 16
2.27.7 WATIN ................................................................................................................................ 16
2.27.8 T-Plan Profesional.............................................................................................................. 17
2.27.9 Spiratest ............................................................................................................................. 17
2.27.10 FIREBUG ........................................................................................................................... 18
2.27.11 IMACROS FOR FIREFOX .................................................................................................... 18
CAPÍTULO 3 ....................................................................................................................................... 19
DESARROLLO ..................................................................................................................................... 19
3.1. Descripción del objeto de estudio .............................................................................................. 19
3.2. Características y habilidades de un tester.................................................................................. 20
3.2.1 Características de un tester ...................................................................................................... 20
3.2.2 ¿Qué hace valioso a un tester? .............................................................................................. 22
3.3. Tipos de pruebas que puede implementar un tester para el desarrollo de un sistema ............ 24
3.3.1 PRUEBAS UNITARIAS ............................................................................................................... 25
3.3.2 PRUEBA DE INTEGRACIÓN ....................................................................................................... 27
3.3.3 PRUEBAS FUNCIONALES ........................................................................................................... 28
3.3.4 Prueba de Usabilidad .............................................................................................................. 29
3.3.5 De caja blanca (o estructurales) .............................................................................................. 30
3.3.6 De caja negra (o Funcionales) ................................................................................................. 31
3.4 Herramientas de apoyo para un tester en el desarrollo de su labor profesional ..................... 32
3.4.1 JUnit ......................................................................................................................................... 32
3.4.2 PHPUnit ................................................................................................................................... 34
3.4.3 SimpleTest ............................................................................................................................... 34
3.4.4 FIREBUG ................................................................................................................................... 35
3.5 CERTIFICACIONES PARA TESTER´S ............................................................................................. 36
3.5.1 Certificación del ISTQB ............................................................................................................. 36
3.5.2 IIST ........................................................................................................................................... 37
3.5.3 American Society for Quality.................................................................................................... 37
3.5.4 iSQI ......................................................................................................................................... 37
3.5.5 British Computer Society / Information Systems Examinations Board .................................... 38
3.5.6 Instituto de Examinación para Ciencias Informáticas .............................................................. 38
3.6 Precepciones de un tester profesional ....................................................................................... 39
CAPÍTULO 4 ....................................................................................................................................... 41
RESULTADOS Y CONCLUSIONES ........................................................................................................ 41
REFERENCIAS ..................................................................................................................................... 42
ANEXOS ............................................................................................................................................. 44
ÍNDICE DE FIGURAS
Figura 1 Proceso de pruebas ............................................................................................................... 8
Figura 2 Pruebas de Caja Negra .......................................................................................................... 8
Figura 3 Flujo de Control de Pruebas Unitarias ................................................................................. 10
Figura 4 Flujo de control de pruebas de integración ........................................................................ 11
Figura 5 Flujo de control de pruebas de aceptación ......................................................................... 12
Figura 6 Usuarios WATIR ................................................................................................................... 16
Figura 7 Imaginar ............................................................................................................................... 20
Figura 8 Explorador ........................................................................................................................... 20
Figura 9 Incansable ............................................................................................................................ 20
Figura 10 Perfeccionistas .................................................................................................................. 21
Figura 11 Creatividad ........................................................................................................................ 21
Figura 12 Diplomacia ......................................................................................................................... 21
Figura 13 Persuasivo ......................................................................................................................... 21
Figura 14 Niveles de Prueba .............................................................................................................. 25
Figura 15 Clase Cambiar contraseña ................................................................................................. 26
Figura 16 Pruebas de Integración ..................................................................................................... 27
Figura 17 Pruebas Funcionales .......................................................................................................... 28
Figura 18 Pruebas de Usabilidad ....................................................................................................... 29
Figura 19 Pruebas de Caja Negra ...................................................................................................... 31
Figura 20 Clase suma ......................................................................................................................... 32
Figura 21 Clase SumaTest .................................................................................................................. 33
Figura 22 Prueba Correcta ................................................................................................................ 33
Figura 23 Prueba Fallida .................................................................................................................... 34
Figura 24 Firebug ............................................................................................................................... 35
Figura 25 Certificación ISTQB ............................................................................................................ 36
i
RESUMEN
Las empresas desarrolladoras de software desde los años setenta son conscientes que
existe una gran necesidad de aplicar procesos de verificación en el desarrollo de software
para asegurar que los productos finales satisfagan las especificaciones y necesidades del
cliente pero muchas veces realizan sistemas en lapsos tan cortos que es inevitable que los
errores se hagan presentes en casos reales de sistemas liberados a producción sin ser
probados por un tester, los sistemas son propensos a poner en evidencia la ineficiencia del
grupo desarrollador. Algunos de los problemas que se pueden suscitar en un sistema
liberado a producción sin ser probado por un tester son:
Afectar al cliente, es decir, si el sistema procesa flujo de dinero podría haber
pérdidas monetarias para el cliente si los errores son de esas características.
Disminuye el valor inicial del sistema.
Aumenta costos en cuanto a tiempos para realizar cambios o correcciones.
En esta tesis se presenta de forma detallada los beneficios de implementar pruebas en un
sistema monitoreado por un tester, mostrando las técnicas y procesos utilizados para las
pruebas de un sistema, comprobando que un producto es de mejor calidad cuando se
realiza un proceso de testing, esto se hace posible explicando las características y
habilidades de un tester, mostrando los tipos de pruebas que puede implementar un
tester para el desarrollo de un sistema, exponiendo los beneficios de utilizar un tester
para el desarrollo de un sistema, mostrando algunas herramientas de apoyo para el
proceso de pruebas y a grandes rasgos ejemplificar algunos procesos de testing, para ello
se analizarán las tareas que desempeña, ¿cómo las realiza?, ¿porque son necesarias?,
¿qué darán como resultado si implementamos este proceso en un sistema? , esto da
como resultado una amplia información para las personas interesadas en dedicarse a la
estupenda tarea de realizar pruebas y en caso de las empresas para ir considerando a
estas personas no opcionales si no necesarias.
ii
ABSTRACT
The software development companies since the seventies are aware that there is a great
need for verification processes in software development to ensure that the final products
meet the specifications and customer needs but often perform systems spans so short
that is errors inevitably become present in real cases released into production without
being tested by a tester, systems are likely to highlight the inefficiency of the developer
group systems. Some of the problems that can give rise to a production released without
being tested by a tester system are:
• Affect the client is if the system processes flow of money could have monetary losses for
the client if the errors are of this nature.
• Decrease the initial value of the system.
• Increased costs in terms of time to make changes or corrections.
This thesis presents in detail the benefits of implementing evidence in a system monitored
by a tester, showing the techniques and processes used for testing a system, ensuring that
a product is of better quality when a testing process is done, This permits explaining the
features and capabilities of a tester, showing the types of tests that can implement a
tester for the development of a system, exposing the benefits of using a tester for the
development of a system, showing some support tools the testing process and broadly
illustrate some testing processes, to do many tasks will be analyzed, how are done ?,
because they are necessary ?, What will result if we implement this process in a system?
This results in a wide range of information for those interested in taking up the great task
of testing and in case of companies to go considering these not optional if necessary
people.
1
CAPÍTULO 1
INTRODUCCIÓN
Las empresas desarrolladoras de software desde los años setenta son conscientes que
existe una gran necesidad de aplicar procesos de verificación en el desarrollo de software
para asegurar que los productos finales satisfagan las especificaciones y necesidades del
cliente. Existían otros métodos como las técnicas de verificación estáticas (análisis de
diagramas, diseño y código fuente) que eran en ese entonces las más usadas, pero
predominaba el testing este proceso consiste en ejecutar un programa bajo condiciones
controladas, usando datos reales y observando la salida o resultados obtenidos.
Este proceso permite reducir retrasos en la entrega del producto, fallas del software en la
operación, desacreditación de posicionamiento del producto o de los equipos de
desarrollo o compañía responsable, costos no contemplados por las fallas del producto, lo
que genera pérdidas a veces demasiado costosas, que en algunos casos llevan a que una
empresa quiebre, o en el peor de los casos hay antecedentes que comprueban que
errores de sistema han cobrado vidas humanas, y todo por no realizar las pruebas debidas
del software, porque se piensa que no son necesarias antes de liberar el producto o que
son pérdida de tiempo y recursos. Por el contrario, que un tester realice las pruebas
necesarias que disminuyan la mayor cantidad de errores, puede evitar que empañen la
imagen y a veces la reputación de una organización. Surge por tanto la necesidad de
asegurar en lo posible, la calidad del producto.
2
Planteamiento del problema
Actualmente las empresas desarrolladoras de software realizan sistemas en lapsos tan
cortos que es inevitable que los errores se hagan presentes desde la primera etapa de
desarrollo, en casos reales los sistemas liberados a producción sin ser probados por un
tester con la finalidad de ahorrar tiempo, son los sistemas propensos a poner en evidencia
la ineficiencia del grupo desarrollador y la baja calidad de sus sistemas, ya que los errores
son detectados por los usuarios.
Algunos de los problemas que se pueden suscitar en un sistema liberado a producción sin
ser probado por un tester son:
Afectar al cliente es decir si el sistema procesa flujo de dinero podría haber
pérdidas monetarias para el cliente si los errores son de esas características.
Disminuye el valor inicial del sistema.
Aumenta costos en cuanto a tiempos para realizar cambios o correcciones.
Desprestigio del equipo desarrollador o empresa a la cual pertenecen.
Demandas por parte del cliente insatisfecho.
Quiebre de una empresa.
El 51% de los encuestados indicó que el software que siempre operan, siempre
(4%), a con frecuencia (10%) o algunas veces (39%) sufre de problemas de calidad
(estudio PAC).
Eso solo son algunos problemas que puede generar el sacar a producción un producto que
no ha sido probado por un tester, ya que muchas empresas omiten este proceso por
limitar tiempos de entrega y ahorrar costos en la implementación de un tester. Para
atacar este problema se ha pensado en la realización de esta investigación, con esto se
quiere dar a conocer la importancia del proceso de testing y la importancia de que un
tester tome la decisión de liberar un sistema a producción.
3
Objetivo general
Explicar los beneficios de implementar pruebas en un sistema monitoreado por un tester,
mostrando las técnicas y procesos utilizados para las pruebas de un sistema,
comprobando que un sistema es de mejor calidad cuando se realiza un proceso de testing.
Objetivos específicos
Explicar las características y habilidades de un tester.
Mostrar los tipos de pruebas que puede implementar un tester para el desarrollo
de un sistema.
Exponer los beneficios de utilizar un tester para el desarrollo de un sistema.
Mostrar algunas herramientas de apoyo para un tester en el desarrollo de su labor
profesional.
Ejemplificar algunos procesos de testing.
Mostrar certificaciones para testers.
Realizar búsqueda de tester profesional que de una percepción del tema.
Justificación de la investigación
Esta investigación surge como necesidad de dar a conocer a las nuevas generaciones de
ingeniería de software la importancia de que un tester realice las pruebas de un sistema y
no los mismos analistas y programadores, para ello se analizarán las tareas que
desempeña un tester, ¿cómo las realiza?, ¿porque son necesarias?, ¿qué darán como
resultado si implementamos este proceso en un sistema?, y para poder determinar que el
sistema probado por un tester puede ser considerado como un sistema de calidad.
4
Alcances y limitaciones
Alcances:
Realizar una investigación amplia sobre el proceso de testing pero no práctica.
Justificar el alcance en cuestión de seguridad al invertir en un tester.
Abrir una amplia gama de beneficios obtenidos al realizar un proceso de testing.
Mostrar en el desarrollo en qué consisten y como se llevan a cabo las pruebas que
un tester realiza a un sistema.
Dar a conocer los tipos de certificación para tester.
Limitaciones:
La investigación a desarrollar solo es enfocada a las funciones y labores de un
tester.
Esta investigación no implica evidencia dinámica de la realización de pruebas o
utilización de herramientas solo se explica su funcionamiento.
Los ejemplos mostrados solo serán explicativos y no demostrativos
dinámicamente.
Las pantallas mostradas en las pruebas solo serán para ejemplificar las pruebas
expuestas.
Organización del estudio
El desarrollo del presente documento referente a la investigación de testing, abarca los
siguientes capítulos los cuales se describen de forma breve.
CAPÍTULO 1 INTRODUCCIÓN
En este capítulo se describe el planteamiento del problema a solucionar, la descripción
general del proceso de testing, objetivo general de la investigación que se pretende
alcanzar al culminar la investigación y el manual de tester, objetivos específicos,
justificación de la investigación y los alcances y limitaciones.
5
CAPÍTULO 2 MARCO TEÓRICO
Describe los elementos teóricos (fuentes consultadas como libros e internet) planteados
por diferentes autores, es aquí donde se explican las técnicas, tecnologías etc., que
sustentan la investigación, lo cual permite al lector una mejor comprensión del tema
abordado.
CAPÍTULO 3 DESARROLLO
Este apartado contiene el proceso de desarrollo de la investigación mediante técnicas
establecidas que permitan alcanzar los objetivos específicos. Se realiza una descripción de
las actividades que se realizaron, asimismo se presenta evidencia de dichas acciones.
CAPÍTULO 4 RESULTADOS Y CONCLUSIONES
Este apartado contiene los resultados obtenidos al término del proyecto, determinación
del logro alcanzado, también se expresa por parte de los involucrados, las experiencias
que se obtuvieron durante el trabajo realizado.
6
CAPÍTULO 2
MARCO TEÓRICO
Un aspecto crucial en el control de calidad del desarrollo de software son las pruebas,
estas son realizadas por un tester y a este proceso se le llama testing en este apartado se
especificarán cada una de la pruebas que hacen que el trabajo de un tester tenga lógica
así como antecedentes de lo que ha sucedido por no probar un sistema antes de liberarlo
a producción.
2.1 Testing
“El grado en que un sistema o componente realiza sus funciones designadas dentro de las
limitaciones dadas, tales como la velocidad, precisión, o el uso de la memoria, enfocadas
en ¿Cuánto? y ¿Qué tan rápido? funciona la aplicación, no se hace juicio de la aplicación
solo se mide y analiza(CITA)”.
2.2 Tester
“Los Testers(o probadores) son los que señalan los problemas encontrados en el software,
los fallos durante las pruebas pueden ser percibidos como una crítica contra el producto y
en contra del autor (negociosymanagement, 2013)”.
2.3 Falla
“Una falla es la discrepancia visible que se produce al ejecutar un programa con un
defecto, el cual es incapaz de funcionar correctamente, no sigue su curso normal (web_us,
2008)”.
2.4 Defecto
“Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la
versión correcta del artefacto y una versión incorrecta (EDGAR SANDINO, 2010)”.
7
2.5 Error
El estándar 829 de la IEEE coincide con la definición, define error como “una idea falsa o
equivocada, por ende un programa no puede tener o estar en un error, ya que los
programas no tienen ideas; las ideas las tienen la gente”.
“Nunca se puede probar que un programa no fallará, solo se puede probar que contiene
defectos”
2.6 Validación
Según Boehm, la validación responde la siguiente pregunta: ¿Se está construyendo el
producto correcto?
2.7 Verificación
Para diferenciar esta tarea con la validación, Boehm indica que debe responderse a la
siguiente pregunta: ¿Se está construyendo el producto de la manera correcta?, el
propósito de la Verificación es asegurar que los productos seleccionados cumplen los
requisitos especificados.
2.8 Pruebas
Una prueba es una actividad en la que un sistema o un componente es ejecutado bajo
condiciones especificadas, los resultados son observados o registrados, y una evaluación
es realizada de un aspecto del sistema o componente (IEEE Std.610.12-1990).
Una prueba es una actividad ejecutada para evaluar y mejorar la calidad del producto a
través de la identificación de defectos y problemas (SWEBOK).
8
2.9 Pruebas de caja negra
“Éstas, principalmente, se centran en módulos o charters de interfaz de usuario (pantalla,
ficheros, canales de comunicación…) pero suelen ser útiles en cualquier módulo ya que
todos o la mayoría tienen datos de entrada y salida que se pueden comprobar y verificar
(VÍCTOR GÓMEZ ADÁN, 2012)”.
2.10 De sistema
“El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación
apropiado de datos, y la implementación apropiada de las reglas de negocios, esta prueba
Figura 2 Pruebas de Caja Negra
Figura 1. Proceso de pruebas
9
se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán
que la aplicación alcanzará sus objetivos de negocio (Jorge Hernán Abad Londoño, 2005)”.
2.11 De fin a fin
Involucra la interacción del sistema con otro hardware por ejemplo Base de Datos y redes.
2.12 Pruebas de caja blanca
Estas pruebas están basadas en la lógica interna de la aplicación y verifican que líneas
específicas código funcionan tal como está definido. Con estas pruebas se intenta
garantizar que se ejecuten al menos una vez todos los caminos independientes de cada
módulo, se utilizan las decisiones falsas y verdaderas, para esta prueba, se consideran tres
importantes puntos:
Conocer el desarrollo interno del programa, se debe realizar un análisis de
coherencia y consistencia del código.
Considerar las reglas predefinidas por cada algoritmo.
Comparar la documentación con lo que se está codificando.
2.13 Pruebas manuales
Las pruebas manuales ayudarán a descubrir cualquier problema relacionado con la
funcionalidad del sistema en particular defectos relacionados con la facilidad de uso y
requisitos de interfaces. Por ejemplo cuando verificamos que una página web se visualiza
en dos navegadores diferentes.
2.14 Pruebas automáticas
Para estas pruebas e utilizan un determinado software para sistematizarlas. Por ejemplo,
verificar un método de ordenación. Para este tipo de pruebas IBM Rational proporciona
herramientas que permiten realizar este tipo de pruebas.
10
2.15 Pruebas unitarias
Se aplican a un componente del software se puede considerar como componente
(elemento indivisible) a una función, una clase, una librería, un método. Estas pruebas las
ejecuta un desarrollador cada vez que va probando fragmentos de código o scripts para
ver si todo funciona como se desea.
Figura 3. Flujo de Control de Pruebas Unitarias
11
2.16 Pruebas de integración
Estas pruebas se basan en la conexión y la comunicación entre diferentes módulos. Son pruebas más indispensables en sistemas Cliente-Servidor o Red.
2.17 Pruebas de aceptación
Estas pruebas son realizadas por usuarios expertos, que permiten determinar que un
producto ya está listo para ser liberado a producción, se puede distinguir entre dos tipos
de pruebas; en ambas existe retroalimentación por parte del usuario experto:
2.18 Pruebas alfa
Las realiza el usuario en presencia de personal de desarrollo del proyecto, para estas
pruebas se implementa una máquina exclusiva para las pruebas.
2.19 Pruebas beta
Las realiza el usuario después de que el equipo de desarrollo les entregue una versión casi
definitiva del sistema.
Figura 4. Flujo de control de pruebas de integración
12
2.20 Pruebas funcionales
Estas pruebas son generalmente hechas por los testers, se realizan sobre el sistema
funcionando comprobando que cumpla con las especificaciones (normalmente a través de
los casos de uso). Las pruebas de rendimiento se basan en comprobar que el sistema
puede soportar el volumen de carga definido en la especificación, es decir, hay que
comprobar la eficiencia (por ejemplo, se ha montado una página web sobre un servidor y
hay que probar qué capacidad tiene el estado de aceptar peticiones, es decir capacidad de
concurrencia (CIBERTEC, Pag.17).
2.21 Pruebas de seguridad
Evalúa que el grado de seguridad con el que cuenta el sistema al protegerse contra
accesos internos o externos no autorizados, estas pruebas requieren sofisticadas técnicas
y herramientas.
2.22 Pruebas de usabilidad
“Las pruebas de usabilidad aportan datos tanto cuantitativos como cualitativos sobre
usuarios reales que llevan a cabo tareas reales con un producto. Los profesionales de la
usabilidad pueden evaluar algunos aspectos de la accesibilidad utilizando protocolos
Figura 5. Flujo de control de pruebas de aceptación
13
normalizados de pruebas de usabilidad, introduciendo unas pocas modificaciones para
incluir a participantes con discapacidad (2008, Shawn Lawton Henry)”.
2.23 Pruebas de humo
“Una prueba de humo o smoke test, es un testing rápido que se realiza sobre aspectos
funcionales no tanto para encontrar bugs sino para asegurarse que la funcionalidad básica
del software o de una parte del software se encuentre estable y responda al
comportamiento esperado” (Irina Fuentes Viñas, 2014).
El objetivo es verificar, con pruebas sencillas y que demanden poco tiempo, que ciertos
caminos de la aplicación funcionen correctamente. Normalmente se elige un conjunto de
funcionalidades significativas, no hace falta que sean todas las de la aplicación.
2.24 IEEE Standard for software unit testing, IEEE 1008-1987
El objetivo principal de este estándar es especificar un modo común de realizar las
pruebas de unidad al software, el cual puede ser utilizado como base para buenas
prácticas de la ingeniería del software.
2.25 ANSI / IEEE Std 829-1983
Norma IEEE para la documentación del software de pruebas, se describe la información
básica, necesidades y resultados de pruebas de software. Esta norma de ensayo unidad
requiere el uso del diseño de la prueba especificación y resumen de la prueba de informe
especificado en la norma ANSI / IEEE Std 829 a 1.983.
14
2.26 Certificación del ISTQB
El ISTQB (International Software Testing Qualifications Board) es una organización de
certificación de la calidad del software que opera internacionalmente. El ISTQB fue
fundado en noviembre de 2002 en Edimburgo y está legalmente registrado en Bélgica.
Esta organización se encarga de soportar y definir un esquema de certificación
internacional. Suministra el plan de estudios y el glosario sobre los que se definen los que
se establecen las guías para la acreditación y evaluación de los profesionales del testing a
cargo de los comités de cada país Según ellos mismos, el ISTQB ha creado esquema más
exitoso del mundo para la certificación de los probadores de software. Hasta junio de
2013, ha certificado a más de 307.000 testers en 70 países en todo el mundo, con una tasa
de crecimiento de aproximadamente 12.000 certificaciones por trimestre (testeando
software, 2014).
2.27 HERRAMIENTAS PARA TESTING
Antes de seleccionar una herramienta para pruebas es necesario pensar primero en los
requisitos y las necesidades del proyecto, luego comparar algunas y posteriormente
probarlas hasta llegar a la selección más adecuada, existen algunas herramientas que
pueden ayudar a realizar el proceso de testing y que harán más confiable las tareas de un
tester teniendo como base una herramienta que respalde los errores encontrados en el
sistema.
1) Herramientas Open Source:
2.27.1 Testopia
Es un administrador de casos de prueba, el cual maneja extensiones para interactuar con
Bugzilla. Testopia está diseñado para ser una herramienta genérica para el seguimiento de
casos de prueba, permitiendo a las organizaciones realizar las pruebas de software e
integrar reportes de defectos encontrados, así como el resultado de los de los caso de
prueba (VictorTapiaTec, 2013).
15
2.27.2 Qabook
Es un producto de gestión de pruebas que le permite crear, gestionar y editar:
requerimientos, casos de prueba (con o sin pasos de prueba), prueba de rachas, defectos,
ambientes, presentación de informes y más con la elección de escritorio, web o Microsoft
SharePoint como su interfaz de usuario, en las instalaciones o en la nube (qabook, 2014).
2.27.3 Squash Tm
Es el gestor de repositorio de pruebas se encuentra en el kit de herramientas de código
abierto Squash. Permite la gestión de requisitos, casos de prueba y ejecución de campañas
en un contexto de múltiples proyectos (sourceforge, 2014).
2.27.4 Testitool
Testitool es una aplicación escrita en PHP que permite a sus usuarios componer y
gestionar el plan de pruebas de control de calidad (testitool, 2014).
2) Herramientas para pruebas funcionales
2.27.5 Selenium
Es un framework para pruebas de aplicaciones Web, descargable de forma gratuita desde
su sitio web. Proporciona una herramienta de grabación y playback, que permite
desarrollar pruebas sin necesidad de aprender un lenguaje de Scripting, incluye
características como grabación, playback, selección de campos, auto completar
formularios, pruebas de recorrido (Walkthrough), debug, puntos de control, scripts Ruby y
otros formatos.
16
2.27.6 Watir
Watir para la automatización de los navegadores web. Te permite escribir pruebas que
sean fáciles de leer y mantener. Es simple y flexible, watir impulsa navegadores de la
misma manera que la gente hace. Se hace clic en los enlaces, llena de formas, presiona los
botones. Watir también comprueba los resultados, como por ejemplo si el texto se espera
que aparezca en la página.
Watir es una familia de bibliotecas de Ruby pero apoya su aplicación, no importa lo que la
tecnología se desarrolla en. Mientras Watir sólo soporta Internet Explorer en Windows,
Watir-WebDriver apoya Chrome, Firefox, Internet Explorer, Opera (watir.com).
Algunos usuarios que utilizan esta herramienta son:
2.27.7 Watin
WatiN se ha convertido en una herramienta fácil de usar, ofrece un marco rico y estable.
WatiN está desarrollado en C # y objetivo es ofrecer una manera fácil de automatizar sus
pruebas con Internet Explorer y FireFox utilizando .Net (watin.org).
Figura 6. Usuarios WATIR
17
3) Herramientas comerciales de gestión de pruebas
2.27.8 T-Plan Profesional
Tiene un diseño modular, diferenciando claramente entre el Análisis, Diseño, Gestión y
Supervisión de los Activos de prueba. Los errores o consultas encontrados durante la
ejecución de la prueba también se pueden registrar y seguimiento durante todo el ciclo de
vida de Pruebas en el Administrador de T-Plan de Incidentes.
2.27.9 Spiratest
SpiraTest incluye un sistema integrado de gestión basado en la web de documentos que
permite a los miembros del proyecto para subir documentos en un lugar seguro y
centralizado, con el apoyo de la organización de carpetas, las taxonomías de
documentación y meta-etiquetado, así como una función de control de versiones. A
diferencia de una herramienta independiente, estos documentos pueden ser conectados a
los artefactos SpiraTest (requisitos, casos de prueba, incidente es) para proporcionar una
imagen completa a los usuarios.
En el apartado anterior se mencionan algunas herramientas que facilitan la realización de
pruebas para testers, como se mencionó algunas son de acceso libre y otras son
comerciales dependiendo de la magnitud del sistema y lo que se quiera probar es como se
elige el tipo de herramienta, por ejemplo Firefox cuenta con algunos complementos que
son fáciles de usar y que ayudan a ir detectando errores al momento de ejecutar una
función algunas de estas herramientas son:
18
2.27.10 Firebug
Es una extensión de Firefox creada y diseñada especialmente para desarrolladores y
programadores web. Es un paquete de utilidades con el que se puede analizar (revisar
velocidad de carga, estructura DOM), editar, monitorizar y depurar el código fuente, CSS,
HTML y JavaScript de una página web de manera instantánea e online.
2.27.11 Imacros for firefox
Los profesionales en la web puede utilizar iMacros probar la funcionalidad y performance
de aplicaciones de la web. El comando CRONÓMETRO captura de forma precisa los
tiempos de respuesta de las páginas web. iMacros también incluye soporte para muchos
elementos AJAX.
19
CAPÍTULO 3
DESARROLLO
Después de realizar un análisis con toda la información recabada de la investigación para
poder llevar a cabo un proceso de testing se debe implementar ciertas pruebas que
ayudan a encontrar los errores de un sistema de manera más específica, así como
herramientas que facilitan el proceso de testing, la unión de todos estos elementos hacen
que las empresas realicen sistemas de mejor calidad y que sus clientes queden
satisfechos con el producto recibido.
3.1. Descripción del objeto de estudio
Testing es el proceso que se debería realizar en todo sistema, desde el inicio de la primera
etapa y hasta su aprobación con el objetivo de entregar un sistema sin errores, o con el
menor margen de ellos, el objetivo de esta investigación es llevar a las empresas una
nueva manera de ver el trabajo de un tester, de tal manera que se convenzan que este rol
dentro de un proyecto es de suma importancia como el de un desarrollador, un
tester tiene la capacidad de cuestionar soluciones con el objetivo de agregar valor a un
producto, para llegar a esto el tester tiene como objetivo tomar las pruebas que él
considere pertinentes de acuerdo al sistema e implementarlas para tener un respaldo de
los errores encontrados, ya que un tester no se contagia de suposiciones.
En el siguiente apartado se retomarán los objetivos específicos de esta investigación,
ejemplificando cada uno de ellos.
20
3.2. Características y habilidades de un tester
Como se puntualizó en el marco teórico lo que es un tester, en este objetivo se extenderá
la importancia del mismo en un equipo de desarrollo, puesto que tiene diferentes
habilidades y características al resto del equipo, cumple tareas específicas y no se basa en
supersticiones, por lo tanto ¿qué características debe tener un tester? y ¿Por qué es
valiosa la presencia de un tester?
3.2.1 Características de un tester
Capacidad para "imaginar" soluciones a problemas existentes.
Explorador nato.
Incansable
No tienen ningún miedo por adentrarse en terrenos y
situaciones desconocidas. Un buen tester está
deseando obtener la última versión beta de un cierto
producto para explorar sus entrañas y, a ser posible, ser
el primero en encontrarle fallos.
Un tester debe ser capaz de poder realizar hipótesis con
un grado de fiabilidad aceptable acerca de la causa de
un error cuando éste se produce.
Según Miguel Llopis un tester debe ser incansable:
debo confesar que frente a mi mesa de trabajo tenía
un folio clavado en un panel de corcho con dos
palabras en inglés a tamaño 48, negrita y subrayadas:
KEEP TRYING!
Figura 7. Imaginar
Figura 8. Explorador
Figura 9. Incansable
21
Perfeccionistas con criterio
Creatividad
Diplomacia
Persuasivo
La perfección de un producto radica en el equilibrio perfecto
entre fiabilidad y coste. De nada nos sirve un software
desarrollado en tiempo récord si tiene muchos fallos.
Probar lo extraño no es suficiente para un tester,
debe tener la capacidad de crear aquellos errores que
no imaginó el desarrollador y que pudieran hacer
fallar el sistema.
Un tester debe tener la capacidad de expresarse con
tacto, aun cuando lo que se está haciendo es criticar el
trabajo de otros. A pesar de tratarse de una crítica
constructiva y enfocada a mejorar el producto final,
no es algo sencillo.
Un tester debe ser capaz de señalar bien el error
expuesto y, realmente, convencer al resto de
miembros del equipo de que dicho fallo DEBE ser
resuelto a la mayor brevedad posible.
Figura 10. Perfeccionistas
Figura 11. Creatividad
Figura 12 .Diplomacia
Figura 13. Persuasivo
22
De manera personal y con base en la experiencia que obtuvo realizando pruebas, las
características más importantes que se considera debe tener un tester, es profesionalismo
y diplomacia esto acompañado de la buena comunicación con los demás integrantes del
equipo de desarrollo, ya que muchas veces el trabajo de un tester es criticado, porque el
tester es el encargado de detectar los errores e informarlos al resto del equipo , esto
molesta pues aparte del trabajo establecido deben corregir los errores encontrados.
Miguel Meléndez, un tester profesional con 5 años de experiencia en el área de testing,
compartió lo siguiente: “Sin embargo después de conocer por sólo dos meses el
testing, me di cuenta que mi forma de pensamiento se empataba con lo que un tester
debe hacer, cualidades como pensamiento crítico y pensamiento lateral, siempre he sido
alguien que cuestiona e incluso que desafía el status QA”.
3.2.2 ¿Qué hace valioso a un tester?
Es muy útil contar con alguien cuyo trabajo sea única y exclusivamente vigilar la
calidad del software para asegurar que la calidad se vea como una autentica
prioridad. Al saber que una persona buscará el error más mínimo, el equipo
desarrollador será más cuidadoso y deseará tener los menores errores posibles. A
nadie le gusta que le digan sus errores.
Un tester impulsa el desarrollo, por que ayuda a que los errores se detecten
rápido y no afecte en las demás tareas planeadas. Otro factor por el que un tester
impulsa el desarrollo es porque tiene que tener algo que testear, lo que obliga al
equipo de desarrollo a mantener cierta velocidad en el desarrollo para alimentar al
tester.
23
Un tester impulsa el uso de buenas prácticas porque para que alguien pueda
probar el software este tiene que ser actualizado constantemente. Otro efecto
beneficioso, es que si se tiene un tester en un equipo de desarrollo, no caerán en
el error habitual de dejar la calidad para el final.
A continuación se muestran siete lecciones e indicadores que según Miguel Meléndez un
tester profesional hacen que un tester sea más valorado:
Confías en tu equipo de pruebas: Tu equipo tiene la experiencia y el conocimiento
adecuado para probar algo, tienen conocimiento tanto del dominio en el que el
sistema se desenvuelve, como de aspectos técnicos que los apoyan en las pruebas
no funcionales, recordemos: “Un tester sólo puede probar lo que conoce”.
Tienes muchas preguntas: La curiosidad es el alma del testing, utiliza el
pensamiento crítico para cuestionar y evaluar todos los elementos con los que
estás trabajando.
Te encuentras a ti mismo en situaciones que no habías pensado antes: De pronto
te das cuenta que acabas de encontrar como es que se creó el calendario romano,
qué idiomas se hablan en américa latina, como funciona la encriptación asimétrica,
el tamaño máximo de un archivo permitido en distintos sistemas operativos entre
otras…
Big Bugs: Más que la cantidad de incidencias reportadas, es importante evaluar
qué tipo de escenarios estamos reportando, si tus reportes son de alta relevancia
en la calidad del producto, es que los esfuerzos se están canalizando de manera
adecuada.
Te juzgan de loco: Las pruebas comienzan a tornarse un poco “locas” al incluir
escenarios que pudieran sonar poco probables para algunos, tal vez quieras echar
un vistazo a la priorización de tus pruebas y ejecutar primero las que sean más
probables, pero también son importantes los escenarios “raros”, recordemos
que: El pensamiento lateral es el arma fundamental de un tester.
24
Estás orgulloso de lo que vas a liberar: Las pruebas ayudan a tener una visión
amplia de la calidad del producto, los testers deberán estar orgullosos de lo que
están liberando, de lo contrario, no se estará agregando confianza al producto o
servicio.
Estas aprendiendo: El contexto es una parte fundamental del testing, se debe ver
al testing como un proceso multidisciplinario en el que cada sistema traerá consigo
el reto de aprender sobre algún tema nuevo.
Te estas divirtiendo: Si no te estás divirtiendo en testing, es que no es para ti, o no
lo estás haciendo bien, así que ¡Disfrútalo!
3.3. Tipos de pruebas que puede implementar un tester para el
desarrollo de un sistema
En un proyecto se software los errores son inevitables en cualquier etapa, entre
desarrolladores comúnmente le llaman Debugs, aun cuando realizan inspecciones
después de cada fase algunos errores permanecen fase tras fase sin ser descubiertos, por
lo que al final del desarrollo es muy probable que el sistema tenga errores.
Es por eso que las pruebas de software son muy importantes en el desarrollo de un
sistema esto hace que sean demasiado costosas, pueden llegar a representar el 30 y 50%
del costo total del sistema, pero cuando un sistema es liberado sin ser probado y contiene
errores puede ser fatal y los costos mucho más altos ver Anexo 1 y 2.
Se ejemplificarán las pruebas recomendables para un sistema, como se realizan y en qué
consisten. La fig. xx muestra las pruebas que se realizan en cada nivel de desarrollo, como
se puede observar se empieza probando cosas pequeñas hasta llegar a lo más grande.
25
3.3.1 PRUEBAS UNITARIAS
Las pruebas unitarias son una de las formas que se tiene de probar pequeñas e
individuales partes de código. A través de ellas se verifica que cierto módulo o
funcionalidad se ejecuta dentro de los parámetros y especificaciones.
Las pruebas unitarias típicamente son automatizadas, pero pueden llevarse a cabo de
forma manual. Cuando son automatizadas es buena práctica que forme parte del
repositorio que contiene al código probado (Marisol Lara García, 2013).
Para la ejemplificación de esta prueba se tomará el fragmento de código de una clase.
Figura 14. Niveles de Prueba
26
Los principales aspectos a
considerar son los siguientes:
Si las condiciones no se cumplen
debe generar Rutinas de Error
Que se generen las
validaciones
Si una condición no se cumple
mostrará Posibles Mensajes
Que se realicen las condiciones
Resultado: Comparar el resultado
esperado con el resultado obtenido. Figura 15 Clase Cambiar contraseña
27
3.3.2 PRUEBA DE INTEGRACIÓN
Consiste en construir el sistema a partir de los distintos componentes y probarlo con
todos integrados. Estas pruebas deben realizarse progresivamente. El foco de atención es
el diseño y la construcción de la arquitectura de software.
En este caso se prueba cómo es la interacción entre dos o más unidades del software, las
pruebas de integración son las que comprobarían que se ha mandado un email o la
conexión real con la base de datos.
Las principales características a tomar son las siguientes:
Que los datos se almacenen de
manera correcta en la BD
Verificar que las especificaciones de diseño sean alcanzadas con respecto a las respecto a las especificaciones. Decide qué acciones tomar
cuando se descubren problemas
Figura 16 Pruebas de Integración
28
Para estas pruebas se recomienda realizar estas técnicas para ver mejor el
comportamiento de la integración de las unidades.
Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica
que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con
los parámetros correctos.
Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se verifica
que los módulos de nivel inferior llaman a los de nivel superior de manera.
3.3.3 PRUEBAS FUNCIONALES
Las pruebas Funcionales deben enfocarse en los requisitos funcionales, se asegura el
trabajo apropiado de los requisitos funcionales, incluyendo la navegación, entrada de
datos, procesamiento y obtención de resultados.
Las metas de estas pruebas son:
Verificar la apropiada
aceptación de datos
Verificar el procesamiento y
recuperación de datos
Que sean desplegados los mensajes apropiados de error y precaución cuando se usan datos inválidos.
Que los resultados esperados ocurran cuando se usen datos válidos. Figura 17. Pruebas Funcionales
29
3.3.4 PRUEBAS DE USABILIDAD
Determina que tanto el usuario podrá usar y entender la aplicación. Identifica las áreas de
diseño que hacen al sistema de difícil uso para el usuario. La prueba de usabilidad detecta
problemas relacionados con la conveniencia y lo práctico del sistema desde el punto de
vista del usuario.
Los principales problemas de usabilidad que se desean detectar y corregir son los
siguientes:
El sistema es demasiado complejo y difícil de usar.
La recuperación de errores es pobre y los mensajes de error no tienen significado
El sistema obliga al usuario a recordar formatos y secuencias
Los diagramas, pantallas, reportes y gráficos son de calidad y apariencia pobre
La lógica y conveniencia de los botones, interfaces y mensajes de ayuda deben ser testeadas
Figura 18 Pruebas de Usabilidad
30
3.3.5 DE CAJA BLANCA (O ESTRUCTURALES)
Los métodos de caja blanca o estructural permiten:
De caja negra (o funcionales)
Garantizar que todas las rutas independientes dentro del módulo se ejecuten al menos una vez
Probar que se ejecuten los lados verdadero y falso de todas las decisiones lógicas
Ejecutar las estructuras de
datos internas para asegurar
su validez
Hacen énfasis en la reducción de errores internos
Verificar la correcta
implementación de las unidades
internas, las estructuras y sus
relaciones
Figura Pruebas de Caja Blanca
31
3.3.6 DE CAJA NEGRA (O FUNCIONALES)
Los métodos de caja negra o funcional permiten detectar errores como:
Funciones incorrecta o faltante Errores de interfaz
Errores en estructuras
de datos o en acceso a
BD externas Errores de comportamiento o
desempeño
Errores de inicialización o término
Figura 19. Pruebas de Caja Negra
32
3.4 Herramientas de apoyo para la realización de pruebas
Algunos Frameworks de apoyo para realizar pruebas unitarias ofrecen un conjunto
completo de utilidades, motores de ejecución y reportes son:
JUnit, TestNG, CPPUnit, NUnit, Visual Studio UnitTesting
3.4.1 JUnit
Se tomará un ejemplo del ingeniero Felipe Martínez, donde de ejemplifica de manera
sencilla cómo funciona la herramienta JUnit.
1. Se empezará creando la clase que queremos probar. Tendrá el siguiente código:
Es una clase muy sencilla que dispone de un método que permite sumar dos números.
2. Lo siguiente es crear la clase servirá para probar la clase Suma. Se requiere saber si la
suma se hace correctamente en tres casos: sumando dos números positivos, sumando dos
números negativos y sumando un número positivo y un número negativo. El código será el
siguiente:
Figura 20 Clase suma
33
3. Se activa la vista “JUnit” en Eclipse. Para ello hay que pulsar en: “Window”; “Show
View”; “Other...”; “Java”; “JUnit”.
4. Y se ejecuta el proyecto como test JUnit, pulsando sobre el proyecto con el botón
derecho, luego pulsamos “Run as” y finalmente “JUnit Test”.
Ahora se podrán ver los resultados. Si todo ha ido bien, en la vista JUnit aparecerá esto:
Figura 22 Prueba Correcta
Figura 21. Clase SumaTest
34
Si hay algún fallo aparecerá lo siguiente:
Figura 23. Prueba Fallida
Una vez realizada la prueba se puede ver que un resultado salió sin ninguna falla y en el
otro se hace mención que se modificó el código de forma que se pudiera ejemplificar la
prueba y se observa que la prueba salió fallido.
3.4.2 PHPUnit
Un framework para PHP que permite crear y ejecutar tests unitarios de manera simple.
Está basado en el framework “JUnit” para java.
3.4.3 SimpleTest
Es un framework para pruebas de unidad en PHP y pruebas Web. Esta herramienta
cuenta con un navegador Web interno, lo que permite que las pruebas naveguen los sitios
Web, ingresen datos en formularios y páginas de prueba.
35
3.4.4 Firebug
Firebug se integra con Firefox para poner una gran cantidad de herramientas de desarrollo
a su alcance mientras navegas. Puede editar, depurar y monitorear CSS, HTML y JavaScript
en vivo en cualquier página web (Mozilla).
De manera personal se comparte que esta herramienta es muy útil, puede tener distintas
propiedades para un desarrollador, en este caso se utilizaba para pruebas de funcionalidad,
usabilidad y carga, pues permitía ver el tiempo de respuesta de cierta acción ejemplo, insertar un
usuario, ver los segundos que se tardaba en realizar esa acción, si tardaba más del tiempo
estimado eso ya era motivo de error, en pruebas de usabilidad podía probar que todos los botones
tuvieran el mismo margen, color, alineación etc..
Figura 24 .Firebug
36
3.5 CERTIFICACIONES PARA TESTER´S
Si bien sabemos que un “probador de software” deberá de ser: curioso, perceptivo,
inquisitivo, crítico, analítico, persistente, buen comunicador y negociador, estas
características y habilidades son parte del perfil de un buen ingeniero, pero son en su
mayoría implícitas a la profesión y difíciles de medir de forma concreta. Es por eso que se
requiere de una formación estructurada y especializada que pueda ser validada para
garantizar los conocimientos básicos y la experiencia (David Aguilar, abril 2013).
Las certificaciones ayudarán a desarrollar habilidades específicas de lo que un tester debe
hacer y un terter certificado brindará la seguridad a las empresas para que deleguen la
seguridad de cualquier sistema sin necesidad de preocuparse por que la persona al hacer
las pruebas no sepa que puntos específicos probar, una persona certificada sabrá qué
proceso, herramientas, reportes generar para realizar las pruebas correspondientes y dar
los resultados esperados.
3.5.1 Certificación del ISTQB
Como ya se mencionó anteriormente esta certificación es internacional y hasta el
momento la única en su categoría. Hasta junio de 2013, ha certificado a más de 307.000
testers en 70 países en todo el mundo, con una tasa de crecimiento de aproximadamente
12.000 certificaciones por trimestre (testeando software, 2014).
Figura 25. Certificación ISTQB
37
Entre sus programas se encuentran los siguientes:
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.
3.5.2 IIST
(International Institute for Software Testing) de Estados Unidos ofrece los programas:
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.
3.5.3 American Society for Quality
(ASQ) es un organismo muy importante en Estados Unidos, que ofrece programas de
formación y certificación para roles de gestión de calidad en distintos dominios. En el caso
específico del software, ofrece el programa CSQE (Certified Software Quality Engineer).
3.5.4 iSQI
(International Software Quality Institute) en Alemania, que se destaca por ofrecer un
programa de certificación para testing ágil. Estos son sus programas:
38
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
3.5.5 British Computer Society / Information Systems Examinations
Board
(BCS/ISEB) en el Reino Unido ofrece los siguientes programas de certificación:
Foundation, Advanced, Expert (en alianza con ISTQB)
Intermediate Certificate in Software Testing. Este certificado se considera como un
nivel intermedio entre los niveles Foundation y Advanced del ISQTB.
Certified Agile Tester (en alianza ISQI)
3.5.6 Instituto de Examinación para Ciencias Informáticas
Está situada en Holanda y ofrece programas de certificación orientados a la metodología
TMap (Test Management Approach):
TMAP NEXT Test Engineer
TMAP NEXT Test Manager
Estos certificados mencionados brindarán las habilidades suficientes para realizar un
análisis más detallado sobre los diferentes procesos de pruebas de software y ejecutarlos
de forma efectiva en el entorno en donde se esté trabajando. Además, estas
certificaciones ayudarán a ampliar el valor curricular de su carrera profesional como
Ingeniero de Pruebas de Software y abrirán puertas en cualquier empresa desarrolladora
de software.
39
3.16 Precepciones de un tester profesional
En este apartado, en la necesidad de investigar y tener como base a un tester profesional
para cualquier duda y sustento de información, se contactó a Miguel Ángel Meléndez
Hernández él cuenta con 26 años de edad y es Ingeniero en Tecnologías Computacionales
egresado del Tecnológico de Monterrey y cuenta con la maestría en administración de TI
con 5 años de experiencia en el área de testing.
El compartió su experiencia como tester y en percepción propia ¿por qué considera que
un tester es importante?.
Miguel Meléndez: Llegue a testing al final de mi carrera porque era el puesto que más
dinero podía proporcionarme en ese entonces, y tenía que pagar mi título
universitario, estaría dos meses ahí mientras junto lo necesario para luego iniciar una
maestría, ya tenía mi beca aprobada. Sin embargo después de conocer por sólo dos
meses el testing, me di cuenta que mi forma de pensamiento se empataba con lo que un
tester debe hacer, pensamiento crítico y pensamiento lateral, siempre he sido alguien
que cuestiona e incluso que desafía el status QA.
Así que después de dos meses como practicante, rechace mi beca de maestría y me
convertí en tester de tiempo completo, hoy 5 años después (y una maestría terminada)
puedo decirte que fue una de las mejores decisiones de mi vida.
Me he dado cuenta que yo tuve la suerte de conocer el testing, sin embargo uno de mis
objetivos es ser promotor del rol en nuestro país para que otros como yo tengan la
fortuna de estar informados sobre lo interesante, divertido y necesario que es el testing
en nuestro país.
¿Qué es un tester?
Para mí un tester es aquel que tiene la capacidad de cuestionar soluciones con el objetivo
40
de agregar valor a un producto. Alguien que no se contagia de suposiciones y que desafía
el status QA en todo momento.
¿Cuáles son sus funciones?
Encontrar errores.
Pensar en términos de riesgo.
Reportar defectos e información relevante.
Alertar sobre información relevante a quienes toman las decisiones.
¿Qué pruebas realiza y que herramientas hay y utiliza un tester?
En lo personal me enfocó en prueba funcionales, de seguridad y de usabilidad, pero un
tester puede especializarse en diversos aspectos al ser testing un área multidisciplinaria.
41
CAPÍTULO 4
RESULTADOS Y CONCLUSIONES
A continuación se detallan los resultados y conclusiones de la presente tesis, realizada la
investigación y alcanzados los objetivos se puede concluir que la tesis presenta una amplia
información para dar a conocer la importancia de la realización de testing dentro de un
sistema, esta tesis presenta a grandes rasgos cómo puede mejorar un sistema gracias a la
intervención de un tester, toda esta investigación servirá para orientar a nuevas empresas
a pensar primeramente en garantizar la calidad de los sistemas, para que el cliente quede
satisfecho y así una empresa va obteniendo prestigio y mayor terreno en el campo de las
TI gracias a la calidad de sus productos, se determina que un tester es imprescindible en
un equipo de desarrollo, ya que es el encargado de encontrar la mayor cantidad de
errores en un sistema previniendo futuros fallos y pérdidas monetarias.
Con respecto a lo investigado y lo que es en la vida real se puede determinar que las
empresas aún siguen dejando de lado la calidad de los sistemas, en la poca experiencia
desempeñada como tester pude darme cuenta que las empresas siguen dejando de lado
la calidad del producto creado, para evitarse problemas de tiempo y costos. Esto hace
pensar que hay un largo camino por recorrer, pero como resultado de esta investigación y
con respecto a la tesis se pretende ir acortando ese camino para impedir las evidentes
rupturas de empresas, todas por no tener como primer objetivo la calidad de sus
sistemas.
Esta tesis da como resultado una guía para personas interesadas en dedicarse a la
estupenda tarea de realizar pruebas y en caso de las empresas para ir considerando a
estas personas como parte fundamental de algún proyecto para la realización de un
sistema.
42
REFERENCIAS
Alejandro. (14 de Enero de 2014). Testeando Software. Obtenido de
http://testeandosoftware.com/istqb-que-es-cuales-son-los-niveles-de-certificacion/
Ariel Pasini, H. R. (Abril de 2006). Testing en aplicaciones web. Obtenido de
apasini,hramon,[email protected]
Barrera, M. A. (17 de Agosto de 2010). TESTING. Pruebas de software "TESTING".
Bressano, M. (Abril de 2012). slideshare. Obtenido de
http://es.slideshare.net/educar_bressano/testing-ing-gabriela-muoz
Carlos Blanco, J. H. (s.f.). ocw.unican. Recuperado el 23 de 04 de 2015, de
http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/practicas-
1/Practicas/p1-pruebasSistemasSoftware.pdf
Ceniceros, J. C. (7 de Agosto de 2012). La Verificación y Validación de Software. Obtenido de
http://juankenny.blogspot.mx/2012/08/vvs-la-verificacion-y-validacion-de.html
CES. (2009). Expertos en Testing. Recuperado el 25 de 04 de 2014, de
http://www.ces.com.uy/index.php/ique-es-el-testing/perfil-del-tester-
Corral, R. (21 de 10 de 2006). Pon un tester en tus proyectos. Obtenido de
http://geeks.ms/blogs/rcorral/archive/2006/10/21/Pon-un-tester-en-tus-proyectos.aspx
Dilane. (s.f.). Control de Calidad y Aseguramiento de la Calidad del Software. Recuperado el 26 de
04 de 2015, de https://sites.google.com/site/adilaneqa/home/calidad-del-
software/control-de-calidad-del-software/caracteristicas-del-tester
FIREBUG. (2010). Web Development Evolved. Obtenido de http://getfirebug.com/whatisfirebug
Garzas, J. (28 de Marzo de 2012). javiergarzas.com. Obtenido de
http://www.javiergarzas.com/2012/03/herramientas-para-pruebas-software.html
Ignacio Esmite, M. F. (s.f.). Automatización y Gestión de las Pruebas Funcionales. Recuperado el 24
de 04 de 2015, de http://www.ces.com.uy/documentos/imasd/CES-CACIC07-
Automatizacion_y_Gestion_Pruebas_Funcionales.pdf
JUnit. (04 de 12 de 2014). JUnit. Obtenido de http://junit.org/
Palacio, L. G. (05 de 10 de 209). MÉTODO PARA GENERAR CASOS DE PRUEBA FUNCIONAL.
31/08/2009. Medellin, Colombia, Colombia.
43
Pello, J. (19 de Abril de 2007). SoftQaNetwork. Obtenido de www.Softqanetwork.com
PMOinformatica. (5 de Noviembre de 2012). 5 Herramientas para la automatización de pruebas de
software. Obtenido de http://www.pmoinformatica.com/2012/11/5-herramientas-para-
la-automatizacion.html
Quintanilla, G. (27 de Noviembre de 2008). Mejores prácticas de desarrollo de software. Obtenido
de http://clases3gingsof.wikifoundry.com/page/Falla+-+Error+-+Defecto
Ramirez, F. G. (s.f.). Testing Ágil de Software con Herramientas Libres y Abiertas. Recuperado el 25
de 04 de 2015, de
http://www.academia.edu/2332917/Testing_%C3%81gil_de_Software_con_Herramientas
_Libres_y_Abiertas
S., J. Z. (21 de Enero de 2013). Niveles de Prueba del Software. Recuperado el 26 de 04 de 2014, de
https://pruebasdelsoftware.wordpress.com/
Sarco, J. P. (20 de Mayo de 2010). Articulos y Herramientas de Testing, pero en Español. Obtenido
de https://josepablosarco.wordpress.com/performance-testing/
SENA. (2015). SERVICIO NACIONAL DE APRENDISAJE. Recuperado el 2015, de
http://ciclodevidasoftware.wikispaces.com/Tipos+de+Pruebas
Sinibet. (18 de JUNIO de 2010). Topics de sistemas. Obtenido de
http://topicsistemas.blogspot.mx/2010/06/terminos-de-la-teoria-en-sistemas-caja.html
Tello, D. E. (30 de Marzo de 2011). Importancia de las pruebas de software. Tamaulipas:
CINVESTAV.
T-SYSTEM. (s.f.). Servicios de Pruebas – Pruebas duras para los sistemas de TI. Recuperado el 26 de
04 de 2015, de http://www.t-systems.com.mx/soluciones-industrias/servicios-de-pruebas-
pruebas-duras-para-los-sistemas-de-ti/557032
Vogel, L. (01 de 07 de 2014). Unit Testing with JUnit - Tutorial. Obtenido de
http://www.vogella.com/tutorials/JUnit/article.html
44
ANEXOS
Anexo 1
1. Algunos de los peores errores de la historia por no probar un producto
antes de liberarlo a producción.
Figura 26 Error 1
Figura 27. Error 2
45
Figura 28. Error 3