Aseguramiento de Calidad de Software Guía de revisión

Transcripción

1 Aseguramiento de Calidad de Software Guía de revisión

2 Control de versiones Autor Fecha Ver. Cambio mcano 05 de marzo de Pre release. vmoreno, rrodriguez, mcano 08 de Marzo de Versión inicial. mcano 05 Abril de Actualización de fechas ya vencidas. 2.- Nuevas revisiones: Paginación ante múltiples resultados, Utilización de filtros en formularios, Fiabilidad ante falla en Webservice, Acceso a archivos subidos por usuarios, Confirmación de prioridad en Ticket, Incluir Software, Incluir Bases de datos, Manual de Instalación, Repositorio de configuración, Pagina de offline. 3.- Cambios en introducción.

3 Índice de contenido Quality Assurance Introducción... 5 I. Revisiones Manuales... 6 Identificación de responsables... 6 Diseño y menús... 6 Logo Mineduc... 6 Pie de página... 7 Tipo de letra... 7 Geometria del aplicativo al efectuar Zoom In / Zoom Out... 7 Mensajes de error... 7 Registro de Errores... 8 Mensajes de espera... 8 Validación de Campos (Numérico, Carácter, mail, fecha, largo, etc)... 8 Validación de entrada en server... 9 Funcionalidades (Que grabe, que sume, etc.)... 9 Plan de pruebas... 9 Navegabilidad (Que funcionen menús a link)... 9 Navegadores (Explorer, Firefox, Chrome) Navegación en dispositivos móviles Incorporación de Google Analytics (páginas principales) Captcha (en paginas Públicas) Reintentos de login (máximo 10) Funciones abreviadas de teclado Cookies Ejecutar Script Contenido no indexado Contenido no requerido Contenido inapropiado Ortografía Rendimiento Interoperabilidad Caracteres UFT Documentación Web Services Paginación ante múltiples resultados Utilización de filtros en formularios Fiabilidad ante falla en Webservice Acceso a archivos subidos por usuarios Confirmación de prioridad en Ticket Incluir Software Incluir Bases de datos Manual de Instalación Repositorio de configuración Pagina de offline II. Revisiones Automáticas Acunetix Web Link Validator HP LoadRunner jmeter

4 Quality Assurance Nessus

5 Introducción Quality Assurance La presente guía contiene las pautas en base a las cuales se realizarán los controles de calidad de software, por tanto, cada proyecto de software para su paso a producción sea aprobado deberá ser capaz de aprobar cada prueba a la que sea sometido, siendo el área de QA quien selecciona que pruebas son o no pertinentes en cada proyecto. Esperamos que esto nos ayude a acercarnos aún más a la meta de entregar a la comunidad un servicio de la más alta calidad. 5

