Autor. Paul Ammann, Jeff Offutt

Fuente: Cartoon Tester

Fuente: Cartoon Tester

Fuente: Cartoon Tester

Desde la primera solapa ‘Summary’ se pueden compartir las estadísticas haciendo click en la burbuja ‘Share the Stats’ permitiendo publicarla en diferentes canales internos o de manera individual.

Además, en el costado superior derecho se puede apreciar también que dicha información se puede compartir en:
- la red Lnk propiamente dicha, en forma pública
- Twitter
- Facebook

y además se cuenta con la url del grupo para poder enviarlo a quien querramos y así se puede unir al mismo para entre otras cosas, acceder a esta información.

Aparte, pasando el mouse por sobre el porcentaje de Seniority, se podrá apreciar la cantidad de miembros que se han unido al grupo con dichos perfiles.

Desde la solapa ‘Demographics’ se puede visualizar la información a partir de:
- Seniority
- Function
- Location
- Industry

Fuente: Group Statistics for TESTING & QA

Expo:QA

Su labor va a ser la de representar y divulgar en dicho país la filosofía y actividades de expo:QA 2012.

El certámen español se celebrará en Madrid el próximo junio, del 4 al 7, en lugar del mes de noviembre como había sucedido hasta ahora.

Habrá webinars, 40 ponencias, 4 tracks, Keynotes y grandes figuras que animarán el programa.

El certámen se ha convertido en una referencia para los profesionales en Testing y Calidad del Software en España y en Europa, con 8 años de existencia se ha consolidado como el mayor evento del sur de Europa sobre estos temas, ampliando su área de influencia a Latinoamérica.

Fuente: QAustral

Pregunta:
¿Alguien ha realizado pruebas funcionales en SAP? ¿Es muy complejo? ¿Necesita mucho conocimiento del producto SAP?

Respuesta:
Ciertamente hace falta conocimiento en el producto, de lo contrario uno depende del soporte que le deban dar los analistas funcionales y desarrolladores SAP.

Las siguientes, son algunas de las tareas que deben realizar a fin de construir casos de prueba:
a. Entender los procesos funcionales que componen una aplicación de un módulo de negocios en particular.
b. Identificar aquellos procesos que pueden ser tomados como ‘modelos’ y estudiarlos al detalle como para después, poder replicar el conocimiento adquirido sobre otros modelos que tienen similar comportamiento, y así poder acelerar la construcción de sus casos de prueba.
c. Reconocer la dependencia entre los procesos.
d. Identificar -como siempre- el flujo normal y los flujos alternativos que nos permitirán diseñar los casos de prueba ‘positivos/felices’ y los ‘negativos’.
e. Analizar los argumentos (datos) que deberán ser tenidos en cuenta a la hora de preparar las condiciones del ambiente antes de ejecutar los casos de prueba diseñados.

… y aquí me detengo por un segundo para recomendar algo: Si somos parte de un equipo consolidado y alineado, podremos trabajar en conjunto con los desarrolladores para que nos ayuden con el ‘armado’ del ambiente, en caso de que nosotros no podamos hacerlo.

… otro punto a considerar es que hay transacciones que son comunes, son estándares, pero que dependiendo de los datos ingresados, los caminos que se generan, son totalmente distintos.

Pregunta:
Entiendo que al ser un producto parametrizable, vendrá provisto de la documentación funcional disponible en cada módulo, y partiendo de ella, ¿pueden diseñarse las pruebas? ¿O no es tan sencillo?

Respuesta:
Es un producto altamente parametrizable y en contiene mucha documentación funcional, es cierto, no obstante digo, el tester que incursione en este tipo de prácticas, debería conocer para poder entender la globalidad y luego diseñar los casos:
1. el negocio en sí
2. la parametrización del módulo
3. las reglas de negocio

Además hay que tener en cuenta aquellos procesos y/o transacciones que son implementados de forma estándar, y aquellos a los que se le han efectuado modificaciones, es decir, se los ha customizado.

Sobre estos últimos habrá que tener particular atención porque influyen en el aprendizaje de lo que se deba probar.

Por otra parte, y más allá de todos los puntos mencionados, esta la preparación del ambiente de prueba, cuestión que a veces se puede tornar un poco dificultoso.

Pregunta:
Vale, comprendo… En cuanto al ambiente de pruebas, ¿a qué te refieres exactamente?¿Al entorno de pruebas? ¿Al juego de datos?

Respuesta:
Me refiero a ambas, sorry, tanto a las condiciones propias del entorno de pruebas como al juego de datos a preparar y que permitirá generar la población de datos.

Un buen número (no todos) de datos que se puedan estar generando, servirá para diferentes pruebas ya que hay varias transacciones estándares que aplican en diferentes procesos y que inician de la misma forma.

Comentario:
Coincido completamente con lo que dice Gustavo. Ahora mismo existe un auge en el tema de pruebas en entorno SAP, como si fuera algo muy distinto a lo que se hace habitualmente (si hablamos de pruebas funcionales).

