Nombre: Ficha:
Elkin Mosquera 1237740 - CAL!A! EN EL !E"A##$LL$ !E "$F%&A#E
Ac'i(i)a) )e a*ren)i+a,e:
Pruebas del software
"emana:
3
ACTIVIDADES DE REFLEXIÓN INICIAL ¿Qué importancia tienen las prueas !el so"t#are en la cali!a! !el mismo$
Son Importantes las pruebas realizadas al software debido a la gran utilidad que aportan aportan para identifica identificarr las fallas que pueda presentar presentar el sistema sistema en cada una de sus etapas y poder intervenir para una efectiva solución, además de esto también sirv sirven en para para que al mome moment nto o de entr entreg egar ar nuest nuestro ro trab trabaj ajo o soft softwa ware, re, este este se encuentre en un alto nivel de calidad. as pruebas buscan generar mayor confianza en el proceso de desarrollo de software, ya que de una u otra forma tratan de encontrar los errores que se puedan presentar durante la ejecución del mismo, para que sean mejorados. !sta es una de las etapas del ciclo de vida del software más importante, porque permiten verificar la calidad del software antes de que pueda salir al mercado y ser utilizados por los usuarios finales.
ACTIVIDADES DE A%R&%IACIÓN DEL C&N&CI'IENT& (AN)LISIS DE CAS&* !l proyecto de software para administrar la gestión de recursos "umanos de la empresa, ya pasó por las etapas de análisis, dise#o y desarrollo e ingresa a la etapa de pruebas, es all$ donde %amilo &ndrés como director del proyecto debe asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que pueda tener.
'ara 'ara inic inicia iarr esta esta etap etapa a es neces necesari ario o elab elabora orarr el plan plan de prueba pruebass para para este este proye proyect cto, o, donde donde se incl incluy uya( a( Iden Identitifificad cador or del del plan plan,, alcan alcance ce,, $tems $tems a probar probar,, estr estrat ateg egia ia,, cate catego gori riza zaci ción ón de la conf config igur urac ació ión, n, entr entreg egab able less )tan )tangi gibl bles es*, *, procedimientos especiales, recursos, cronograma, gestión de riesgos.
%LAN DE %R+E,AS AD'INISTRAR LA -ESTIÓN DE REC+RS&S .+'AN&S Intro!ucci/n ! plan de pruebas de Software se elabora con el fin de especificar, qué elementos o componentes se van a probar para que el grupo de trabajo pueda realizar el proceso de +alid +alidaci ación ón y +erif +erifica icació ción n de los requer requerimi imient entos os funcio funcional nales es y no funcio funcional nales es de la "erramienta Software para administrar la gestión de recursos "umanos. &demás, a través del plan de pruebas pruebas se puede continuar continuar con la trazabilidad trazabilidad de los requerimientos requerimientos,, con lo cual el grupo de trabajo, identifica el porcentaje de avance que se "a logrado "asta cierto momento. &l desarrollar el plan de pruebas, se puede obtener información sobre los erro errore res, s, defe defect ctos os o fall fallas as que que tien tiene e el prot protot otip ipo, o, as$ as$ se real realiz izan an las las corr correc ecci cion ones es pertinentes, segn el caso y se asegura la calidad del producto que se está entregando al cliente. !l plan de pruebas se aplica sobre el producto, es decir, el código fuente del Software para administrar la gestión de recursos "umanos, los resultados de las pruebas son son regi regist stra rado doss en un form format ato o deno denomi mina nado( do( -epo -eport rtes es de 'rue 'rueba bas. s. as as prue prueba bass a implementar son básicas, esto incluye las pruebas unitarias y de integración que son vitales para la validación del producto.
%rop/sito0 !l propósito del plan de pruebas planteado en este documento, es permitir permitir definir los lineamientos a seguir para realizar la planeación de la etapa de prue pruebas bas sobre sobre el proy proyect ecto o A!ministr A!ministraci/n aci/n !e Recursos Recursos .umanos1 .umanos1, plant plantean eando do una una estr estrat ateg egia ia que que cond conduzc uzca a al obje objetitivo vo enfo enfocad cado o en el aseguramiento de calidad del software. !l propósito del 'lan /aestro de 'ruebas es(
•
•
•
'roveer un artefacto central que gobierne la planeación y control del esfuerzo de pruebas. !ste define el enfoque general que será empleado para probar el software y para evaluar los resultados de esas pruebas, y es el plan de más alto nivel que será usado por los administradores para guiar y dirigir el trabajo de pruebas detallado. 'roveer visibilidad a los interesados en el esfuerzo de pruebas que "an tenido las consideraciones adecuadas para varios aspectos que orientan el esfuerzo de pruebas, y dónde es apropiado que los interesados aprueben el plan. !ste 'lan /aestro de 'ruebas también soporta los siguientes objetivos espec$ficos( Identificar los $tems que serán objeto de las pruebas.
•
•
•
!nmarcar la metodolog$a de pruebas que será utilizada
Identificar los recursos requeridos y proveer un estimado del esfuerzo de las pruebas. !laborar un listado de los elementos entregables del plan de pruebas.
•
Alcance !l plan maestro de pruebas describe el detalle de las diferentes pruebas a ser aplicadas, as$ como también las "erramientas y metodolog$as a utilizar en cada una de estas. as pruebas que serán realizadas son( •
•
•
•
Re2isi/n !e la !ocumentaci/n( %onsiste en revisar la calidad y completitud de los documentos insumo y casos de uso para la ejecución de las pruebas. %rueas +nitarias0 Se validaran las piezas individuales del software como una unidad independiente, bucles, condicionales, etc. %rueas !e inte3raci/n0 Se validara la integración entre los diferentes módulos que componen la solución con el fin de garantizar que su operación integrada es correcta. %rueas Funcionales (proce!imientos*0 Se validaran los procesos, reglas de negocio establecidas y los requerimientos funcionales. 4 Identificación de requerimientos funcionales. 4 0ener en cuenta los requerimientos no funcionales.
%rueas !e sistema0 as pruebas de sistema se determinarán en el momento que el 1utsourcing de 2esarrollo entregue el documento de -equerimientos no funcionales, y as$ determinar qué tipos de prueba se realizarán y a qué casos de uso se aplicarán. •
%rueas !e re3resi/n0 Se validara que el sistema mantenga su correcta funcionalidad debido a la incorporación de un ajuste, corrección o nuevo requerimiento. &dicionalmente y con el fin de centrar el plan de pruebas en ciertos factores que son cr$ticos y de mayor relevancia para el proyecto, se determinan los tipos de pruebas que se realizarán para el proyecto, dise#ando los factores de calidad y las pruebas especializadas para alcanzar estos atributos del software entregado. %on esta misión se identifican de acuerdo a las especificaciones del cliente los factores 'ara este proyecto de acuerdo a los requerimientos, se definen los siguientes factores en los que se enfocarán las pruebas( %orrección.
%onformidad.
3acilidad de 4so.
'ortabilidad.
3acilidad de 1peración.
Re"erencias 4 -4'( 'roceso 4nificado -ational 4 -equerimientos de Software. 4 !specificación de casos de uso. Au!iencia !n la parte de audiencia están involucradas y participan todas aquellas personas involucradas directamente en( Obtener objetivos. Denir acciones
.laneacin
A*robacin •
• • •
!esarrollo !e/nir .ruebas #eali+ar
E,ecucin
Medir los conocimientos Etapas Denir Procedimientos
Re"erencias %ronograma del 'royecto !specificación -equerimientos de Software( 4 -equerimientos funcionales del Software. 4 -equerimientos no funcionales del Software. • •
'isi/n !e las %rueas Conte5to !el %ro6ecto 6 Antece!entes -ealizar levantamiento y un posterior análisis de los procesos de &dministración de recursos "umanos, con el fin de plantear una arquitectura de solución tecnológica que permita la optimización, monitoreo y eficiencia de los procesos de negocio que constituyen y representan valor en las objetivos estratégicos de la organización. •
'isi/n !e las %rueas aplicale a este pro6ecto a misión de la evaluación para el presente proyecto se define enfocada al aseguramiento de la calidad de los componentes y artefactos tecnológicos desarrollados, de manera que estos cumplan con la especificación de los requerimientos del cliente. 'ara esto se definen los siguientes lineamientos que constituyen la misión y objetivos dentro este esfuerzo de pruebas( •
• • •
•
• •
2escubrir tantos errores como sea posible 5otificar acerca de los riesgos percibidos del proyecto !6aminar la aplicación para comprobar si "ace o no lo que se supone, debe "acer. 2e igual forma verificar si ésta "ace o no lo que se supone, no debe "acer. +alidar y +erificar a través de la comparación del resultado de las pruebas del aplicativo con el resultado que el mismo tendr$a que producir de acuerdo a su especificación. !valuar la calidad del producto y satisfacción de los interesados %umplir con los requerimientos del cliente
E2aluaci/n !e %rueas0
4 4 4 4
'ermitir detectar problemas desde el inicio de la especificación de requerimientos. 2isminuir riesgos. 1btener producto de calidad. Satisfacción del cliente.
Lo3ros0 4 4 4
a necesidad de optimización que presenta el cliente. 7estionar la ejecución de procesos. +erificar la confiabilidad de la información.
&dicionalmente e6isten unos motivadores puntuales que van a contribuir a que se construya un software que satisfaga los requerimientos del cliente de la manera más óptima posible y siguiendo un proceso adecuado para conseguirlo. !stos son( • • • • •
&seguramiento de la calidad. Solicitudes de cambios. -iesgos de calidad. +erificación de los casos de uso. %omprobación de los requerimientos funcionales y no funcionales
Elementos &7eti2o !e %rueas & continuación se listan los elementos )artefactos, entregables, documentos etc.* que serán objeto de prueba dentro del esfuerzo de pruebas( Fase Inicial • • • •
2ocumentación !specificación de -equerimientos !stimaciones /odelos 8 2iagramas
Diseñador
E,ecucin CEE$ .#EA"
%ERS%ECTIVA DE %R+E,AS %LANEADAS %asos e7ecuci/n !e la prueas
Hay Cambios
n!lisis de Pruebas
Diseñador de pruebas
E,ecucin lis'a )e chequeo #e(isin !ocumen'acin .ruebas )e in'eracin
"o Hay Cambios #rupo n!lisis de Pruebas
Hay Cambios
.ruebas )e 5uncionales
Hay Cambios
n!lisista de Pruebas "o Hay Cambios
.ruebas )e "is'ema .ruebas )e #en)imien'o .ruebas )e Hay Cambios
dministradores de Prueba "o Hay Cambios
#e*e'ir ciclo )e *ruebas
VISIÓN DE %R+E,AS !l plan de pruebas se basará en su totalidad en pruebas funcionales, instalación, regresión y otras teniendo en cuenta los requerimientos no funcionales.
Re2isi/n !e la !ocumentaci/n( a estrategia para realizar estas pruebas, consiste en la revisión de la documentación y casos de uso verificando su completitud y concordancia en la información que se encuentra en ellos. •
%rueas unitarias0 as estrategias para realizar estas pruebas consiste en generar casos de prueba necesarios( 'ara que cada sentencia o instrucción del programa se ejecute al menos una vez correctamente. 'ara que cada condición tenga por lo menos una vez un resultado verdadero y al menos una vez uno falso. 'ara probar varias veces el mismo bucle )en donde aplique* considerando los siguientes casos( Ignorar el bucle, pasar una vez, pasar dos veces, pasar n veces, pasar n89 veces y n:9 veces. •
•
•
•
%rueas "uncionales o !e proce!imientos0 a estrategia para realizar estas pruebas consiste en la elaboración y ejecución de Set de 'ruebas, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e inválidos que permitan verificar lo siguiente( 4 4so de datos válidos. 4 4so de datos inválidos. %rueas !e Re3resi/n0 a estrategia para realizar estas pruebas consiste en repetir las pruebas )funcionales y de carga* ejecutadas antes de corregir defectos o de a#adir nuevas funcionalidades, para comprobar que las modificaciones no provocan errores donde antes no los "ab$a.
%rueas !e Aceptaci/n as pruebas de aceptación se basarán en su totalidad en pruebas funcionales, instalación, y otras teniendo en cuenta los requerimientos funcionales las pruebas. &dicionalmente estas pruebas serán de caja negra.
•
Pruebas funcionales o de procedimientos: a estrategia para realizar estas
pruebas consiste en la elaboración y ejecución de Set de 'ruebas, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e inválidos que permitan verificar los casos de pruebas.
.ERRA'IENTAS DE %R+E,A ;erramientas técnicas para las pruebas enfocadas en la reducción de riegos.
Factor !e %ruea0
%onformidad
Técnica0
'ruebas de operación
Descripci/n( %on las pruebas de operación se garantiza que el usuario está bien capacitado en el manejo del software y además se lleva un registro para guardar los caminos no contemplados dentro de las pruebas previas del software, y con ello se tomarán las medidas adecuadas. Factor !e %ruea0
3acilidad de 4so
Técnica0
-evisiones
Descripci/n( Se debe incluir al cliente y
C/!i3o
%roceso0 4 -evisión paso a paso pseudo código.
Factor !e %ruea0
3acilidad de 1peración
Técnica0
'ruebas de -equerimientos
Descripci/n( +alidar los requerimientos no funcionales de ambiente recolectados con el cliente versus las caracter$sticas requeridas por el ambiente de producción.
Re:uerimientos "uncionales0 4
-+I
4
Tiempos !e respuesta;
4
'ensa7es;
%rueas !e Inte3raci/n as pruebas de integración que se realizaran durante el proceso de desarrollo de los componentes de software, deben seguir las siguientes pol$ticas y lineamientos de ejecución( •
•
•
Se tiene una fase de pruebas unitarias competa y aprobada para el inicio de las pruebas de integración. 'robar en primer lugar los componentes o módulos individuales del software y posteriormente y de manera progresiva se Irán agrupando "acia arriba y de manera funcional estos componentes para probar escenarios que impliquen varias funcionalidades de interacción entre los componentes, y se continuará as$ "asta llegar al nivel más alto de funcionalidad e integración. 'ara la ejecución de estas pruebas se utilizarán las siguientes técnicas(
&,
T=CNICA 'ruebas de %aja negra "AL!A
EN%#A!A .#$CE"$
.ERRA'IENTAS 4
2!'4-&- 8 -1=10 2! '-4!=&S 8 S!74I/I!501 2! +&-I&=!S
>4I%I1 2! ?@I01 A %oncordancia de los procedimientos del sistema con los requerimientos de usuario •
1ptimo manejo de e6cepciones y errores
•
3ácil seguimiento de la ejecución por medio de los traces.
&,
T=CNICA 'ruebas de -egresión
.ERRA'IENTAS 4
2!'4-&- 8 -1=10 2! '-4!=&S 8 S!74I/I!501 2! +&-I&=!S
>4I%I1 2! ?@I01 •
5o se detectan errores inyectados durante la integración del sistema
&,
T=CNICA istas de %"equeo
.ERRA'IENTAS istas de c"equeo con los items a comprobar para la integración
>4I%I1 2! ?@I01 •
!l 9BBC de los $tems "an sido c"equeados y cumplen con la condición para ser aprobados.
CRITERI&S DE ENTRADA > SALIDA •
Criterios !e Entra!a !el %lan 'aestro !e %rueas
4 4 4 4
Set de pruebas completo y claro. %laridad en el procedimiento para el desarrollo de las pruebas. 0oda la documentación requerida para la realización de las pruebas debe estar disponible.
Criterio de $alida del Plan Maestro de Pruebas
4
•
Due todos los set de pruebas dise#adas para cada caso de uso se ejecuten de manera e6itosa, cumpliendo los criterios de aceptación definidos para cada uno.
Suspensi/n 6 Reanu!aci/n
4 4 4 4
4na caracter$stica principal tiene un error que impide probar un área importante. !l entorno de pruebas no es lo suficientemente estable como para confiar en los resultados. !l entorno de pruebas es muy diferente del entorno de producción. 5o se puede instalar la nueva versión o un componente
%rueas !e Inte3ri!a! !e los !atos 6 ,ase !e !atos
1bjetivo de la 0áctica(
+erificar que los datos ingresados en las tablas de la base de datos no sufran. Verificar la integridad referencial de los datos.
0áctica(
Invocar cada acceso a la base de datos por medio de los procesos y métodos definidosE enviando datos válidos e inválidos. +erificar que cada proceso ocurra de manera correcta y que se retornen los datos esperados en cada caso espec$fico.
;erramientas necesarias(
%opia de -espaldo de la =ase de 2atos
%riterio de é6ito(
-etorno y no corrupción de los datos al e6ponerlos a los procesos funcionales del sistema.
%onsideraciones !speciales(
'robar con un m$nimo de cinco registros por tabla los procesos. 0odos los procesos serán invocados manualmente.
%R+E,AS DE F+NCI&NA'IENT&0 ?; @; ; B; ; ;
-esti/n !e Recursos .umanos; N/mina; Car3os; %resupuestos; Cuentas; Reportes;
-esti/n !e Recursos .umanos0 Re3istro !e %ersonal0
&7eti2o !e la Tctica0 Tctica0
+erificar que el personal adicionado a la base de datos. 'or medio del formulario de -egistro de 'ersonal ingresar en los campos los datos solicitados y presionar el botón de 7rabar registro.
•
Se enviarán datos incorrectos en los campos para verificar que los avisos de información inválida sean mostrados. •
.erramientas necesarias0 Criterio !e é5ito0
Consi!eracio nes Especiales0
,s:ue!a !e %ersonal;
5inguna. Se revisará la tabla de 'ersonal de la base de datos y se verificará que el registro diligenciado en el formulario "aya sido adicionado correctamente. !n caso de enviar datos inválidos el registro no debe "aber sido adicionado a la tabla de 'ersonal. 5inguna
+erificar el registro del personal.
&7eti2o !e la Tctica0 Tctica0
'or medio del formulario de -egistro de 'ersonal se podrán buscar registros de la base de datos. Si no se encuentran registrados avisara por medio de un mensaje.
•
Criterio !e é5ito0
!n el formulario de Re3istro !e %ersonal, se debe cargar la información del registro completo encontrado. !n caso de enviar datos inválidos el motor de bsqueda no cargará ningn registro en el formulario de -egistro de 'ersonal.
Consi!eracione s Especiales0
5inguna
'o!i"icaci/n !e %ersonal;
+erificar la correcta modificación el registro del personal.
&7eti2o !e la Tctica0 Tctica0
'or medio del formulario de -egistro de 'ersonal se podrán /odificar registros de la base de datos.
•
Criterio !e é5ito0
!n el formulario de Re3istro !e %ersonal, se debe cargar la información del registro completo encontrado. !n caso de enviar datos inválidos el motor de bsqueda no cargará ningn registro en el formulario de Re3istro !e %ersonal.
Consi!eracione s Especiales0
5inguna
Eliminaci/n !e %ersonal
&7eti2o !e la Tctica0
+erificar que la eliminación de un registro del personal se ejecute correctamente.
Tctica0
•
4na vez se ubique el registro a eliminar por medio de la función =squeda de 'ersonalF descrita anteriormente. Se presionará el botón !liminarF.
Criterio !e é5ito0
Se revisará la tabla de Registro de Personal de la base de datos y se verificará que el registro "aya sido eliminado de la base de datos.
Consi!eracione s Especiales0
5inguna
N/mina
&7eti2o !e la Tctica0
+erificar que el proceso de nómina se lleve a cabo e6itosamente.
Tctica0
•
'or medio del formulario de 7enerar se realizan la nómina de personal. •
'uede ser( Duincenal, /ensual.
Criterio !e é5ito0
Se revisará la tabla de 5omina de la base de datos y se verificará que el registro diligenciado en el formulario "aya sido adicionado correctamente. !n caso de enviar datos inválidos el registro no debe "aber sido adicionado a la tabla de 5omina.
Consi!eracione s Especiales0
5inguna
Car3os
Re3istro !e Car3os
&7eti2o !e la Tctica0 Tctica0
+erificar que el cargo sea adicionado a la base de datos. 'or medio del formulario de %argos ingresar en los campos los datos solicitados y presionar el botón de 7rabar registro.
•
Se enviarán datos incorrectos en los campos para verificar que los avisos de información inválida sean mostrados. •
Criterio !e é5ito0
Se revisará la tabla de %argos de la base de datos y se verificará que el registro diligenciado en el formulario "aya sido adicionado correctamente. !n caso de enviar datos inválidos el registro no debe "aber sido adicionado a la tabla de %argos.
Consi!eracio nes Especiales0
5inguna
,s:ue!a !e Car3os;
+erificar el registro de los cargos registrados.
&7eti2o !e la Tctica0 Tctica0
'or medio del formulario de %argos se podrán buscar registros de la base de datos. Si no se encuentran registrados avisara por medio de un mensaje.
•
Criterio !e é5ito0
!n el formulario de %argos, se debe cargar la información del registro completo encontrado. !n caso de enviar datos inválidos el motor de bsqueda no cargará ningn registro en el formulario de %argos.
Consi!eracione s Especiales0
5inguna
'o!i"icaci/n !e Car3os;
&7eti2o !e la Tctica0 Tctica0
+erificar la correcta modificación el registro del %argo. 'or medio del formulario de %argos se podrán /odificar registros de la base de datos.
•
Criterio !e é5ito0
!n el formulario de %argos, se debe cargar la información del registro completo encontrado. !n caso de enviar datos inválidos el motor de bsqueda no cargará ningn registro en el formulario de %argos.
Consi!eracione s Especiales0
5inguna
Eliminaci/n !e Car3os;
&7eti2o !e la Tctica0 Tctica0
+erificar que la eliminación de un registro de cargos 4na vez se ubique el registro a eliminar por medio de la función =squeda de %argosF descrita anteriormente. Se presionará el botón !liminarF.
•
Criterio !e é5ito0
Se revisará la tabla de %argos de la base de datos y se verificará que el registro "aya sido eliminado de la base de datos.
Consi!eracione s Especiales0
5inguna
•
%resupuestos
&7eti2o !e la Tctica0
+erificar que los registros de presupuesto ingresos y egresos se registren.
Tctica0
•
'or medio del formulario de 'resupuesto se realizan registros de ingresos y egresos. •
'uede ser( /ensual.
Criterio !e é5ito0
Se revisará la tabla de 'resupuesto de la base de datos y se verificará que el registro diligenciado en el formulario "aya sido adicionado correctamente. !n caso de enviar datos inválidos el registro no debe "aber sido adicionado a la tabla de 'resupuesto.
Consi!eracione s Especiales0
5inguna
•
Cuentas Re3istro !e Cuentas
&7eti2o !e la Tctica0 Tctica0
+erificar el registro de las cuentas de la empresa. 'or medio del formulario de %uentas se realizan los registros.
•
Criterio !e é5ito0
Se revisará la tabla de %uentas de la base de datos y se verificará que el registro diligenciado en el formulario "aya sido adicionado correctamente. !n caso de enviar datos inválidos el registro no debe "aber sido adicionado a la tabla de %uentas.
Consi!eracione s Especiales0
5inguna
•
Au!itoria
&7eti2o !e la Tctica0
+erificar los registros de las operaciones realizadas en la ejecución del software.
Tctica0
•
'or medio del formulario de &uditoria se podrán visualizar los registros.
Criterio !e é5ito0
Se revisará la tabla de &uditoria de la base de datos y se verificará que las operaciones realizadas durante la ejecución del software sean registradas detalladamente.
Consi!eracione s Especiales0
5inguna
•
Reportes
&7eti2o !e la Tctica0
+erificar que se realicen los reportes de todos los datos registrados en las tablas de la base de datos.
Tctica0
•
'or medio del formulario de -eportes se realizan los reportes de( 4 7estión de -ecursos ;umanos. 4 5ómina. 4 %argos. 4 'resupuestos. 4 %uentas. 4 &uditoria
Criterio !e é5ito0
%onsulta de los registros de las tablas.
Consi!eracione s Especiales0
5inguna
%rueas !e Control !e Se3uri!a! 6 Acceso;
&7eti2o !e la Tctica0
-evisar que el sistema de seguridad de la aplicación ofrezca un nivel confiable para la empresa.
Tctica0
Se digitará la clave de acceso a la aplicación y se revisará su desempe#o. Se tratará de ingresar por medio de datos inválidos.
.erramientas necesarias0
5inguna
Criterio !e é5ito0
!l sistema no debe permitir por ningn motivo el ingreso al interior a través de contrase#as incorrectas ni por medio de trucos que violen la seguridad del aplicativo.
Consi!eracione s Especiales0
5inguna.
%rueas !e Falla 6 Recuperaci/n;
&7eti2o !e la Tctica0
'robar el sistema en computadores con diferentes tipos de configuración de "ardware para determinar su desempe#o y funcionamiento.
Tctica0
Se ejecutará el sistema en tres equipos diferentes, posteriormente se probará su rendimiento en condiciones m$nimas de "ardware.
.erramientas necesarias0
5inguna.
Criterio !e é5ito0
Se espera obtener un desempe#o no tan variable entre máquinas, especialmente un buen comportamiento en el computador con unos recursos de "ardware por debajo de los que tendrá la máquina donde residirá el sistema.
Consi!eracione s Especiales0
os equipos donde se realizará la prueba tendrán grandes diferencias de recursos.
RES%&NSA,ILIDADES > EQ+I%& DE TRA,A<& %ersonas 6 Roles
%ontar con el personal calificado para llevar a cabo cada una de las etapas descritas en el plan de pruebas. REC+RS&S .+'AN&S RES%&NSA,ILIDADES ES%ECGFICAS & C&'ENTARI&S
R&L
&dministrador de 'ruebas
2ise#ador de 'ruebas
&nalista de 'ruebas
&dministra el esfuerzo de las pruebas, aprueba los criterios de entrada y salida a las pruebas, monitorea avance del esfuerzo de pruebas, aprueba los casos de prueba, gestiona el alcance y misión de las pruebas, %ertifica el nivel de calidad del producto construido. !s el responsable de dise#ar los set de pruebas )estructura y enfoque* que se realizarán al sistema para una certificar que se construyó un producto que satisface los requerimientos definidos. !s el responsable de ejecutar los casos de prueba y realizar los reportes correspondientes sobre esta ejecución. -ealizar documentación técnica de las pruebas.
•
•
•
•
-esti/n !el ries3o &lgunos de los riesgos más comunes durante la fase de pruebas suelen ser( 3alta de recursos y baja competencia en pruebas 3alta de los recursos necesarios para ejecutar las pruebas segn el plan 0iempo reducido asignado a la fase de pruebas %ambios frecuentes en la definición de los objetivos y alcance del plan de pruebas 3alta de coordinación entre los equipos de desarrollo y testing 3alta de e6periencia con nuevas tecnolog$as, "erramientas, lenguajes de programación. 4na caracter$stica muy deseable de un equipo de pruebas es la pro8actividad, Incluso antes de que el software comience a desarrollarse, el equipo puede involucrarse en las
distintas etapas de definición para conocer más en profundidad el proyecto as$ como comenzar a definir estrategias de pruebas. /edidas a tomar para obtener los mejores resultados podr$an ser(
Inter2enci/n temprana !el e:uipo !e prueas en el pro6ecto a inclusión del equipo de pruebas en las etapas iniciales del desarrollo del producto ayudará a obtener mayor conocimiento del mismo as$ como permitirá detectar posibles defectos en etapas tempranas, por lo que el coste de resolución de los mismos será inferior.
@; %reparaci/n !e las prueas &ntes de comenzar el desarrollo del producto, el equipo de pruebas podrá comenzar a dise#ar el plan a seguir as$ como identificar futuras necesidades. ;erramientas a utilizar, configuración de entornos
; De"inici/n !e los criterios !e entra!a H sali!a 5o refiriéndose a los datos, sino los puntos de unión con otras plataformas e integraciones con terceros. !s muy til definir y mantener las interfaces y mecanismos de comunicación con terceros para evitar futuros problemas.
B; Re:uerimientos !e prueas 2esde el equipo de pruebas, se fomentará el uso de estándares, tecnolog$as abiertas, as$ como buenas prácticas de desarrollo
; -esti/n !e !e"ectos 4na tarea de gran importancia es el seguimiento y priorización de los defectos encontrados. !stos deben ser incluidos en los planings de siguientes iteraciones para que sean resueltos. &demás, deben ser trazados para conocer cuándo y en qué versión "an sido resueltos. Siguiendo estos puntos, conseguiremos reducir en gran medida los riesgos más comunes durante el desarrollo de software. ;ay que tener en cuenta que se debe trabajar en sincron$a con los demás grupos implicados, desde la parte de gestión, pasando por desarrollo, pruebas, despliegue, unos dependen de otros y los problemas de unos se propagan a otros.
