CARACTERÍSTICAS DE UN TESTER Y DE UN PROGRAMADOR

TESTER

      Exploradores: No les asusta la aventura en situaciones desconocidas. Aman tener una nueva pieza de software, instalarla a su computador y ver qué pasa.

      Solucionadores de problemas: Los testeadores de software son buenos encontrando por qué algo no funciona bien, ellos solucionan “rompecabezas”.

      Implacables: Siempre siguen intentando. Ellos pueden ver un bicho que rápidamente se desvanece o es difícil de recrear. Más que desecharlo como si fuera una casualidad, ellos van a intentar toda manera posible de reproducirlo y aislarlo.

      Creativos: Testear lo obvio no es su­ficiente para ellos, su trabajo es pensar creativamente para encontrar bichos.

      Perfeccionistas: Ellos luchan por la perfección, pero conscientes de que algunas cosas se vuelven inalcanzables, se acercan lo más que pueden.

      Ejercen el buen juicio: Necesitan tomar decisiones acerca de lo que van a testear, cuánto tiempo va a tomar y si lo que están buscando es un bicho o no.

      Tácticos y diplomáticos: Son los que siempre traen las malas noticias. Tienen que decirles a los programadores que “su bebé” está feo. Buenos testeadores de software saben cómo hacerlo de manera táctica y profesional, son siempre cautos.

      Persuasivos: Los testeadores encontrarán bichos que quizás no son lo suficientemente severos para ser arreglados. Pero ellos necesitan en algunas ocasiones insistir y demostrar que vale la pena arreglarlos, deben ser buenos argumentando, exponiendo con claridad sus razones.

PROGRAMADOR

      Previsor: Programar es prever. Debes ir por delante y ser capaz de ver lo que va a ocurrir. Si no eres previsor tendrás que tirar muchas veces tu trabajo lo que minará y repercutirá en tu confianza y en la de los que te rodean.

       Lógico: Analizar antes de programar. No escribas nada hasta que tengas totalmente resuelto el problema. Si eres de los que lo primero que hacen es escribir tendrás que tirar muchas veces tu código y te encontrarás con que no resuelve el verdadero problema del usuario.

      Abstracto: Busca soluciones generales y no particulares. Si sólo resuelves el problema concreto, pronto te encontrarás resolviendo un problema similar. Si abstraes conseguirás resolver tanto el problema concreto como otros muchos que aparecerán en el futuro y que ni siquiera te habías imaginado.

      Perseverante: Un buen programa requiere mucho tiempo y esfuerzo. Necesitas tesón y dedicación sin que cunda el desaliento. Si no eres perseverante no terminarás ningún gran proyecto o a partir de un momento la calidad de tu programación se reducirá.

      Empático: El programador no inventa problemas, los resuelve, debes ser capaz de escuchar hasta comprender el problema, a partir de ese momento podrás resolverlo. El mayor error que puedes cometer es programar por ego y tratar de buscar el halago de que eres el mejor, en su lugar busca que los usuarios te aprecien porque se sientan bien escuchados y atendidos, esa es la batalla que debes ganar.

      Documentalista: Piensa desde el primer momento que tus programas serán mantenidos por otros programadores. Comenta profusamente tu código, crea documentos que ayuden a su comprensión y mantenimiento. Programa tus aplicaciones como te gustaría encontrarte una aplicación que hubiese desarrollado otro programador.

      Simplista: Menos es más, menos código es sinónimo de mejor programación. Resolver una función o un procedimiento con el menor código posible es un buen síntoma. Lo más complicado es conseguir desarrollar aplicaciones sencillas, con las opciones adecuadas y la usabilidad correcta. Tan malo es lo que sobra como lo que falta. El usuario es un juez implacable y sabio, habla con los usuarios y simplifica.

      Práctico: Buscar la perfección no tiene por qué ser la mejor opción, hay que saber encontrar el punto de equilibrio entre número de líneas, rendimiento óptimo, facilidad para comprender y mantener el código.

NOTA: Esta información fue tomada de las páginas: http://velneo.es/8-caracteristicas-importantes-de-un-buen-analista-programador/

https://sites.google.com/site/adilaneqa/home/calidad-del-software/control-de-calidad-del-software/caracteristicas-del-tester

Ana Catalina Rodríguez Jaramillo 

METRICAS EN EL DESARROLLO DE SOFTWARE