La verdad es que es similar. El tema aquí es el conocimiento del propio SAP, donde los procesos que se parametrizan tienen flujos de información, en general, bastante complejos, con lo que es necesario un conocimiento funcional elevado para poder plantear los casos de prueba correctamente.

Si no, como dice Gustavo, estás en manos de los desarrolladores de SAP, que te pueden ayudar a plantear los casos de prueba positivos; pero en general, no los negativos, los flujos de datos alternativos; las situaciones de uso no habituales, etc.

En definitiva, el planteamiento de prueba funcional es el de siempre, pero el conocimiento del propio aplicativo SAP y de los procesos implementados son limitantes. Son el factor de éxito en este caso.

Comentario:
Creo que todo lo que habéis comentado, aplica a todos los productos / aplicaciones de SW que testeamos. Si no ocurre así, trabajamos bastante a ciegas, y sólo basados en alguna experiencia previa y/o intuición del buen tester.

Es un tema recurrente desde hace muchos años, y aún sigue muy vigente.

El disparador del debate, iniciado por Anko Beijleveld, es el siguiente:

Leyendo la ley de Arnold sobre documentación me he preguntado si realmente vale la pena en el Testing.
En general he visto que lo mayoria de los defectos se encuentran sin un testplan, casos de pruebas etc..

Arnold’s Laws of Documentation:

1. If it should exist, it doesn’t. – Cuando necesitas un caso de prueba no existe
2. If it does exist, it’s out of date. – Si lo tienes ya esta obsoleto porque han cambiado el programa
3. Only documentation for useless programs transcends the first two laws.

Arnold’s Laws of Documentation | Unwritten Laws of Life lawsoflife.co.uk

1. If it should exist it doesn’t. 
2. If it does exist it’s out of date. 
3. Only useless documentation transcends the first two laws.

Los comentarios que han sido dejados por algunos de sus miembros, son:

Comentario 1
Es básica, si no dispones de documentación ni de conocimiento sobre el negocio, cómo específicas correctamente los casos de prueba?

Comentario 2
Pero si lo conoces el negocio y conoces los riesgos y hablas directamente con los desarolladores, realmente necesitas crear casos de prueba?

Comentario 3
Yo creo que es básico. Sobretodo para poder tener una traza de lo que se ha probado. También es necesario a la hora de hacer regresiones y poderlas automatizar. Esto sería en el caso ideal, pero si no se dispone de suficiente tiempo, siempre se puede usar el “Exploratory testing”…

Comentario 4
Comparto la opinion de Ivan, aparte crear los casos de prueba sirven para que parte del equipo que se encarga de los defectos puedan desarrollar una trazabilidad y despues para posibles discrepanciascon el solicitante

Otro fuente que me resultó oportuna citar es: How to Test Process Documentation

Instructions

1. Establish a test team comprised of software developers and individuals who can represent a typical user of the software. Business users will test the function of the software while developers will test the code and the processing of the system.
2. Determine and document the test process objectives. Outline any and all business scenarios and system functions that the test process needs to address. Include user functionality and technical functionality. Consider also any ways that the software of system exchanges data with other programs.
3. Write a test plan. Include any tasks that the test team will perform. Include all data that will be needed for the test. Be thorough and detailed. Start at the beginning of the process flow and create test scenarios that follow a logical flow of data.
4. Ask that each tester keeps detailed records of the results of the test process. Documenting the test process will provide greater insight into the gaps and problems with the software. Provide a standard document where testers will make notes about the functionality of the software and identify problems.
5. Determine a time line for the test process. Assign individuals to perform each portion of the tests and assign a deadline for each test item or process. Perform the tests.
6. Summarize the test results in a formal document. Include detailed results and an analysis on the overall functionality of the software. Review the documentation with key decision makers to determine if the software is ready for release

Fuente: How to Test Process Documentation

Antes que nada, y como opinión personal, pienso que cada uno de nosotros, mas allá de la actividad que tengamos, accedemos y utilizamos sistemas de información.

Como ‘usuarios’ de estos sistemas queremos que nos ofrezcan una cierta funcionalidad en base a la necesidad que tenemos, que sean sencillos de manejar, que automaticen algunas tareas, que nos brinden información útil y a tiempo, que sean seguros, estables, … sigo?

Ahora bien, dentro de un proyecto de desarrollo de software, sea que estemos como Líderes de proyecto, Analistas, Programadores o Testers, nos interesa siempre construir sistemas de información útiles, que permitan cubrir las expectativas de los usuarios que nos han solicitado el desarrollo del sistema, para resolver ciertos problemas que están teniendo y ofrecerles ventaja competitiva.

Los ‘usuarios’, …, que tema, ¿no?

Por lo general, los usuarios no son especialistas en sistemas (aunque cada día este aspecto se va revirtiendo) y como tal, no comunican sus necesidades en forma adecuada, muchas veces no saben lo que quieren o hasta incluso, no identifican sus verdaderos problemas o necesidades (para nosotros, ‘causa-raiz’).

Por otra parte, el equipo de desarrolladores (programadores para algunos) no es experto en procesos de negocio de usuarios, sí en dar una solución tecnológica.

