MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_01D56ECB.567A4DD0" Este documento es una página web de un solo archivo, también conocido como "archivo de almacenamiento web". Si está viendo este mensaje, su explorador o editor no admite archivos de almacenamiento web. Descargue un explorador que admita este tipo de archivos. ------=_NextPart_01D56ECB.567A4DD0 Content-Location: file:///C:/E1771A94/PUBLICACION13VOL3.NUM34.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
Análisis de la aplicación de pruebas funcionales y=
pruebas
de usabilidad de software en el desarrollo de sistemas web
Analysis of the
application of functional tests and usability tests of software in the
development of web systems
=
Natalia
Patricia Layedra Larrea.[1], =
Marco
Vinicio Ramos Valencia. [2=
],
Blanca Faustina Hidalgo Ponce. [3] &=
amp;
Angela Elizabeth Samaniego Orozco.[4]
Recibido: 07-07-2019 / Revisado: 17-07-2019 /Aceptado: 12-08-2019/
Publicado: 10-09-2019
The main objective of this work is to analyze the
application of functional tests and usability test son web systems. In orde=
r to
apply this test, a web system was developed to manage ecclesiastic meetings=
for
Riobambas Biblical Church.
The system was developed using SCRUM methodology,
which allowed to make an analysis of the requirements, both in development
priority and in the time in which each one is carried out; plus, AngularJS =
technology
was used for the front end, and programming language JAVA was used for the =
back
end on Netbeans 8.2 development environment, and RestFULL sevices which all=
ow
connection between front end and back end. Finally, PostgreSQL was used as
database management system.
Functionality= tests and usability tests were applied on the web system. In order to obta= in the results for the usability a survey was taken by a group of 20 people= , with different roles in the system, of which 90.14% said that the system = is easy to use. Functionality tests were applied on the authentication modu= le, considering that there are several user roles. As a result of these tes= ts, user could use the system correctly as it was expected.
Resumen
El
objetivo general del presente trabajo es analizar la aplicación de pruebas
funcionales y pruebas de usabilidad en sistemas web. Para aplicar dichas pr=
uebas
se desarrolló un sistema web para la gestión de reuniones eclesiásticas par=
a la
Iglesia Bíblica Riobamba.
El
sistema fue desarrollado utilizando la metodología de desarrollo SCRUM, que=
permitió
realizar un análisis de los requerimientos levantados tanto en prioridad de
desarrollo como en el tiempo en que se realiza cada uno; además, se utilizó=
la
tecnología AngularJS para el front end, mientras que para el back end se
trabajó con el lenguaje de programación JAVA en el entorno de desarrollo
Netbeans 8.2, y servicios RestFULL que permiten la conexión entre el front =
end
y el back end. Finalmente, para la gestión de la base de datos se utilizó
PostgreSQL.
Sobre
el sistema se han ejecutado pruebas de funcionamiento y usabilidad. Para
obtener los resultados de la usabilidad del sistema se aplicó una encuesta =
de
usabilidad a un grupo de 20 usuarios con distintos roles dentro del sistema=
, de
los cuales el 90.14% manifestaron que pudieron usarlo fácilmente. Las prueb=
as
de funcionamiento se aplicaron en el módulo de autenticación de usuarios,
considerando que existen varios roles. Como resultado de las pruebas de
funcionamiento se obtuvo un funcionamiento adecuado del módulo, en base a lo
esperado por los usuarios.
Palabras
claves:
Desarrollo de software, programación, pruebas de software, pruebas de
funcionamiento, pruebas de usabilidad.
Introducción
=
Para que un proyecto de software sea de calidad debe cumplir con tod=
os
los requisitos que el usuario haya solicita en la primera etapa de
levantamiento de necesidades. La industria crece a pasos agigantados y por =
ello
los desarrolladores deben utilizar diferentes formas de garantizar la calid=
ad
de su producto desarrollado.
=
Según (Pressman, 2002) la calidad del software es la concordancia c=
on
los requerimientos funcionales y de rendimiento explícitamente establecidos,
con los estándares de desarrollo explícitamente documentados y con las cara=
cterísticas
implícitas que se espera de todo software desarrollado profesionalmente.
=
En este contexto, es importante e imprescindible planificar como par=
te
del proyecto la aplicación de pruebas que verifiquen el funcionamiento corr=
ecto
del sistema, pero además se debe tomar en cuenta que los usuarios puedan us=
ar
fácilmente el mismo, se debe verificar que el sistema refleje la naturaleza
propia del entorno que va a cubrir el sistema, y que los usuarios se sientan
identificados con su uso.
=
La usabilidad se define como la capacidad de un software de ser
comprendido, aprendido, usado y ser atractivo para el usuario, en condicion=
es
específicas de uso (International Organization for Standardization ISO 9126,
2001).
=
Hay muchos tipos de negocio, pero en el desarrollo de software, la
calidad es esencial para el éxito. Para garantizar este éxito, la función de
testeo es vital. Los tests de software ayudan a los equipos a evaluar el
software con los requerimientos e información recogida de los usuarios
(ŤTécnicas de testeo de software y herramientasť, 2017).
=
Existen varios tipos de pruebas y muchas herramientas que ayudan a l=
os
desarrolladores a aplicar los tests para verificar la calidad del sistema
desarrollado. Las pruebas utilizadas en este trabajo son:
=
=
Pruebas de usabilidad
=
Una prueba de usabilidad es la capacidad de que un producto software
pueda ser aprendido, entendido y atractivo por el usuario que lo utiliza, d=
onde
de forma individual se evalúa esas características, una forma común de hace=
rlo
es observando a las personas mientras utilizan el producto software analiza=
ndo
y evaluando como se desempeńan en su uso al igual que en su aspecto, cada u=
no
de los usuarios se pueden categorizar según su nivel de conocimiento del
sistema (Sánchez, 2012).
=
Para la realización de las pruebas de usabilidad existen 4 métodos p=
ara
realizar este tipo de evoluciones, donde la que tiene una prioridad más alt=
a es
la evaluación heurística ya que en esta permite evaluar de forma más rápida=
las
necesidades en la interfaz y genera costos menores, se tiene también la
evaluación por prototipos es el utilizar herramientas software que permita
evaluar las características de la interfaz del sistema en conjunto con la
evaluación heurística, también se tiene pruebas de usuario simplificado y
laboratorios de usabilidad (Sánchez, 2012)
=
=
Pruebas de funcionamiento
=
Las pruebas funcionamiento se encargan principalmente de verificar q=
ue
las funcionales desarrolladas en el sistema cumplan con sus especificacione=
s,
las pruebas se basan en los requerimientos funcionales o metáforas los mism=
os
que puede estar o no dementados e inclusive sobre un módulo seleccionado del
sistema, en las pruebas de este tipo se aplican por lo genera pruebas de ca=
ja
negra ya que lo que se considera en si es el comportamiento externo del
producto software. (pmoinformatica, 2014).
=
Las pruebas de funcionamiento se pueden realizar de forma manual o
automatizada, pero sin embargo es necesario que se siga un procedimiento pa=
ra
la ejecución de las mismas como lo sugiere Kibernum en su página, para la
ejecución de la prueba primero se debe realizar una análisis de los
requerimientos a evaluar, para proceder en lo posterior a la realización de=
un
plan de pruebas en el cual se debe especificar como se van a realizar las
mismas y las métricas de aceptación de las pruebas, para lo posterior poder
ejecutar el dicho plan dentro del cual se pueden encontrar incidencias que =
se
reportarán mediante la realización de un reporte de cierre. (Kibernum Chile,
2015).
=
=
Otros tipos de pruebas son:
=
=
Prueba unitaria
=
La prueba unitaria se aplica en el elemento más pequeńo de un sistem=
a,
cada componente es testeado para asegurar que funciona correctamente.
Normalmente desarrolla una única función cohesiva. La función de la prueba
unitaria es de analizar cada pequeńa parte y testear que funciona correctam=
ente
(ŤTécnicas de testeo de software y herramientasť, 2017).
=
Prueba de caja negra
=
Es una técnica de pruebas de software en la cual la funcionalidad se
verifica sin tomar en cuenta la estructura interna de código, detalles de
implementación o escenarios de ejecución internos en el software. En las
pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del
sistema, sin preocuparnos en tener conocimiento de la estructura interna del
programa de software (ŤPruebas de Caja Negra y un enfoque prácticoť, 2017).=
=
La aplicación web desarrollada para este trabajo cuenta con un módul=
o de
autenticación, permitiendo de esta forma que la información que manejará el
sistema solo pueda ser visualizada por el usuario y el pastor, dando así el
resguardo de la información solo para la parte interesada y no esté disponi=
ble
para otros, con fines dańinos o usos incorrectos.
=
El módulo de miembros permite registrar la información personal, el
domicilio y su ubicación y la participación activa que tiene en la iglesia,
todo esto de cada uno de los miembros de la iglesia.
=
El módulo de reuniones permite gestionar la creación de la reunión c=
on
la ubicación, permite modificar o suspender una reunión, de cada una de las=
reuniones
se deberá registrar el lugar donde se realiza, la persona que se encuentra a
cargo de la reunión y llevar un registro del día y la hora en que se da la
reunión.
=
El módulo de Diezmos y Ofrendas proporciona la facilidad de registra=
r el
número total de miembros que asisten a la reunión, la fecha en que se dio, =
el
número de Biblias que estuvieron en la reunión y el valor de ofrendas
recolectadas, permitiendo de dicha manera que los informes que se entregan
sobre estos datos recolectados se los entregue de forma oportuna, eficiente=
y
con un formato general, facilitando así la realización del informe económico
global de la iglesia.
=
El módulo de Peticiones y Visitas admite que se controle la ayuda a =
cada
uno de los miembros o personas que la necesiten ya sea esta de oración o
visitas.
=
El sistema también cuenta con un módulo de reportes los mismos que
facilitan la visualización de la información que se necesita para la
realización de las actividades de la iglesia, que se debe presentar cada ci=
erto
periodo de tiempo, ya sean de miembros de la Iglesia, Ofrendas y diezmos o =
de
las reuniones.
=
Metodología
En el desarr= ollo de este trabajo, después de haber terminado el sistema web para gestión de reuniones eclesiásticas, se aplicaron las pruebas tanto funcionales como de usabilidad para verificar que los requerimientos levantados en la fase inic= ial, se cumplan, y que el sistema haya alcanzado un alto porcentaje de calidad.<= o:p>
Pruebas
funcionales
=
Para la aplicación de las pruebas funcionales se siguen los pasos que
propone Cindy Campos de la Universidad Nacional Autónoma de México (Campos
Chiu, 2015), permitiendo definir adecuadamente como se realizaran y el alca=
nce
que tendrá el desarrollo de las mismas. De los puntos propuestos por Cindy
Campos se tomarán solo los que apliquen ya que las pruebas se realizan sobr=
e un
módulo en específico y no sobre todo el sistema.
=
Las pruebas se ejecutan de forma modular con técnicas de caja negra,
teniendo así datos que permiten verificarán la funcionalidad del módulo a p=
robar.
Para ejecutar las pruebas funcionales el módulo seleccionado es el de
autenticación y el de registro de asistencia con los diferentes roles. El
sistema cuenta con 4 roles de usuario: Administrador / Pastor, Miembro, Líd=
er de
Ministerio y Líder de Reunión.
=
Para realizar las pruebas se procede a la identificación de los
atributos o campos que se deben completar, para determinar los valores de
entrada y los valores de salida de la prueba, para los requerimientos
analizados el formulario implementado para las sesiones cuenta con 3 campos=
que
son el usuario, la contraseńa y el rol del usuario a autentificarse, mientr=
as
que para el registro de la asistencia y ofrendas el formulario cuenta con 5
campos que son genéricos en todos los roles, y un campo que permite selecci=
onar
la reunión en la cual se registrará la asistencia.
= Una vez determinados los campos a ingresar para las pruebas se reali= za la valoración de los atributos con los que se ejecutaran las pruebas tanto = con valores correctos como valores donde la prueba debe resultar fallida, con l= os que se espera tener los resultados esperados en las pruebas de aceptación.<= o:p>
Automatización
de las pruebas funcionales
=
Las pruebas de funcionamiento pueden ser realizan de forma manual o
mediante la ayuda de un software en el cual se puede automatizar las prueba=
s y
determinar si cumplen con los valores definidos para que se cumpla el proce=
so
para ello, mediante la utilización de las librerías de Selenium, para java.=
=
Selenium es una librería que permite ejecutar pruebas sobre los
formularios del sistema que se abre mediante el llamado de un navegador par=
a lo
cual cuenta con conectores dependiendo el navegador sobre los cuales se
ejecutan.
Ejecución
de las pruebas funcionales
=
Durante la ejecución de las pruebas previamente automatizadas es
necesario que se tome en consideración que a pesar de que se analice un fal=
lo o
un éxito de la prueba, estas deben terminar el proceso codificado.
=
Por ejemplo, para el módulo de autentificación de usuarios en el cua=
l,
la prueba satisfactoria será que un usuario que existe en el sistema pueda
ingresar a pantalla principal de su rol y la prueba de fallo será que un
usuario que no exista o este un dato mal ingresado no se le de paso para la
sesión de usuario.
=
De un total de 14 pruebas automatizadas, las cuales no presentaron
errores en su ejecución, mostraron un funcionamiento que cumple con lo
esperado, aun cuando la prueba sea para probar un fracaso. Por ende, se pue=
de
decir que la aplicación está cumpliendo con la funcionalidad implementada de
forma satisfactoria, teniendo en consideración las pruebas de aceptación qu=
e se
han generado para el módulo de autenticación y registro de asistencias y
ofrendas de una reunión.
=
Una de las características principales cuando se ejecuta pruebas
automatizadas con el fin de probar una o varias funcionalidades del sistema=
, es
la rapidez con la que se ejecuta la prueba en la funcionalidad seleccionada.
Como se tiene un total de 14 pruebas funcionales implementadas de forma
automatizada se realiza la medición del tiempo que toma en ejecutar dichas
pruebas.
Pruebas
de usabilidad
=
Las pruebas de usabilidad son una herramienta que permite determinar=
si
el sistema desarrollado para Iglesia Bíblica Riobamba es usable por los
usuarios finales. Estas pruebas se aplicaron basándose en los criterios de
evaluación según el modelo desarrollado por Felipe Almazán y Juan Camus (Fe=
lipe
Almázan, 2008), para el gobierno chileno.
=
De las 7 categorías que se proponen solo se evaluaron 6, ya que la
categoría de búsqueda no aplica para el sistema debido a que el sistema se =
ha
desplegado de forma local y sin un dominio aun, o accesos públicos para su =
uso,
El test cuenta con un total de 19 preguntas las que en base a la propuesta
antes mencionada se las ha modificado para hacerlas preguntas cerradas para
obtener resultados equitativos y cualitativos para su posterior análisis y
determinar si el sistema es usable o no.
=
El tamańo de los sujetos de la experimentación para aplicar la encue=
sta,
se calcula mediante la utilización de la fórmula:
=
=
=
=
=
Donde:
=
=
n =3D Es el tamańo de la muestra a calcular.
=
Z =3D Nivel de confianza deseado.
=
N =3D Tamańo de la población.
=
e =3D=
Es el
error muestral.
=
<=
span
lang=3DES-EC style=3D'font-size:11.0pt;line-height:115%;font-family:"Calibr=
i",sans-serif;
mso-ascii-theme-font:minor-latin;mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";mso-bidi-theme-font:minor-bidi;
position:relative;top:5.5pt;mso-text-raise:-5.5pt;mso-ansi-language:ES-EC;
mso-fareast-language:ES;mso-bidi-language:AR-SA'>
=
=
Los valores con los que se trabajan para obtener el tamańo de la mue=
stra
son:
=
Z=3D 1.96 para el 95% de confianza
=
N=3D 120 personas
=
e=3D =
0.10
para el 10%.
=
𝜎=3D 0.25
=
=
=
=
Dentro de la muestra calculada se toma en consi=
deración
los roles con los que cuenta el sistema y se realiza una tabla con el númer=
o de
personas de cada rol que desarrollarán la prueba como se puede ver en la Ta=
bla
1, ya que se tomará una muestra representativa de cada uno de ellos.
=
Tabla 1. =
span>Roles de usuarios del
sistema
Rol |
No. Personas |
Muestra |
Pastor |
1 |
1 |
Líder de Ministerio |
3 |
2 |
Líder de Reunión |
11 |
7 |
Miembro |
|
10 |
|
Total |
20 |
<=
b>Fuente: Información otorgada por miembros de la Iglesia
<=
b>Elaborado por: Autores
=
=
La distribución presentada se ha realizado de t=
al
forma que exista variedad en los roles de usuario que ingresarán al sistema=
.
Resultados
Para la
realización del análisis de la prueba de usabilidad se tabularon los result=
ados
para obtener una valoración por categoría, teniendo a evaluar de un total d=
e 6
categorías que se seleccionaron para este proceso, y con ellas determinar la
usabilidad del sistema.
Para la
evaluación de cada una de las categorías se estableció preguntas cerradas de
las cuales se contaron los resultados y se cuantificaron en porcentajes.
En cada
categoría se puede apreciar una tabla con el porcentaje de respuestas obten=
idas
de los encuestados:
Categoría
Identidad
Tabla
2. Tabulación de
respuestas Categoría Identidad
Pregunta |
Si |
No |
=
1.=
żCon la información q=
ue
se ofrece en pantalla, es posible saber a qué institución o empresa
corresponde el sitio web? |
100%
|
0%
|
=
2.=
żExisten elementos
gráficos o de texto que se identifiquen con la empresa o institución a la=
que
pertenece el sitio? |
100%
|
0%
|
=
3.=
żLos colores
predominantes en el sitio web se relacionan con la institución? |
75%
|
25%
|
=
4.=
żCree usted que los
elementos que muestra en las páginas se encuentran en armonía? |
95%
|
5%
|
=
5.=
żDistingue alguna ima=
gen
que represente (logotipo) a la institución y que aparece en un lugar
importante dentro de la página? |
100%
|
0%
|
=
6.=
Si tuviera que
contactarse con el pastor de la iglesia, żCuenta el sitio web con alguna
información como teléfono o dirección para hacerlo? |
100%
|
0%
|
Porcentaje
Total |
95%
|
5%
|
<=
b>Fuente: Resultados de encuestas
<=
b>Elaborado por: Autores
Categoría
Contenido
Tabla
3. Tabulación de respuestas Categoría Contenido
Pregunta |
Si |
No |
1. żCree usted que el sitio web
cuenta con información específica sobre las actividades que realizan para=
que
personas ajenas a la institución puedan conocer de la misma? |
100%
|
0%
|
2. żLogra identificar en que parte
del sistema se encuentra y que enlaces aún no ha visitado? |
90%
|
10%
|
3. En los enlaces que se ofrece p=
ara
acceder al contenido, żCree usted que son lo suficientemente descriptivos=
de
la página o acción a la que enlaza |
90%
|
10%
|
Porcentaje
Total |
93.33%
|
6.67%
|
Fuente: Resultados de
encuestas
Elaborado por: Autores
Categoría
Navegación
Tabla
4. Tabulación de respuestas Categoría Navegación
Pregunta |
Si |
No |
1. żExisten elementos dentro de l=
as
páginas, que le permitan saber exactamente dónde se encuentra dentro de e=
ste
sitio y cómo volver atrás sin usar los botones del navegador? |
75%
|
25%
|
2. żExisten elementos que le perm=
itan
regresar atrás sin la utilización de los botones del navegador? |
65%
|
35%
|
Porcentaje
Total |
70%
|
30%
|
Fuente: Resultados de
encuestas
Elaborado por: Autores
Categoría
Gráfica Web
Tabla
5. Tabulación de respuestas Categoría Gráfica Web
Pregunta |
Si |
No |
1. żLas imágenes y graficas que se
muestran en el sistema tienen un tamańo uniforme? |
85%
|
15%
|
2. żCree usted que el uso de imág=
enes
tarda la carga del entorno del sistema? |
85%
|
15%
|
3. Considera usted que gráficamen=
te y
estéticamente el entorno se encuentra equilibrado? |
90%
|
10%
|
Porcentaje
Total |
86.67%
|
13.33%
|
Fuente: Resultados de
encuestas
Elaborado p=
or:
Autores
Categoría Feedback
Tabla
6. Tabulación de respuestas Categoría Feedback
Pregunta |
Si |
No |
1. żAl completar un formulario o =
una
acción de las funcionalidades se presenta algún mensaje de satisfacción o=
no?
|
95%
|
5%
|
2. żEl sistema cuenta con alguna
forma de lograr contactarse con el pastor de la congregación para personas
ajenas al sistema? |
100%
|
0%
|
Porcentaje
Total |
97.5%
|
2.5%
|
Fuente: Resultados de
encuestas
Elaborado p=
or:
Autores
Categoría
Utilidad
Tabla
7. Tabulación de respuestas Categoría Utilidad
Pregunta |
Si |
No |
1. Al mirar por primera vez el si=
tio
web puede identificar el objetivo por el cual se ha implementado? |
95% |
5% |
2. żCree usted que las
funcionalidades implementadas en el sistema han sido de ayuda para usted?=
|
100% |
0% |
3. żCree usted que el sistema pue=
de
ayudar de forma positiva al desarrollo de las actividades de la Iglesia? =
|
100% |
0% |
Porcentaje
Total |
98.33% |
1.67% |
Fuente: Resultados de
encuestas
Elaborado p=
or:
Autores
Para determi=
nar
el porcentaje de usabilidad total del sistema implementado se promediaron l=
os
porcentajes obtenidos de las 6 categorías evaluadas, este resumen se puede
apreciar en la Tabla 8.
Tabla
8. Tabulación total de respuestas de la encuesta de usabilidad
Categoría |
Si |
No |
Identidad |
95.00%
|
5.00%
|
Contenido |
93.33%
|
6.67%
|
Navegación |
70.00%
|
30.00%
|
Gráfica Web |
86.67%
|
13.33%
|
Feedback |
97.50%
|
2.50%
|
Utilidad |
98.33%
|
1.67%
|
Total
|
90.14%
|
9.86%
|
Fuente: Resultados de
encuestas
Elaborado p=
or:
Autores
El test de =
usabilidad
realizado permite evidenciar que el sistema desarrollado es usable con
porcentaje de aceptación del 90.14%, determinando así que los usuarios del
sistema se encuentran satisfechos al utilizarlo.
Para determi=
nar
de forma adecuada si el sistema es usable en base al porcentaje obtenido, s=
e hizo
la consulta a expertos en desarrollo de software quienes supieron manisfest=
ar que
a partir de un 75% de aceptación puede afirmar que el sistema es usable.
Por otro lad=
o, nuestro
resultado se puede basar en la aplicación del modelo sistemático de calidad=
de
Software MOSCA, el cual evalúa la usabilidad y la fiabilidad del software p=
ara
determinar que un sistema es de calidad. Este modelo dentro propone que cad=
a una
de estas características evaluadas debe cumplir al menos un 75% para afirma=
r que
el parámetro evaluado es aceptable (Diaz Anton, 2002).
Conclusiones
ˇ
El análisis de los requerimientos se
logra aplicando la metodología de desarrollo SCRUM, que permite dar una
prioridad y estimar el tiempo en la realización de cada requerimiento.
ˇ
La reducción de tiempos en la
generación de reportes y procesos propios de la Iglesia se refleja en la
utilización del sistema desarrollado, el cual facilita y agilita dichas tar=
eas.
ˇ
La automatización de los test de
funcionalidad permite determinar que los métodos implementados para la
autentificación en el sistema y el registro de asistencias y ofrendas de una
reunión, cumplen las características esperadas y descritas en las pruebas de
aceptación.
ˇ
Mediante la implementación de los t=
est
de usabilidad se determina que el SYSRIBR tiene una usabilidad aceptable de=
un
90.14% después de haber evaluado y analizado cada una de las categorías
propuestas.
=
Referencias Bibliográficas
Diaz, Anton. "Instrumento =
de
Evaluación de Software educativo bajo un enfoque sistemático". Univers=
idad
Federal de Buenos Aires, Congreso Internacional EDUTEC 2003. [En línea] 200=
3,
(Caracas Venezuela), pp. 1-8. [Consulta: 11 noviembre 2017]. Disponible en:
http://www.ufrgs.br/niee/eventos/RIBIE/2002/actas/paper-010.pdf
Técnicas de testeo de software y
herramientas. (2017, diciembre 14). Recuperado 17 de septiembre de 2019, de
Apiumhub website:
https://apiumhub.com/es/tech-blog-barcelona/tecnicas-de-testeo-de-software/=
Pressman, R. Ingeniería del Software. Un enfoque prá=
ctico,
5ta edición, McGraw-Hill Interamericana, Madrid, Espańa, 2002, p. 48.
Mendoza, L. E., Pérez, M. A.,
Grimán, A., & Rojas, T. (2002, noviembre). Algoritmo para la Evaluación=
de
la Calidad Sistémica Del Software. In JIISIC (pp. 85-96).
Interna=
tional
Organization for Standardization ISO 9126: Software Engineering Product
quality, Geneva, Switzerland. ISO 2001
Sánchez, Walter Ovidio. Compend= io de estándares, métodos, técnicas y buenas prácticas de ingeniería de la usabilidad orientado a sitios web en El Salvador. 2(3), (2012), pp. 27-32.<= o:p>
Tipos de pruebas de software
definidos por el ISTQB. [En línea]. 2014. Pruebas Funcionales. [Consulta: 11
septiembre 2017]. Disponible en: http://www.pmoinformatica.com/2014/01/tipo=
s-de-pruebas-de-software-istqb.html
KIBERNUM CHILE, żPor qué son
importantes las pruebas funcionales? [En línea]. Chile, 2015. żPor qué son
importantes las pruebas funcionales? [Consulta:01 julio 2017] Disponible en:
http://www.kibernum.com/noticias/por-que-son-importantes-las-pruebas-funcio=
nales-2/.Pruebas
de Caja Negra y un enfoque práctico. (2017, febrero 26). Recuperado 17 de
septiembre de 2019, de TestingBaires website:
https://testingbaires.com/2017/02/26/pruebas-caja-negra-enfoque-practico/
CAMPOS CHIU, Cindy. Las pruebas=
en
el desarrollo de software [En línea] (Tesis) (Pre-Grado). Universidad Nacio=
nal
Autónoma de México, Facultad de Ingeniería, México. 2015
ALMÁZAN, Felipe. & CAMUS, J=
uan
Carlos. Modelo de Test de Usuario [PDF], 2, Chile, 2008. [Consulta: 28
noviembre 2017]. Disponible en:
http://www.guiadigital.gob.cl/guia-v2/capitulos/05/anexos/pauta-test-usuari=
o.pdf
PARA CITAR EL ARTÍCULO
INDEXADO.
=
<= span lang=3DES-EC>Layedra Larrea, N. P., Ramos Valencia, M., Hidalgo Ponce, B., & Samaniego Orozco, A. (2019). Análisi= s de la aplicación de pruebas funcionales y pruebas de usabilidad de software en= el desarrollo de sistemas web. Ciencia Digital, 3(3.4.), 180-190= . https://doi.org= /10.33262/cienciadigital.v3i3.4.845
El artículo que se
publica es de exclusiva responsabilidad de los autores y no necesariamente
reflejan el pensamiento de la Revi=
sta
Ciencia Digital.
El
artículo queda en propiedad de la revista y, por tanto, su publicación parc=
ial
y/o total en otro medio tiene que ser autorizado por el director de la Revista Ciencia Digital.
[1] Escuela Superior
Politécnica de Chimborazo, Facultad de Mecánica. Riobamba, Ecuador. nlayedr=
a@espoch.edu.ec
[2=
]
Escuela Superior Politécnica de
Chimborazo, Facultad de Informática y Electrónica. Riobamba, Ecuador. vi_ramos@espoch.edu.ec
[3] Escuela Superior Politécnica = de Chimborazo, Facultad de Informática y Electrónica. Riobamba, Ecuador. bhidalgo@espoch.= edu.ec<= /p>
[4] Escuela Superior Politécnica =
de
Chimborazo, Facultad de Informática y Electrónica. Riobamba, Ecuador. angelas=
amaniego991@gmail.com
www.cienciadigital.org =
Vol.
3, N°3.4, p. 180-190, septiembre, 2019