MÉTRICAS DE SOFTWARE

Una métrica es una medida efectuada sobre los programas, documentación, su desarrollo y mantenimiento, o sobre algún aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparación con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias.

VENTAJAS DEL USO DE MÉTRICAS:

·         Determinar la calidad del producto.

·         Evaluar la productividad de los desarrolladores.

·         Conocimiento cuantitativo de las características del proceso y del producto.

·         Se podrán realizar comparaciones con otros proyectos.

·         Se podrá mejorar el producto ya que las métricas sirven para detectar defectos.

CARACTERÍSTICAS:

·         Exactas

·         Precisas: No se debe perder información en los redondeos ya que la información se desvirtúa.

·         Consistentes: Una medición de un atributo debe dar el mismo valor independientemente de la medición.

·         Comparables: Para ello, debe estar normalizada.

TIPOS DE MÉTRICAS DE SOFTWARE:

—  Métricas de tamaño: Los programas se escriben en lenguajes muy distintos y con propósitos muy diferentes, usando técnicas y métodos dispares, pero con una característica común: tienen un tamaño.

Este tamaño se determina habitualmente tomando como referencia el programa en código fuente. El tamaño es una medida empleada fundamentalmente por tres razones: es fácil de obtener una vez que el programa ha sido completado, es uno de los factores más importantes en los métodos de desarrollo, y la productividad se expresa tradicionalmente con el tamaño del código. La medida de tamaño más usada es la cantidad de líneas de código que se representa como Ss, y se mide en LOC (Lines Of Code, líneas de código).  Para programas grandes es más adecuado el uso de KLOC (miles de líneas de código) representadas como S.

—  Métricas de estructuras de control:

La estructura lógica de un programa es el mecanismo que le permite realizar las distintas funciones para las que fue construido. La estructura lógica del programa representa los algoritmos empleados en su diseño y procesa los datos. La estructura de un algoritmo se representa perfectamente con las gráficas denominadas diagramas de flujo. Son muchos los métodos de medición del software que se basan en estos diagramas.

El flujo de control en un programa es habitualmente secuencial, aunque puede ser interrumpido en ciertas ocasiones: 

—  En una decisión, se divide en dos nuevas líneas de flujo que responden a la evaluación de una condición determinada.

—  Un salto hacia atrás devuelve el flujo de control a una instrucción que ya ha sido ejecutada. Normalmente son la base de los bucles.

—  Una transferencia de control a una rutina o procedimiento externo, hace que el flujo discurra por un camino externo al programa.

La métrica denominada cuenta de decisión (DE) mide la cantidad de veces que ocurren situaciones como las mencionadas en primer y segundo lugar. Esto es, cuenta el número de instrucciones de decisión y bucles condicionales. A la hora de contar decisiones debe tenerse en cuenta los casos en que estas son compuestas, en esta situaciones DE cuenta predicados más que instrucciones en sí, por lo que las situaciones en las que se usan los operadores AND y OR incrementan en más de uno el valor de DE (algo similar ocurre con instrucciones del tipo CASE).

—  Métricas compuestas:

Las medidas descritas hasta ahora miden una única magnitud para darle sentido como una característica del software. Sin embargo, ocurre con frecuencia que para describir una determinada cualidad del software es preciso componer (construir un par) de medidas simples.

—  Métricas de esfuerzo:

El número real de horas y minutos que invierte un programador, es enorme, sin embargo hay una medida que destaca por su universalidad: la personames o meses -hombre. Por otra parte, aunque el esfuerzo es muy importante, en realidad la más importante métrica del esfuerzo es el coste.

La importancia de la medida del esfuerzo y coste responde más a necesidades de tipo administrativo y de gestión que estrictamente técnicas.

Otro elemento importante al trabajar a escala reducida es el tiempo de comprensión y aprendizaje que el programador requiere para comprender los requerimientos, el diseño, o cualquier documento previo a la codificación. Aprender a manejar las herramientas y lenguajes, conocer los interfaces, la metodología empleada, etc. Supone retrasos importantes en proyectos unipersonales.

—  Métricas de calidad y fiabilidad:

El estudio de la calidad y fiabilidad tiene una importancia cada vez mayor en el mundo de la Ingeniería del Software. No sólo se trata de obtener sistemas desarrollados correctamente, de acuerdo a los requerimientos y a los estándares establecidos, sino que se pretenda conseguir programas fáciles de mantener y, lo que es más importante, sistemas fiables en tareas críticas.