Aquí es donde debe intervenir, a mi criterio, el Analista Funcional junto con el Analista de Calidad y/o Analista de Pruebas, ya que el ‘requerimiento’ es lo más importante en el desarrollo de sistemas.

Bien, vayamos al punto entonces, el contenido del libro es el siguiente:

1. The Importance of Requirements

• What are Requirements and Why are they important?
• Why Plan?
• A suggested strategy
• Requirements activities in the system life cycle
• Investment in the requirements process
• A process approach
• The requirements plan
• Factors affecting your career decisions
• A comment concerning small projects
• Summary
• Case study

2. The roles of the RA

• Suggested Roles of the RA
• Summary
• Case Study

3. Skills and characteristics of an effective RA

• Skills of the RA
• Characteristics of an Effective RA
• Summary
• Case study

4. Types of Requirements

• Views of Requirements types
• Definitions and Descriptions of Requirements types
• Business Requirements
• Stated Requirements versus Real Requirements
• User Requirements
• High-Level or System-Level Requirements
• Business Rules
• Functional Requirements
• Nonfunctional Requirements
• Derived Requirements
• Design Requirements and Design Constrains
• Performance Requirements
• Interface Requirements
• Verified Requirements
• Validated Requirements
• Qualification Requirements
• The “Ilities” and Specialty Engineering Requirements
• Unknowable Requirements
• Product Requirements
• Process Requirements
• Logistics Support Requirements
• Environmental Requirements
• System, Subsystem, and Component Requirements

Terminologies to Avoid

• Source or Customer Requirements
• Nonnegotiable Versus Negotiable Requirements
• Key Requirements
• Originating Requirements
• Other Guidelines

5. Gathering Requirements

• Plan the Approach
• Summary
• Case Study

6. Best Practices for Requirements Development and Management

• Summary
• Case Study

7. The RA’s Speciality Skills

• Summary
• Case Study

8. An Integrated Quality Approach

• Business Drivers for Quality
• Management’s Role
• GUiding Principles
• Priority Management
• The Components of an Integrated Quality Approach
• Quality Improvement Techniques
• The PDCA Cycle
• How to Design a Process
• Teamwork
• Summary
• Case Study: An example of Quality Improvement Sidetracked

9. A Vision for Requirements Engineering

• How Should we support PMs?
• How should we support Developers?
• Summary
• Case Study

10. Moving Forward: Knowable Requirements, Manageable Risks

• Where to go from here
• Moving Forward
• A requirement Mandala
• Summary
• Case Study

Los invito a que se unan al grupo y puedan debatir en esta discusión asi como en todas las que están abiertas y que están relacionadas con nuestra actividad.

Gracias

Aquí les dejo el primer listado de enlaces, sobre los que estaré trabajando para sacar conclusiones y estar haciendo las respectivas síntesis, para luego seguir buscando más publicaciones.

.

Estimación del esfuerzo de las pruebas.
http://ddonofrio.blogspot.com/2011/03/estimacion-del-esfuerzo-de-las-pruebas.html

//

Estimación Basada en Puntos de Función y Soluciones Híbridas
Enviado por Elsydania Lopez Guerra

fuente: monografías
http://www.monografias.com/trabajos55/estimacion-por-puntos-de-funcion/estimacion-por-puntos-de-funcion.shtml

//

Métricas técnicas de software
http://www.slideshare.net/juic/metricas-tecnicas-del-software-presentation

//

Métricas de software
http://www.slideshare.net/panchois/metricas-de-software

//

Estimación del esfuerzo basada en Casos de Uso
http://pisuerga.inf.ubu.es/rcobos/anis/estimacion-del-esfuerzo-basada-en-casos-de-usos.pdf

//

Métodos de Estimación
http://www.lsi.us.es/docencia/get.php?id=326

//

Estimación tiempo de pruebas
http://www.xing.com/net/ne_calidaddelswyprocesosdede/foro-del-grupo-133698/estimacion-tiempo-de-pruebas-8724580/

//

Puntos de casos de uso
http://es.wikipedia.org/wiki/Puntos_de_caso_de_uso

//

Estimación de esfuerzo con USC COCOMO II
http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/lab/cocomo/pgsi-p2.pdf

//

Estimación de esfuerzo del proyecto
http://www.liderdeproyecto.com/manual/estimacion_de_esfuerzo_del_proyecto.html

//

Planning Poker
http://es.wikipedia.org/wiki/Planning_poker

//

Planning Poker: Estimando tiempos en Scrum
http://www.fperezp.com/blog/2011/03/09/planning-poker-estimando-tiempos-en-scrum/

//

Realizar estimaciones de tiempo con el método poker
http://www.marblestation.com/?p=664

//

Desarrollo de software. Técnica de estimación Planning Poker
http://jummp.wordpress.com/2011/05/15/desarrollo-de-software-tecnica-de-estimacion-planning-poker/

Como resultado de buscar por la palabra clave: estimación, en este blog, obtendremos un número considerable de artículos referidos al tema.
 
//