6 Quality Assurance I. Revisiones Manuales Este conjunto de revisiones se realizan de forma manual, apoyado mínimamente por software. En el listado se indica cuales ya se están utilizando, y cuales serán exigibles en una fecha futura, además de que se indica de cuales corresponden a aplicaciones Web, y cuales a Web Services. Identificación de responsables Aplica a: Toda solicitud. Cada solicitud, para ser procesada, debe incluir los nombres de: - El/Los jefe(s) de proyecto responsable(s). - El/Los desarrollador(es) involucrados en el proyecto. - El/Los responsable(s) de las pruebas internas de desarrollo. Para el caso de los desarrollos externos, también se deben incluir los nombres de: - El/Los encargados del Control de Calidad de Software (QC/QA). Diseño y menús. Para el diseño de los sitios web del ministerio se deben utilizar los lineamientos gráficos indicados en el manual de normas graficas [ en caso de que usted no esté seguro utilice como ejemplo la web de Mineduc [ Logo Mineduc. El logo del Ministerio de Educación debe ser legible y ubicarse en cada página, en la sección superior izquierda, de forma de que el usuario sepa de que esta en una página ministerial. 6

7 Pie de página. Quality Assurance Cada aplicación web ministerial debe contar con el pie de página estándar, esto es importante ya que este pie de página proporciona los números telefónicos necesarios para llamar a nuestro call center en caso de que el usuario tenga problemas, además contiene el hipervínculo con los plugins necesarios para navegar, y la dirección física, con la cual recibimos correspondencia. Tipo de letra El tipo de letra, o font, seleccionado debe ser legible, y debe ser lo bastante común como para que se vea similar en distintos PC, sin importar el navegador empleado, o el sistema operativo utilizado. Recuerde además, que debe cumplir con el manual de normas graficas. Geometria del aplicativo al efectuar Zoom In / Zoom Out Se verifica que los datos presentados en pantalla no se deformen al hacer zoom sobre un sitio Web. El sitio Web tampoco debe fallar debido a que el usuario tiene una resolución de pantalla distinta a la del desarrollador. Mensajes de error, Web Services Los mensajes y páginas de error deben mostrar un fallo manejado, (ejemplo nunca de debe obtener un código 500 desde la aplicación), esto incluye inyección directa de parámetros erróneos o de distinto tipo, de tamaños exagerados, o bien falta de recursos como conexiones a bases de datos, solo por citar algunos ejemplos. Además estos mensajes de error deben ser escuetos, su contenido no debe poder ser manipulado por el usuario y no deben entregar información acerca del funcionamiento interno de la aplicación a un atacante. 7

8 Quality Assurance Registro de Errores, Web Services Los mensajes de error originados por posibles ataques, o por falta de recursos deben registrarse en una bitácora, o log, de la aplicación. Mensajes de espera Para el caso de las aplicaciones web que contengan sistemas de carga asincrónica, como por ejemplo Ajax, se requerirá que estas tengan un mensaje de que están operando, es decir, deben mostrar un mensaje de cargando o similar, mientras no tengan los datos para presentar en pantalla, de forma de que el usuario se de cuenta de que la aplicación está trabajando. Validación de Campos (Numérico, Carácter, mail, fecha, largo, etc) Los campos que son llenados por el usuario deben tener métodos que permitan la validación de los datos ingresados, tales como: - Los nombres de personas, ciudades y países no pueden contener números, - Los s deben estar bien formados, - Las fechas deben tener formato de fecha, - Las fechas deben considerar los años bisiestos, - Los largos de estos campos deben ser lo bastante amplios como para al menos permitir el ingreso completo de los datos, - Los largos de estos campos deben lo ser bastante cortos como para, a lo mas, permitir ingresar el largo máximo del campo en la base de datos, - Deben aceptarse los tildes cuando corresponda, y rechazarlos cuando no corresponda, - Las edades deben ser números naturales, - etc. Esta verificación se realiza en la página que ve el usuario. 8

9 Validación de entrada en server, Web Services Quality Assurance Las aplicaciones ministeriales deberán contar con esta validación, la cual es similar a la Validación de Campos, con la diferencia de que esta se trata de una validación en el servidor, esta debe ser funcional, y su misión es detener los datos que podrían ser inyectados directamente que podrían dañar la aplicación y su información, por ejemplo el comprobar que se reciben números en campos numéricos, que los datos recibidos no superen el largo de los campos declarados en la base de datos, el que los caracteres de control fueron manejados, que no se puedan hacer inyecciones de SQL, que no se pueda ejecutar un path transversal, etc. Funcionalidades (Que grabe, que sume, etc.), Web Services El software debe ejecutar las funciones que dice realizar, por ejemplo el botón grabar debe grabar, el botón imprimir debe imprimir, etc. La documentación anexa, como lo son el modelo de datos y en diccionario de datos, debe permitir la verificación de esto. Plan de pruebas, Web Services Para ejecutar la prueba de funcionalidad, anteriormente mencionada, se requiere un plan de pruebas que indique que acciones se esperan frente a cada interacción con la aplicación. Este plan de pruebas debe incluir las credenciales de acceso a la aplicación. Para no sobre cargar de trabajo al área de desarrollo es aceptable que el plan de pruebas entregado sea el mismo que el utilizado en las pruebas internas de desarrollo, esto no es problema ya que el plan de pruebas recibido será solo una guía para las pruebas de QA. Navegabilidad (Que funcionen menús a link) La aplicación no debe contener enlaces rotos accesibles a los usuarios, además todos los enlaces ofrecidos por la aplicación a sitios externos deben efectivamente contener la información que dice enlazar. 9

10 Navegadores (Explorer, Firefox, Chrome) Quality Assurance Las aplicaciones web deben funcionar correctamente y verse similares en los tres principales navegadores Web: Firefox, Chrome, Internet Explorer. Para el caso de las revisiones de Internet Explorer se recomienda utilizar IETester. Navegación en dispositivos móviles, destinadas a móviles Las aplicaciones web en las cuales la totalidad, o al menos una parte importante, de los clientes accederán mediante dispositivos móviles, deben considerar las restricciones de navegadores, sistema operativo y hardware, en el diseño y desarrollo de estas, de forma de que funcionen correctamente en dichos dispositivos, ejemplos de esto es el pequeño tamaño de la pantalla, la baja capacidad del procesador para ejecutar scripts complejos, el escaso ancho de banda y lo costoso de este, etc. Incorporación de Google Analytics (páginas principales) Cada página de la aplicación Web deberá contener el código de Google Analytics necesario para obtener la estadística correspondiente a dicha aplicación, la única forma de que esto no sea obligatorio es con una nota del jefe de proyecto responsable agregada a la solicitud indicando que por razones del negocio la aplicación no deberá llevar dicho código. Para evitar demoras en los proyectos debido a esto es que se recomienda hacer la solicitud del código de Google Analytics con la debida antelación. Captcha (en paginas Públicas) Toda aplicación que tenga autenticación accesible desde Internet debe contar con un captcha en cada ventana de login a fin de mitigar los posibles ataques de autenticación por fuerza bruta. La implementación de este sistema debe considerar algún mecanismo que no produzca palabras ofensivas. 10

11 Reintentos de login (máximo 10) Quality Assurance Toda aplicación que tenga autenticación accesible desde Internet debe contar un sistema de bloqueo de cuenta ante una gran cantidad de intentos fallidos de login en forma consecutiva. Estos bloqueos de cuenta no deben requerir la utilización de la mesa de ayuda para el desbloqueo, dos buenos ejemplos serian por un lado el bloqueo temporal, en donde se le dice al usuario que lo reintente en media hora más; y por otro lado el bloqueo con obtención automática de una nueva contraseña. Funciones abreviadas de teclado Las funciones abreviadas de teclado, como copiar/pegar, deben estar habilitadas y funcionar correctamente. La aplicación debe ser navegable vía mouse o tabs, si un formulario debe ser llenado en orden 1..N, el usuario debe ser capaz de posicionarse en el primer campo y llegar hasta el N solo con el teclado haciendo TABS para ir de un campo a otro. Cookies Las cookies generadas por la aplicación Web, ya sea para almacenar sesiones, preferencias, o cualquier otro dato; deben quedar inalcanzables para otras aplicaciones en otros dominios dns, a menos de que efectivamente estas deban compartir información. Ejecutar Script Se verificará que los scripts incluidos en el software tengan una sintaxis correcta y se ejecuten correctamente, a la vez que parezcan no realizar daños. En el caso de los scripts SQL, estos deben indicar la base de datos y la tabla donde deben ser ejecutados, solo en caso de esto se desconozca se debe indicar el nombre del sistema y su URL. 11

12 Quality Assurance Contenido no indexado, Web Services Salvo las páginas de index, no debe existir contenido huérfano, es decir, accesible directamente por el usuario y que además no esté enlazado de ninguna forma por ninguna pagina. Contenido no requerido, Web Services No deben existir páginas innecesarias para el funcionamiento de la aplicación, por ejemplo, deben quitarse las páginas de ejemplo y ayuda que acompañan a una biblioteca. Contenido inapropiado, Web Services No deben existir contenidos inapropiados, ofensivos o que estén reñidos con las políticas de Mineduc. Esto incluye comentarios html, texto oculto, fotografías, etc. Ortografía La aplicación no debe contener errores ortográficos. Rendimiento, Web Services Las aplicaciones deben tener tiempos de respuesta adecuados para el usuario, además deben hacer un uso racional de los recursos de hardware y software de los servidores del Ministerio. 12

13 Quality Assurance Interoperabilidad Aplica a: Web Services Los Web Services de gobierno deben ser desarrollados de forma de ser interoperables, ver [ Además de lo anterior, deben observarse a lo menos las siguientes reglas: - Deben existir esquemas WSDL. - Solo deben usarse campos CDATA para el intercambio de binarios. Caracteres UFT-8, Web Services Debe utilizarse el juego de caracteres UTF-8 para Sitios Web, y sus bases de datos [ Documentación Web Services Aplica a: Web Services Los Web Services para ser aceptados para revisión deben venir acompañados de: - Nombre Servicio, - Característica (Proveedor o Consumidor), - Propósito, - Datos de entrada, - Datos de salida, - Sistemas a los que se integra, - Descriptor del Servicio (WSDL), - Documentación anexa. Paginación ante múltiples resultados Exigible: desde el 25 de abril de 2012 Si una consulta genera más de cien resultados estos deben ser divididos en múltiples pantallas. Cada pantalla debe ser alimentada 13

14 Quality Assurance Utilización de filtros en formularios Exigible: desde el 25 de abril de 2012 En cada formulario de búsqueda se debe cautelar que al menos se utilice un filtro. Nunca se podrá listar todo. Fiabilidad ante falla en Webservice Exigible: desde el 25 de abril de 2012 Las aplicaciones que consuman webservices para su funcionamiento, deberán tener mensajes de error controlados ante una falla de dicho webservice, deberá además dejar un registro de dicho evento. Acceso a archivos subidos por usuarios Exigible: desde el 25 de abril de 2012 Los archivos que suba un usuario a alguna plataforma deberá quedar en una carpeta que no sea accesible para el servicio Web, de forma de que ninguno de estos archivos sean accesibles desde una url directa. Confirmación de prioridad en Ticket Exigible: desde el 25 de abril de 2012 Aplica a: Toda solicitud En el sistema de Ticket, para que se considere efectiva una prioridad que este por sobre la prioridad normal, esta deberá ser declarada por parte del informador como auspiciada por su jefatura directa. Incluir Software Exigible: desde el 05 de abril de 2012 Aplica a: Toda solicitud Toda solicitud debe incluir el software a probar, este debe estar completo, con todos sus componentes. Deben incluirse tanto binarios como fuentes. 14

15 Quality Assurance Incluir Bases de datos Exigible: desde el 05 de abril de 2012 Aplica a: Toda solicitud Todo software debe incluir todas las bases de datos que utilice, en caso de que sean demasiado grandes para ser adjuntadas al sistema de ticket estas deben ser disponibilizadas de alguna otra forma convenir. Manual de Instalación Exigible: desde el 05 de abril de 2012 Aplica a: Toda solicitud Se debe incluir un manual de instalación, con los pasos concretos a seguir para instalar para todas y cada una de las partes o componentes del software. Este manual no debe dejar lugar a dudas acerca de ningún paso de la instalación. Repositorio de configuración Exigible: desde el 25 de abril de 2012 Aplica a: Toda solicitud Se revisará que cada proyecto disponga de algún tipo de repositorio de configuración, ya sea en archivos o en bases de datos, estos deberán tener todas las URI y credenciales de cada recurso externo que utilice el software. Nunca se aceptarán configuraciones como, por ejemplo (pero sin limitarse a ellos): direcciones, login o contraseñas, etc, de bases de datos, webservices, recursos compartidos, etc. Pagina de offline Exigible: desde el 25 de abril de 2012 Aplica a: Toda solicitud Las aplicaciones deberán tener alguna forma de configurar por base de datos el que en vez de atender normalmente, aparezca una ventana que indique se que esta sin servicio (utilizar como ejemplo SIGE). 15

16 Quality Assurance II. Revisiones Automáticas Acunetix Software de revisión de vulnerabilidades. Web Link Validator Software de verificación de enlaces rotos. HP LoadRunner Software de pruebas de carga. jmeter Software de pruebas de carga. Nessus Software de revisión de vulnerabilidades. 16