La prueba del software se encarga de someter un programa a una revisión de todos los estados posible por los que puede atravesar en algún momento de su vida útil. Los tres objetivos que dirigen la prueba del software son:

—  La prueba es un proceso de ejecución de un programa con la  intención de descubrir un error.

—  Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

—  Una prueba tiene éxito si descubre un error no detectado hasta entonces. Sin embargo, la característica más destacable de la prueba del software es que la prueba no puede asegurar la ausencia de defectos: sólo puede demostrar que existen defectos en el software.

—  Métricas de diseño:

Eficiencia: el esfuerzo de implementación puede reducirse.

Reducción de errores: los planes de prueba se simplifican notablemente.

Reducción del esfuerzo de mantenimiento: la división en módulos favorece que las distintas funciones las lleven a cabo módulos diferenciados.

NOTA: Esta información fue tomada de la página http://www.slideshare.net/1richard1/metricas-ingenieria-de-software

Ana Catalina Rodríguez Jaramillo

PRUEBAS A FACEBOOK Y WHATSAPP

·         VERIFICAR EL REGISTRO DEL DOMINIO AL INGRESO O CREACION DE UNA CUENTA

PRECONDICIONES: llenar el formulario de registro.

CONJUNTO DE VALORES DE ENTRADA: Ingreso de datos personales, registro de correo y creación de contraseña.

CONJUNTO DE RESULTADOS ESPERADOS: Que diga que el registro es correcto y completo.

FORMA EN LA CUAL SE DEBE EJECUTAR EL CASO DE PRUEBA Y VERIFICAR LOS RESULTADOS: primero ingresamos al menú de registro del facebook, se llenaron los datos requeridos y al final de dicho proceso el resultado fue exitoso (registro completo)

POSTCONDICIONES ESPERADAS: Que el registro del usuario en facebook sea aceptado por este y no genere ningún conflicto con la cuenta a utilizar.

·         VERIFICAR EL LIMITE DE SOLICITUDES DE AMISTAD QUE PERMITE

PRECONDICIONES: Tener 400 personas que envíen solicitudes de amistad.

CONJUNTO DE VALORES DE ENTRADA: Recibir  400 solicitudes de amistad.

CONJUNTO DE RESULTADOS ESPERADOS: Que me reciba las 400 solicitudes de amistad.

FORMA EN LA CUAL SE DEBE EJECUTAR EL CASO DE PRUEBA Y VERIFICAR LOS RESULTADOS: primero 400 personas trataron de enviar sus solicitudes de, donde me llegaron solo 300 solicitudes a las otras 100 solicitudes les aparece suscripción mas no les permite enviar solicitudes de amistad.

POSTCONDICIONES ESPERADAS: que admita todas las solicitudes que fueron enviadas.

·         VERIFICAR EL LIMITE DE CARACTERES QUE SE PERMITEN EN LA ACTUALIZACION DE ESTADO.

PRECONDICIONES: Tamaño de la actualización.

CONJUNTO DE VALORES DE ENTRADA: Documento "Historia de la sociología" texto de 2.193 palabras.

CONJUNTO DE RESULTADOS ESPERADOS: Que la actualización de estado ingresada aparezca completamente.

FORMA EN LA CUAL SE DEBE EJECUTAR EL CASO DE PRUEBA Y VERIFICAR LOS RESULTADOS: se copio un documento de 2.193 palabras el cual es lo máximo que uno copiaría en una actualización y el facebook dejo ingresarlo sin ningún problema.

POSTCONDICIONES ESPERADAS: que el estado se publique en su totalidad.

·         VERIFICACION DEL FUNCIONAMIENTO DEL CHAT

PRECONDICIONES: Tener conexión a internet.

CONJUNTO DE VALORES DE ENTRADA: Entablar una conversación con un amigo.

CONJUNTO DE RESULTADOS ESPERADOS: Que me permita enviar y recibir mensajes.

FORMA EN LA CUAL SE DEBE EJECUTAR EL CASO DE PRUEBA Y VERIFICAR LOS RESULTADOS: Con un compañero de facebook se entablo una conversación en la que se mandaba textos y se recibían sin ningún inconveniente ni problema lo mismo con imágenes y fotos.

POSTCONDICIONES ESPERADAS: que el chat reciba y envíe mensajes.

TIPOS DE PRUEBA DE SOFTWARE

TIPOS DE PRUEBA

PRUEBA DE UNIDAD: Se trata de las pruebas formales que permiten declarar que un módulo está listo y terminado (no las informales que se realizan mientras se desarrollan los módulos)

Hablamos de una unidad de prueba para referirnos a uno o más módulos que cumplen las siguientes condiciones [IEEE, 1986a]:

• Todos son del mismo programa

• Al menos uno de ellos no ha sido probado

• El conjunto de módulos es el objeto de un proceso de prueba

La prueba de unidad puede abarcar desde un módulo hasta un grupo de módulos (incluso un programa completo).

Estas pruebas suelen realizarlas el propio personal de desarrollo, pero evitando que sea el propio programador del módulo.

PRUEBAS DE INTEGRACION: Implican una progresión ordenada de pruebas que van desde los componentes o módulos y que culminan en el sistema completo.

El orden de integración elegido afecta a diversos factores, como lo siguientes:

·         La forma de preparar casos

·         Las herramientas necesarias

·         El orden de codificar y probar los módulos

·         El coste de la depuración

·         El coste de preparación de casos.

PRUEBA DEL SISTEMA: Es el proceso de prueba de un sistema integrado de hardware y software para comprobar lo siguiente:

·         Cumplimiento de todos los requisitos funcionales, considerando el producto software final al completo en un entorno de sistema.

·         El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador.

·         Adecuación de la documentación de usuario.

·         Ejecución y rendimiento en condiciones límite y de sobrecarga.

PRUEBA DE ACEPTACION: Es la prueba planificada y organizada formalmente para determinar si se cumplen los requisitos de aceptación marcados por el cliente.

Sus características principales son las siguientes:

·  Participación del usuario.

·   Está enfocada hacia la prueba de los requisitos de usuario especificados.

·  Está considerada como la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotación.

 NOTA: Esta información fue tomada de la página: http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema09.pdf

   Ana Catalina Rodríguez Jaramillo.





TIPOS DE PRUEBAS DE SOFTWARE



Pruebas Unitarias

Las pruebas unitarias son las pruebas que se realiza a cada uno de los módulos lógicos del desarrollo, teniendo en cuenta el excluir las partes lógicas que conviven con otros módulos o clases del sistema, así evaluando plenamente la característica principal de cada modulo.



Pruebas de Regresión o Aceptación.

Las pruebas de regresión estas dispuestas a evaluar una aplicación ya terminada, de la cual no se cuenta con documentación. Este tipo de pruebas se realiza para tener un modelo básico del funcionamiento de la aplicación a la cual se aplica, conocer el objetivo básico para el cual fue desarrollado. Normalmente no se realizan una prueba de funcionamiento exhaustivo. Este tipo de prueba también se aplica antes de realizar cualquier modificación al aplicativo.



Pruebas Funcionales.

Estas pruebas son similares a las de regresión, con la diferencia que ya se realiza una prueba técnica y se incluye cada uno de los requerimientos funcionales conocidos. Las pruebas funcionales, se realizan en ambientes controlados, donde se pueda manipular los datos de entrada y salidas.

Daniel Nikolay Giraldo.

DEF. CARACTERISTICAS DE LA CALIDAD INTERNA Y EXTERNA DEL SOFTWARE

FUNCIONALIDAD

PRESICIÓN: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de exactitud.

ADECUADO: Capacidad del producto software para proporcionar un conjunto de funciones apropiado para unas ciertas tareas y objetivos de usuario.

INTEROPERABILIDAD: El esfuerzo necesario para acoplar un sistema con otro. Capacidad del producto software para interactuar con uno o más sistemas.

CONFORMIDAD: Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con la funcionalidad.

SEGURIDAD: La disponibilidad de mecanismos que controlan o protegen los programas y los datos. Capacidad del producto software para proteger información y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados.

FIABILIDAD

MADUREZ: Capacidad del producto software para evitar fallar como resultado de fallos en el software.

TOLERANTE A ERRORES: el deterioro causado cuando un programa descubre un error. Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software o de infringir sus interfaces.

RECUPERABILIDAD: Capacidad del producto software para restablecer un cierto nivel de prestaciones y de recuperar los datos directamente afectados en caso de fallo.

USABILIDAD

COMPRENSIBILIDAD: Capacidad del producto software que permite al usuario entender si el software es adecuado y cómo puede ser usado para unas tareas o condiciones de uso particulares.

APRENDIBILIDAD: Capacidad del producto software que permite al usuario aprender sobre su aplicación.

OPERATIBILIDAD: la facilidad de operación de un programa. Describe el grado en el cual las aplicaciones atienden los aspectos operacionales, tales como: salvar y recuperar datos y recuperación de procesos.

La facilidad de operación es una característica de la aplicación, minimizando la necesidad de actividades manuales, tales como: montaje de cintas, manejo de papel e intervención manual directa en el lugar.

ATRACTIVIDAD: Capacidad del producto software para ser atractivo al usuario.

EFICIENCIA

TIEMPO DE RESPUESTA: El rendimiento  del funcionamiento de un programa. Capacidad del producto software para proporcionar tiempos de respuesta y de proceso e índices de respuesta al realizar sus funciones bajo unas ciertas condiciones.

RECURSOS: Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas.

UTILIZACIÓN:

MANTENIBILIDAD

ANALIZABLE: Capacidad del producto software para serle diagnosticadas deficiencias o causas de los fallos en el software, o para identificar las partes que han de ser modificadas.

CAMBIABLE: Capacidad del producto software que permite que una determinada modificación sea implementada.

ESTABILIDAD: Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software.

COMPROBABLE: Capacidad del producto software que permite que el software modificado sea validado.

PORTABILIDAD

ADAPTABILIDAD: concerniente al cambio del producto necesario por el cambio de sus requerimientos. Capacidad del producto software para ser adaptado a diferentes entornos, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el propio software.

INSTALABILIDAD: describe el modo en que la conversión desde medios ambientes previos influenciarán en el desarrollo de la aplicación. Capacidad del producto software para ser instalado en un cierto entorno.

COEXISTENCIA: Capacidad del producto software para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes.

REEMPLAZABLE: Capacidad del producto software para ser usado en lugar de otro producto software, para el mismo propósito, en el mismo entorno.

Ana Catalina Rodríguez Jaramillo.

CICLO DE VIDA DEL SOFTWARE

Libro ingeniería del software
Ian Sommerville (Británico)
2009

Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:
• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

Ana Catalina Rodríguez Jaramillo.

Esta información fue tomada de las publicaciones de las siguientes páginas: 

http://books.google.com.co/books?id=gQWd49zSut4C&printsec=frontcover&hl=es#v=onepage&q&f=false

http://spanishpmo.com/index.php/ciclos-de-vida-modelo-en-v/

Modelo de cascada

El primer modelo de cascada fue implementado por el Americano Winston W. Royce en 1970.

Primer Modelo Propuesto por Royce.

A partir de este modelo se crearon varias versiones, en las que se agregaban otros procesos en medios de los propuestos por Royce, pero en general manteniendo los cinco (5) iniciales del modelo original.

También se cuentan con modificaciones mas complejas como el Waterfall Model with Subprojects del Autor Steve Mcconnell.

Daniel Nikolay Giraldo G.

CONCEPTO PROPIO DE "CALIDAD DE LAS PERSONAS QUE PARTICIPAN EN LA CONSTRUCCIÓN DE UN PRODUCTO DE SW"

La calidad para un grupo de personas que participan en la construcción de un producto de software, es aquella en la que dichas personas cumplen con integridad todas las exigencias, requisitos y caprichos del cliente, entregándole así un software impecable, dejando al cliente satisfecho.

Ana Catalina Rodríguez Jaramillo.


La calidad de las personas de un grupo de Software, se cumple cuando todos los procesos se realizan de manera acorde con lo planeado, manteniendo un cronograma de trabajo, teniendo en cuenta los posibles percances que puedan surgir a través del proyecto. Mantener a todo el personal incluido en el proyecto informado dia a dia con el progreso que se tiene del mismos.


Daniel Nikolay Giraldo G

PRINCIPIOS DEL PROCESO DE PRUEBAS DE SOFTWARE - CONCLUSIONES

En un software ya sea grande o pequeño, van a existir siempre errores, por eso hay que hacer un buen proceso de pruebas, para que con las pruebas que se implementen se corrijan los errores de mayor importancia, para que el software sea y funcione lo mejor posible.

Ana Catalina Rodriguez Jaramillo.