100+ Ready-to-Execute Test Cases (Checklists) AUT

You Can Use to Test the Most Common Components of AUT
How to test the most common components of your AUT effectively, every single time
This article is a list of common validations on most widely found elements of AUT – that is put together for the convenience of testers (especially in agile environment where frequent short term releases happen).
Every AUT (Application Under Test) is unique and has a very specific business purpose. The individual aspects (modules) of the AUT cater to different operations/actions that are crucial for the success of the business that the AUT supports. Though each AUT is designed differently, individual components/fields that we encounter on most pages/screens/applications are same with more or less similar behavior.

Some Common Components of AUT:

• Save, Update, Delete, Reset, Cancel, OK – links/buttons- whose functionality is as the label of the object indicates.
• Text box, drop downs, checkboxes, radio buttons, date control fields – that work the same way every time.
• Data grids, impacted areas, etc. to facilitate reports.

The way these individual elements contribute to the overall functionality of the application might be different but the steps to validate them are always the same.
Let’s continue with the list of most common validations for web or desktop application pages/forms.
Note: The actual result, expected result, test data and other parameters that are typically a part of a test case are omitted for the sake of simplicity – A general checklist approach is employed.
Purpose of this comprehensive checklist:
The primary purpose of these checklists (or test cases) is to ensure maximum test coverage on field level validations without spending too much time, at the same time not compromise the quality of testing them.
After all, confidence in a product can only be attained by testing every single element to the best extent possible.

The Complete Checklist (Test Cases) for Most Common Components of AUT

Note: You can use these checklists as it is in Microsoft Excel format (download provided at the end of the article). You can even track the test execution in same file with pass/fail result and status.
This could be an all-in-one resource for QA teams to test and track the most common components of AUT.  You can add or update test cases specific to your application and make it even more comprehensive list.

Checklist #1: For a module, we have to check the below points:

Module Name:

Module Functionality:

Module Impact over the application:

Module Flow:

Menu & Submenu:

Spellings and Order & Suitability:

Control for each sub menu:

Checklist #2: For each screen, we have to verify the below points

Form Functionality:

Form Impact over the application:

Form Flow:

Designing:

Alignments:

Title:

Field Names:

Spellings:

Mandatory Marks:

Alerts of Mandatory fields:

Buttons:

Default Cursor Position:

Tab Sequence:

Page before entering any data:

Page after entering data:

Checklist #3: For each text box in the screen we have to verify the below points

Text Box:

	ADD(In add screen)	EDIT (in Edit screen)
Characters
Special Characters
Numbers
Limit
Alert
Spelling & Grammar in Alert message:

BVA (Size) for Text Box:
Min —>—> Pass
Min-1 —> —> Fail
Min+1 —> —> Pass
Max-1 —> —> Pass
Max+1 —> —> Fail
Max —> —> Pass
ECP for Text Box:

Valid	In Valid
-	-
-	-

Checklist #4: For each list box/drop down in the screen we have to verify the below points

List Box/Dropdown:

	ADD(In add screen)	EDIT (in Edit screen)
Header
Correctness of Existed Data
Order of Data
Selection and Deselect ion
Alert:
Spelling and Grammar of Alert message
Cursor after alert
Reflection of Selection and De selection in remaining fields

Checklist #5: For each Check box in the screen we have to verify the below points

Check Box:

	ADD(In add screen)	EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselect ion
Alert:
Spelling and Grammar of Alert message
Cursor after alert
Reflection of Selection and De selection in remaining fields

Checklist #6: For each Radio button in the screen we have to verify the below points

Radio button:

	ADD(In add screen)	EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselect ion
Alert:
Spelling and Grammar of Alert message
Cursor after alert
Reflection of Selection and De selection in remaining fields

Checklist #7: For each date field in the screen we have to verify the below points

Date field:

	ADD(In add screen)	EDIT (in Edit screen)
Default date display
Design of calendar
Navigation for different months and years in date control
Manual Entry in date text box
Date format and uniformity with overall application
Alert:
Spelling and Grammar of Alert message
Cursor after alert
Reflection of Selection and De selection in remaining fields

Checklist #8: For each save button in the screen we have to verify the below points

Save/update:

	ADD(In add screen)	EDIT (in Edit screen)
Without giving any data:
With only mandatory fields:
With All fields:
With Max limit:
With min limit
Spelling & Grammar in Confirmation  Alert message:
Cursor
Duplication of Unique fields:
Spelling & Grammar in duplication Alert message:
Cursor

Checklist #9: For each Cancel button in the screen we have to verify the below points

Cancel:

With data in all fields
With only mandatory fields:
With All fields:

Checklist #10: For each Delete button in the screen we have to verify the below points

Delete:

	EDIT (in Edit screen)
Delete the record which is not used anywhere in the application
Delete the record which has dependency
Add the new record with same deleted details again

Checklist #11: To verify impacted areas after saving/updating

After Saving/updating:

Display in View
Reflection in impacted forms in the application

Checklist #12: For each data grid in the screen we have to verify the below points

Data Grid:

Grid Title and spelling
Form Before giving any data
Message Before giving any data
Spellings
Alignments
S No
Field Names & Order
Correctness of Existed data
Order of Existed data
Alignment of Existed data
Page navigators
Data when navigating with different pages

Edit Link Functionality

Page after Edit:
Title and spellings
Existed data of Selected record in each field
Buttons

While this list might not be exhaustive, it is indeed extensive.
==> You can download all these checklists in MS Excel format: Download in Excel format
Points to note:

1. Depending on your need, additional tests under each category/for each field can be added or existing fields can be removed. In other words, these lists are completely customizable.
2. When in need to include field level validations to your test suites, all you have to do is pick up the respective list and use it for the screen/page that you would like to test.
3. Maintain the checklist by updating the pass/fail status to make this a one-stop-shop for listing features, validating them and recording the test results.

As always, the intent is to provide our readers with some easy to use techniques, tips and tools that make our work efficient and of course, easy.  

http://www.softwaretestinghelp.com/100-ready-to-execute-test-cases-checklists/

Videoconferencia: aspectos positivos y negativos

Pese a que es un sistema que cuenta con un gran número de ventajas, no se termina de apreciar un importante grado de implantación en las organizaciones y cuando digo implantación, no me refiero a un uso esporádico de esta tecnología, sino a su integración en la realización de determinadas tareas en distintos procesos de las mismas. En este artículo voy a pasar a analizar cuáles son, a mi juicio, las ventajas e inconvenientes de este tipo de sistemas.
La principal ventaja de las videoconferencias ya sea en comunicaciones 1:1, 1:N, N:N o N:M es sin duda la eliminación de la necesidad de desplazarse para que un grupo de personas puedan comunicarse. Esto no es ninguna tontería sobre todo si lo medimos en criterios económicos y de ahorro de tiempo, es decir, ¿cuántas veces hemos tenido que desplazarnos cientos de kilómetros para una reunión que ha durado un par de horas?,v¿cuánto cuesta mantener esta forma de funcionar al año?. Además y, como consecuencia de lo anterior, incrementa la disponibilidad de los intervinientes en la misma.
Esas ventajas, desde luego son lo suficientemente importantes como para que cualquier organización pueda plantearse el uso de las mismas. No obstante, el éxito de la implantación de un sistema de estas características dependerá de una serie de factores:
1) Un factor muy importante son las características de la organización en la que se pretende implantar, es decir, si no existe mucha dispersión geográfica entre las diferentes sedes, no existe la necesidad de reunirse con frecuencia, el resto de organizaciones con las que mantiene contacto no tienen implantado un sistema de estas características, etc… serán circunstancias que provoquen que al no ser un elemento que mejore sustancialmente los procesos y además ahorre dinero, dificultarán la implantación de un sistema de videoconferencia. Por tanto, la cuestión no es intentar meter esos sistemas con calzador, sino realmente estudiar si merece la pena en función de las características y circunstancias de la organización.
2) Otro factor son los usuarios, ya que independientemente de que pueda resultar beneficioso, si éste no decide cambiar de costumbres, no le ve las ventajas o es el único que se interesa en esto, probablemente la implantación se encuentre con problemas. Si los usuarios no quieren, será difícil por tanto conseguir que este tipo de sistemas tengan durabilidad y/o utilidad en la organización. No obstante, en bastantes casos se puede atajar este problema mediante instrucciones por parte de la dirección y en otros intentar conseguir que los usuarios entiendan los beneficios para ellos y la organización mediante un completo proceso de gestión del cambio.
3) Ya lo he indicado en el punto número 1), pero no está de más recordar que si en una videoconferencia tiene que haber bidireccionalidad, la otra parte también debe emplear un sistema de estas características, es decir, una empresa dedicada a la exportación de determinados tipos de artículos puede ver las indiscutibles ventajas de utilizar este tipo de sistemas para reducir el número de viajes a los diferentes países con los que opera y por tanto reducir costes, pero claro, si el resto de de empresas con las que trata no acostumbra a utilizar este tipo de sistemas no se conseguirá el objetivo que se marcó al realizar la implantación de la videoconferencia como otro medio de comunicación más.
Ya hemos visto, algunas de las principales ventajas de la implantación de este tipo de sistemas, no obstante, tampoco hay que ir al extremo de pensar que gracias a la videoconferencia se eliminarán todo tipo de reuniones, ya que en muchos casos y circunstancias será más aconsejable el trato personal directo.
Por tanto, se trata de la incorporación de una utilidad más, como en su día lo fueron el teléfono, el fax, el correo electrónico, etc… para poner en comunicación personas y que utilizada en un entorno y circunstancias favorables a su implantación tiene consigo grandes ventajas, tanto para las personas como para la organización.

http://jummp.wordpress.com/2009/10/28/videoconferencia-aspectos-positivos-y-negativos/

Complejidad ciclomática

La complejidad ciclomática es una métrica a tener en cuenta para evaluar la mantenibilidad, comprensión, testeabilidad y probabilidad de errores de una determinada aplicación.
Este término fue propuesto por Thomas J. McCabe en 1976 y tiene como una de sus características principales su independencia respecto a los lenguajes de programación (por lo menos, de los más convencionales), por lo que teóricamente podrían ser comparables aplicaciones realizadas con tecnologías distintas en base a su complejidad ciclomática. Digo teóricamente, porque además de la algorítmica las características propias del lenguaje de programación pueden influir en que sean más sencillas o no su inteligibilidad, mantenibilidad, etc… No obstante y en cualquier caso, resulta una aproximación muy a tener en cuenta de esos factores.
¿Qué mide la complejidad ciclomática? Pues el número de posibles caminos lógicos que tiene una aplicación. ¿Quiénes crean esos posibles caminos lógicos? Los métodos, las sentencias selectivas (if, case), sentencias iterativas (while, for), lanzamiento y tratamiento de excepciones (throw, catch), devolución de resultados de un método cuando no es lá última línea del mismo (return), operadores lógicos en guardas, etc…
Cuanto más caminos lógicos tenga una aplicación, una clase o un método más complejo resulta y por tanto, requiere un mayor esfuerzo desde el punto de vista de las pruebas unitarias (el número de pruebas unitarias para recorrer todo el código crece linealmente con la complejidad ciclomática (además de cumplirse eso, se verifica que: 1) la complejidad ciclomática es menor o igual que el número de casos de pruebas que se requiere para hacer cobertura de todo el código de la aplicación (téngase en cuenta que los else no suman complejidad ciclomática), 2) la complejidad ciclomática es mayor o igual que el número de casos de prueba que se requieren para verificar que realmente se “abren” los distintos caminos físicos)).
Por tanto, una baja cobertura de una aplicación viene a decir que existe una gran cantidad de código que no se ha verificado (utilizando esta estrategia), que se recorra, por lo que probablemente si no se ha recurrido a pruebas intensivas de la aplicación, muy probablemente se traduzca en errores evitables que se detectan posteriormente, incluso en producción).
También se requiere un mayor esfuerzo para la mantenibilidad y comprensión del código (¿cuántas veces nos hemos perdido en un mar de sentencias if anidadas?) y por todo lo anterior se incrementan las posibilidades de que existan errores, porque ¿cuántas veces nos hemos encontrado con que un problema en un método era provocado porque no se metía por la guarda correspondiente de una condicional o porque no entraba en un determinado bucle?, por lo que simplemente la mera experiencia nos indica que debe existir una relación entre la complejidad ciclomática y el número de errores de una aplicación.
Como la complejidad ciclomática es el resultado de los diferentes caminos lógicos que puede tener una aplicación es lógico que esta crezca conforme más extensa (en líneas de código) es una aplicación y por regla general una aplicación con muchas funcionalidades, grande, etc…, es más compleja, requiere mayor codificación y tendrá como consecuencia una mayor complejidad ciclomática (de esta manera existirá prácticamente una relación entre una clasificación de las aplicaciones por líneas de código y una clasificación de las aplicaciones por complejidad ciclomática, es importante señalar que no tienen por qué conservar el mismo orden aunque sí más o menos estarán por el mismo entorno, es decir, la segunda aplicación con más líneas de código, puede ser la cuarta en complejidad ciclomática o la quinta aplicación con más código, la segunda en complejidad. Por tanto este tipo de complejidad es inherente a las aplicaciones y existe por el simple hecho de la existencia de las mismas y por tanto, aplicaciones con envergadura se traducen en aplicaciones complejas de mantener y eso es consecuencia de su complejidad ciclomática intrínseca.
Independientemente de que una codificación eficiente puede eliminar caminos lógicos innecesarios, existe un límite y es el que da la propia dinámica de funcionamiento de un sistema de información que provoca que se codifique su comportamiento en algoritmos que como se han comentado anteriormente pueden ser complejos. Cuando se aproxima a este límite, lo más que se puede hacer es utilizar la complejidad ciclomática para determinar si determinados métodos o clases son demasiado complejas y requerirían ser analizadas de cara a dividirlas en otras más simples, mejorando así la mantenibilidad de las mismas.
Existen algunas clasificaciones basadas en rangos de complejidad ciclomática que determinan cuando es recomendable hacer la simplificación de determinadas clases y métodos y también hay casos de éxito de la aplicación de los mismos en algunas compañías.
En muchas ocasiones a simple vista se puede determinar si un método o una clase tienen una complejidad ciclomática alta, no obstante, esta tarea puede ser agotadora si la aplicación a analizar es muy grande, por ese motivo, lo mejor es delegar esa función en analizadores estáticos de código, como es el caso de Sonar, que permite obtener métricas de la complejidad ciclomática tanto a nivel de aplicación, como de clases y de métodos y utilizando su implementación de funcionalidades de drill down ir de datos más generales a información más de detalle.
Como todas las métricas de ingeniería del software, no hay que tomarse los resultados de la complejidad ciclomática al pie de la letra, sino saber interpretar qué es lo que están diciendo y tomar medidas para reducir el impacto de dicha complejidad en la aplicación (mayor cobertura de pruebas unitarias) y para tomar decisiones de revisión de la codificación en métodos y clases complejos y su posible simplificación en otros más sencillos.

http://jummp.wordpress.com/2010/04/27/complejidad-ciclomatica/

Entrevista: Curso de “Técnicas Avanzadas para Testing Automatizado”

Sumario

Entrevista al Dr Marcelo Frias vinculada con el curso de Técnicas Avanzadas para Testing Automatizado a celebrarse en la RIO 2013.

Testing Automatizado, Entrevista

Introducción

Es interesante tener conocimiento acerca de los cursos intensivos que tendrán lugar en la RIO 2013, desde el 18 al 23 de febrero de este año, donde el Dr Marcelo Frias estará dando este curso.

Desde el sitio oficial, hay un enlace que nos permite bajar un archivo comprimido que contiene 8(ocho) archivos con material vinculado con la formación.

Las ‘Técnicas Avanzadas para Testing Automatizado’, es un área de conocimiento que ya esta con nosotros y las tendencias indican que será una práctica que acompañará a todo proyecto de testing, sea cual fuere éste, de ahora en más.

En virtud a ello, y como venimos siguiendo el tema no solo desde este blog sino además desde el Grupo de Discusión (TESTING & QA) a través de los distintos Debates y Encuestas publicadas, es que nos pusimos en contacto con el Dr Frias para proponerle una entrevista y conocer más en detalle acerca de estas jornadas, su experiencia anterior, el alcance del curso, qué espera del mismo, y su opinión respecto a la tendencia de estas prácticas.

Entrevista (TB:TestingBaires/MF:Marcelo Frias)

1.TB: Profesor, si bien visitando el sitio oficial de RIO 2013 se puede acceder al alcance de esta formación, ¿Cómo podría brevemente explicar porqué es útil y/o necesario contar con este conocimiento?

MF: Antes de contestar quiero agradecerles por el interés en la Rio2013 en general, y en el curso que dictaré en particular. La Rio2013 es la vigésima edición de la Escuela, y la misma ha sido de inmensa ayuda para miles de estudiantes argentinos que han accedido a cursos dictados por científicos y/o tecnólogos nacionales y extranjeros de primer nivel.

El curso que voy a dictar en esta edición de la Escuela tiene por objetivo presentar una serie de técnicas de testing que normalmente no forman parte de la formación de grado brindada por las Universidades Públicas o Privadas argentinas. Estas técnicas permiten generar tests de manera automática, al mismo tiempo que poseen buenas propiedades como por ejemplo el garantizar buena cobertura de condiciones o garantizar una alta taza de mutantes eliminados.

Definición: Dado un método M, un mutante de M es un método M’ que difiere de M en que una (1) de sus sentencias ha sido mutada. Una mutación de una sentencia s es el reemplazo de alguna parte de s por otra expresión. Por ejemplo, en la sentencia “i++;”, se puede reemplazar el operador aritmético ++ por –. En una sentencia “x = y + x;” se puede cambiar + por -, o alguna de las variables por otra de un tipo compatible.

2.TB: Actualmente ¿Cuáles son las acciones que Ud está llevando a cabo para difundir este tipo de prácticas?

MF: El dictado de este curso es una de ellas. Se suma al dictado de un curso con objetivos similares durante la Escuela de Ciencias Informáticas (ECI 2012) en Exactas-UBA por parte de mi colega el Prof. Nazareno Aguirre, y seguramente organizaremos más actividades incluso a través de la cooperación con TestingBaires.

TB: Cuenten con nosotros para toda difusión y/o colaboración en conjunto.

3.TB: ¿Considera que en Argentina esta práctica es común o se encuentra en crecimiento?

MF: Ciertamente el testing en general es una actividad ampliamente adoptada en los procesos (ágiles) de desarrollo. Considero que las técnicas en las que se basa el curso deben tener una mayor presencia dado que permiten incrementar la productividad y efectividad de los testers. Ciertamente varias de las herramientas que utilizaremos en el curso no tienen actualmente la presencia que merecen en el portfolio de herramientas de los testers.

4.TB: ¿Qué beneficios le trae a la empresa tener personal certificado para llevar a cabo este tipo de técnicas?

MF: Algunas de las herramientas presentadas en el curso son aún de fuerte tenor académico, y no están aún en condiciones de ser adoptadas en el trabajo diario. Sin embargo, otras pueden brindar importantes beneficios. Un escenario de uso particularmente interesante es el siguiente: si deseamos tener test suites que garanticen un cierto tipo de cobertura, y nuestros tests aún no lo brindan, hay herramientas entre las que veremos en el curso que permiten incrementar esta cobertura y de esta forma mejorar la calidad de nuestras suites.

5.TB: ¿RIO 2013 tiene algún tipo de comunidad donde el Tester interesado pueda acceder a información y beneficios relacionados?

MF: No hay una comunidad formalmente organizada para tal fin, pero ciertamente es posible organizar una, o mejor aún colaborar con TestingBaires que ya tiene una comunidad ávida de conocimiento y de nuevas tecnologías.

TB: Será un honor que integre principalmente la comunidad actual que compone el grupo de discusión en LinkedIn : TESTING & QA. Para ello, hay dos requisitos fundamentales: (1) Hacerse miembro de la red LinkedIn, (2) Unirse al grupo de discusión TESTING & QA (Aclaración: el nombre del grupo es todo en mayúscula). El sistema interno de LinkedIn nos envía la solicitud para unirse al grupo, y apenas la autorizamos, el interesado ya formará parte del grupo pudiendo acceder / participar de todos los distintos Debates, Promociones y Ofertas Laborales que están publicadas (el 8% de la comunidad son miembros de RRHH), además de enterarse de novedades de charlas y formaciones virtuales que se darán durante el año anunciadas por los propios miembros del grupo, o que Ud mismo proponga. Por supuesto que todo este comentario vale hacerlo extensivo a toda la comunidad universitaria (alumnos y profesores) que se muestre interesada por este área de conocimiento.

6.TB: ¿Cuáles son las ventajas a nivel profesional que le puede brindar a un tester tomar este curso intensivo?

MF: Este es un curso planteado (fundamentalmente) para estudiantes universitarios de grado y, como tal, incluye conceptos teóricos además de herramientas y tecnología.
Pero hay una versión de este curso pensada para profesionales que se centra en el buen uso de estas herramientas. Entre las herramientas hay desde herramientas utilitarias que permiten medir la cobertura lograda con una suite, hasta herramientas que permiten generar datos de test que garantizan cubrir un lugar específico escogido por el tester dentro del código. Dentro de estas últimas hay distintas herramientas que se distinguen por los dominios en los que consiguen mayor cobertura, por ejemplo.

7.TB: ¿Está pensando en organizar reuniones ‘físicas’ en Buenos Aires?

MF: Sí. El plan es organizar un ciclo de encuentros centrados en una herramienta diferente en cada uno. En los mismos se explicarán los fundamentos que hacen a esa herramienta especial, las cualidades de la misma, cómo instalarla, y si la cantidad de asistentes lo permite, una experiencia “hand-on” utilizando la herramienta.

8.TB: ¿Está pensando en organizar reuniones ‘Virtuales’ en Buenos Aires?

MF: La verdad que en este momento estoy más interesado en organizar encuentros presenciales, pero no lo descarto como una actividad a realizar de manera esporádica, o en el futuro de forma periódica.

9.TB: ¿Qué le recomendaría al Tester que todavía tiene dudas sobre si encarar o nó el estudio de este tipo de técnica?

MF: Primero y fundamental, estudiar siempre es bueno. Aún si el resultado de ese “estudio” es que una cierta técnica/herramienta no es del agrado de uno, al menos uno tendrá la certeza de que la está descartando en base a una decisión informada, y no por desconocimiento. Y por supuesto es muy posible que algunas de las técnicas efectivamente sean de su agrado y utilidad, y decida adoptarlas.

10.TB: ¿Hay algo que nos quiera contar y que sea de interés general para la Comunidad de Testers?

MF: El testeo del software es sin dudas una actividad central en el desarrollo de software porque es una forma de análisis de software que es escalable y relativamente sencilla (en comparación a otras técnicas). Sin embargo, el testeo de una aplicación tiene limitaciones importantes. Por ejemplo, salvo en contadas excepciones no brinda información sobre el comportamiento de la aplicación fuera de los inputs testeados. Si se adopta la práctica de utilizar contratos en las clases, entonces es posible utilizar técnicas que brindan mayor confianza acerca de la aplicación testeada al concluir que esta es correcta para cientos de miles o incluso millones de tests (que por supuesto se generan automáticamente). Estas técnicas se presentarán en el curso en la Rio2013 si el tiempo lo permite.

Agradecemos al Dr Marcelo Frias por su predisposición durante la entrevista y todo la información que nos ha dado.

Prof. Dr. Marcelo F. Frias
Profesor Titular, Instituto Tecnológico de Buenos Aires
e-mail: mfrias@itba.edu.ar
Investigador del CONICET

Nota: Esta entrevista ha sido publicado en TESTING & QA (grupo de discusión en LinkedIn) donde podrás seguir los debates que se inicien de la misma.

http://testingbaires.com/entrevista-curso-de-tecnicas-avanzadas-para-testing-automatizado/

The lines are getting blurred

I hear about this all the time when I talk to PractiTest’s users.  You can read about it in the blogs and tweets of our fellow testers.  People in QA conferences are talking about it more and more…
The trend is clear.
For most testers this is not an easy change.
At the beginning it frightened me. Then I learned to live with it.  And, as I immersed myself into this new reality, I started to realize the incredible range of opportunities and improvements it offered both to development teams in general and to testers in particular.
What am I talking about…?
The fact that today the lines that separate between developers and testers are getting blurred, resulting in more and more testing tasks being done by the developers within our teams.

This is not happening in your team… Or is it?

The first reaction I get when I bring this subject up with fellow testers is that in their company this is not happening.
Then, when I ask if programmers are doing more tests today than they did 3 or 5 years ago the faces and tones suddenly change and become less secure.
Everywhere you look at developers are getting more involved in testing.  They are writing more unit tests, Continuous Integration practices are common in many organizations, there are more programmers walking up to testers with questions about testing scenarios, etc.

The “virtual wall” previously used by developers to toss the product over to the testing team now has many doors and windows that both teams use to communicate and even collaborate.

What does this mean to the organization?

For starters it means that programmers need to learn how to test.
Testers get a chance to teach our development peers that testing (or at least good testing) is not a trivial task of randomly pressing buttons on the screen or typing “asdf” into text fields to ensure you can enter data into the system.
We’ve become testing mentors, explaining about testing scripts and testing data, reviewing positive and negative scenarios, explaining about pairwise testing and the testing heuristics we use.
Additionally, this change also means that our project teams now allocate time for developers to test their code. Even if this sounds trivial at first it is a big mental shift in the way companies prioritize their tasks, especially when projects get close to their deadline and time becomes the most scarce resource in the team.

What does this mean to us as testers?

I already wrote  that we’ve become mentors to our development peers. But does that mean that we are actually teaching our work to others in order to be relieved of our duties in the near future?
At first this is what frightened me, not personally for my future, but for the future of our career as a whole.
I was afraid that testers would become another VHS player or another Fax Machine, useful in the past, but doomed to extinction as times and technology advanced.
But then I realize that this was only partly true.
It is true that part of our job is being migrated to others in our organization, but it is also true that we are being given more responsibilities within the team and also being offered the chance to influence more on our process and the outcome of our projects.
In many places testers today have become strategists and advisors, working from the early stages of the project in order to assess and plan the overall development approach of each feature based on it’s requirements, risks and also based on what will need to be tested and how.
We’ve also been given more responsibilities to work with users both before as well as after the product has been delivered to them.
We are also being asked to perform more technical tasks, planning and architecting large parts of the automatic testing framework that will serve both developers and tester in our work.
Depending on the type of environments and companies we work in, testers are being given additional tasks.  For example, in many SaaS companies (such as PractiTest) testers are tasked with many of the deployment and production monitoring operations, as well as troubleshooting issues happening to customers in their real-work environments.  As a friend of mine put it some weeks ago, it is not about whether a bug is happening or not, but about how many times it is happening and to what percentage of our users…
And obviously, we are being asked to compile all the information that relates to the project and its quality status.  Giving a live, clear and concise overview to the rest of the team on the state of the product, the status of the process and the ways in which both of them can be improved.

What is the next step…?

I am not sure what the next step will be, but as I said before the trend is clear and the lines between testers and developers are getting blurred.
For the good or the less good (let’s keep optimistic) this is happening and it is something we all should be aware off in order to be prepared for the changes that will continue coming in the future.
Are you seeing this in your company?
How is this changing the way you work today?
Share with us your experience to understand how is this new reality changing your life and your work as a tester!

http://qablog.practitest.com/2013/11/the-lines-are-getting-blurred/

El papel de los usuarios en un proyecto de desarrollo de software

Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de desarrollo de software, mayores serán las probabilidades de éxito que tenga el mismo.
No obstante es importante hacer algunas matizaciones:
1) El proyecto no se hace sólo, porque incluso existiendo una gran ayuda por parte de los usuarios, si no se consigue interpretar con precisión lo que quieren y no se dinamiza un feedback continuo de los mismos durante todo el proceso de desarrollo, se incrementarán las posibilidades de que algún requisito funcional no se haya recogido adecuadamente o de que se haya realizado un software con una usabilidad incómoda para los usuarios.
Estas circunstancias son fuente de innumerables problemas en las fases finales del proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, además de crear conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo. Esto hace que sea fundamental el papel que desempeñan tanto el jefe de proyectos, como el equipo de analistas funcionales y analistas programadores.
2) Es importante que entre el grupo usuarios asignados al proyecto haya usuarios que vayan a estar implicados en el futuro uso del sistema de información, es decir, no es suficiente que el equipo de usuarios esté formado por “ideólogos” o “teóricos” que se nutrirán del resultado del trabajo de la herramienta, sino que es fundamental que participen usuarios que después se tengan que poner el mono de trabajo y vayan a trabajar con el software. Es importante conseguir la combinación de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no participen usuarios directores, ya que pueden existir conflictos entre usuarios que éstos deben solucionar y también es recomendable que el software no sólo se diseñe para el corto plazo, sino que sirva para tareas de gestión, planificación, etc… y esta visión la proporcionan principalmente los usuarios directores), por lo que el jefe de proyectos debe poner en conocimiento del cliente esta necesidad, como es lógico explicando los riesgos de que no se aplique esta estrategia.
3) Los analistas están para ayudar y para colaborar con los usuarios en la especificación y diseño de la solución, pero no están para “dar lecciones” a los usuarios y enseñarle cómo deben hacer su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no sea la más ortodoxa, siempre tendrá una justificación que sólo se entendería si realmente estuviéramos haciendo su trabajo durante un tiempo y viéramos los problemas con los que se enfrentan cotidianamente. La clave por tanto está en la colaboración y en el diálogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una vuelta al calcetín de cómo hacen sus tareas, salvo que ellos mismos lo soliciten y procurando en estos casos y en consenso con los usuarios que los cambios sean tranquilos.
4) Es fundamental documentar el proyecto, en primer lugar con la documentación que se especifique en las normativas de desarrollo de la organización para la que se realiza el servicio, con las matizaciones que indique el Director del Proyecto, en segundo lugar con la documentación que establezcan las normativas internas de calidad de tu organización (no requerirá un sobreesfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo anterior sumarle toda la documentación de trabajo que sea necesaria para trabajar con los usuarios, que no tienen por qué entender de modelos de datos, de diagramas de casos de uso, etc…, es más, es un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son de utilidad técnica y no hablan el mismo lenguaje de los usuarios. Este tipo documentación, por tanto, no tiene por qué tener los formalismos de la técnica y tiene como objetivo que el usuario capte lo que el analista está interpretando y se pueda ir perfilando a partir de esto, tanto requisitos, como casos de uso, interfaces, etc… Es muy importante trabajar todo esto, ya que comenzar demasiado pronto con la construcción, es algo muy arriesgado, ya que los costes de modificar algo en las distintas fases de la construcción pueden ser muy importantes y provocar que se tengan que reconstruir varias veces distintas funcionalidades de la aplicación.

http://jummp.wordpress.com/2010/02/13/el-papel-de-los-usuarios-en-un-proyecto-de-desarrollo-de-software/

You report too much defects! OR Defect triaging.

Ever heard “You report too much defects” from a developer or project manager? Before blaming them for being not committal for quality, try understanding that number of defects is not the only (and even not the right) quality measure. With this post I will try to share my experience on assuming responsibility for not-reporting certain defects – performing triage, thus helping to achieve better quality (due to both logical and psychological reasons).
Black tag in Triage: the most difficult to assign
According to wikipedia
Triage is a system used by medical or emergency personnel to ration limited medical resources when the number of injured needing care exceeds the resources available to perform care ...
Red - Emergent
Yellow - Urgent
Green - Nonurgent
Black - Dead or very severely injured and not expected to survive
... Patients who are severely injured and not expected to survive are the most difficult to assign because of the obvious ominous implications

The term triage is adopted for describing process of prioritizing defect fixes. And I want to stress that giving black tags are part (and the most significant in my opinion) of that process. If your development resources are limited (and they typically are) you want to give Black tag to defects that are too hard to fix, don’t you? Well defects are not people so it should be simpler to assign the black tag without morale complications, shouldn’t it? You may also include business priorities in tagging defects unlike battlefield patients triaged “with no regard to rank”. I still have seen a lot of testers unwilling to accept fact that correctly reported defect is cancelled with comment “legacy defect”, “accord to the specification” or simply “fixing is rejected”.
Documented and known defects
Do you know the joke: documented defect is no more defect – it is a feature. This is not a joke – it is reality the industry I work (probably it is not so in military or medical software industry /isn’t it strange however that those are areas where triage comes from :) / ). Cost and time-to-market are key factors (quality tend to have the secondary role) for products. For solutions key factors for success are unfortunately: I. show potential customer that you are the best to do this work (which not necessarily be truth) and II. Implement your contract obligations (e.g. pass all UAT tests or even worse – 95% of them, no matter how many bugs there are outside those tests).
So I believe you are used to see your management to add your reported defect to “list of known problems” as a problem resolution.
The problem here is that none is reading those known problems list until thy run into the problems. You are lucky if the known problem includes workaround acceptable for customer. If not – it may appear they will find alternative software and will hate your product forever because of effort put into trying to use it. I don’t believe that describing defect as know issue is THE ultimate solution. It may sometimes be better not to describe it, wait for customer to report and then implement a solution customer for each customer.
Less is more
In battlefield triage is associated with evacuation. Prioritization is aimed to understand whom to evacuate first. Those tagged black are left on battlefield and given painkillers to ease their passing. This will help you to evacuate those tagged red – otherwise they will die within few hours.
You don’t need to give painkillers for defects. If you left them on battleground (in the software) it will help your team to concentrate on fixing other defects.
“Secondary triage is typically implemented by paramedics, battlefield medical personnel or by skilled nurses”. Tester should learn to be “battlefield medical personnel”, which is not so simple however and requires understanding of the project and customer context.
What you will gain is more respect from developers and management, more respect to defects you report and more of them fixed as a result due to both technical and psychological reasons

http://testingreflections.com/node/4699

La crisis del software

La crisis del software, en mi opinión, es algo que todavía no se ha superado, desde que se empezase a hablar de ella, en la década de los sesenta, a partir del genial holandés Edsger Dijkstra en su obra “The Humble Programmer”
Bien es cierto, que hay autores, con un prestigio infinitamente multiplicado por infinito superior al mío, que consideran que es algo que está superado, como por ejemplo, Roger S. Pressman, que lo redefine como aflicción crónica, al existir cada vez más casos de éxito.
Mi experiencia, al menos en el segmento en el que me muevo, es que se quiera llamar como se quiera, la crisis del software sigue presente.
La crisis del software se refiere principalmente a las siguientes características del proceso de desarrollo:
- Incumplimiento sistemático de los plazos de entrega.
- Desajuste entre el presupuesto inicial estimado y el presupuesto final del proyecto.
- Baja calidad del producto final: Incumplimiento de especificaciones y dificultad de mantenimiento.
Que alguien me diga en qué porcentaje de los proyectos en los que ha participado como programador, analista, jefe de proyectos o gerente se ha cumplido algunas de las premisas anteriores. En bastantes, ¿verdad?.
Por eso pienso que la crisis del software continua, por mucho que la aparición del concepto de ingeniería del software o de múltiples metodologías hayan intentado paliarla.
Bien es cierto, que las bases para eliminar la crisis del software en un proyecto de desarrollo de software son muy conocidas por todos, lo que pasa es que son tantos los ingredientes a utilizar (unos dependientes del grupo de desarrollo y otros no) para que un proyecto salga bien en plazos, presupuesto y calidad, que no resulta nada sencillo (aunque no es imposible) conseguirlo.
Por todo lo anterior, pese a que la solución tiene una base metodológica y de disciplina (de todas las partes que intervienen en el proyecto, teniendo mucho peso la parte usuaria), la base para arreglarla es cultural, es decir, la adquisición de buenos hábitos de base para el desarrollo de proyectos software (ya que sin esta cultura, la metodología se llenará de polvo en las estanterías y la disciplina un bien perecedero) y la erradicación de los mitos del software en todas sus vertientes.
Nadie tiene la llave para ser infalible en los proyectos de desarrollo de software, es decir, como he dicho antes, un proceso de desarrollo tiene muchos condicionantes y es muy complicado manejarlos todos, sobre todo cuando no dependen de uno. En cualquier caso, lo que hay que intentar siempre es tender a hacer las cosas de la mejor manera posible y a intentar cumplir los objetivos de plazos, presupuestarios y de calidad, porque si hay una cosa que debe clara a todos, es que si un proyecto no se enfoca hacia esos objetivos, es complicado, muy complicado, que se consigan por casualidad.

http://jummp.wordpress.com/2009/05/22/la-crisis-del-software/

Bug Tracking Tools

Web Based Bug Tracking

Product	Vendor	Comments
AceProject	Websystems	Free bug tracking software designed for project managers and developers. Try the demo version and then create your free account.
AdminiTrack	AdminiTrack	Hosted issue and bug tracking application
ADT Web	Borderwave	Advanced Defect Tracking Web Edition is a bug-tracking solution designed for small, medium and large software companies to simplify their defect, suggestion and feature request tracking. The software allows you to track defects, feature requests and suggestions by version, customer etc.
Agility	AgileEdge	Issue and Bug Tracking Software. Agility features a easy to use web-based interface. Key features include fully customizable field lists, workflow engine, and email notifications.
AsiTrack	AsiTrack	AsiTrack is an 100% native issue tracker designed exclusively for software companies. Some of it's features are: dedicated features and user interfaces for project managers, developers and testers easy to install and automatic database management built-in real-time notifications system personalized activity reports issues, versions and projects are displayed as a tree, so everything is visible and can be managed easily
Assembla Tickets	Assembla	Hosted issue and bug tracking tool. Integrated with Hosted Repositories (SVN, Hg, git) and other collaboration Tools. Written in Ruby On Rails.
Bontq	BONTQ LLC	Online bug & issue tracking system and a project management tool. Main features: Integrated Desktop Client that makes screenshots and captures videos, email notifications, wiki, reports, team management, test cases, attachments, search, projects, companies, google docs integration, import from fogbugz and basecamp, customizable interface.
Bug/Defect Tracking Expert	Applied Innovation Management	Web-based bug tracking software
BugAware.com	bugaware	Bug tracking solution. Installed and ASP hosted service available. Features include: Email alert notification, knowledge base, dynamic reporting, team management, user discussion threads, file attachment, searching.
bugcentral.com	bugcentral.com	Web based defect tracking service
BUGtrack	SkyeyTech, Inc.	Web based defect tracking system
BugHost	Active-X.COM	BugHost is a feature-complete hosted defect tracking system ideal for small- to medium-sized companies who want a secure, Web-based issue and bug management system. There is no software to install and can be accessed from any Internet connection. Designed from the ground up, the system is easy to use, extremely powerful, and customizable to meet your needs.
BugImpact	Avna Int.	Professional issue-tracking and project management system. Unlimited: projects, entries/bugs/issues Web access: users access their BugImpact service through a standard Web browser Workflow configurations control: BugImpact installs with a default workflow configuration that can easily be changed or replaced entirely File attachment: details thread may contain attachments, such as screenshots, Excel spreadsheets, internal documents or just any binary files. E-mail notification: the system sends e-mail notification to users when new bugs are assigned or status changes Builds : project(s) may have a specific 'fix-for' version with optional deadline Priority Colorize: custom colors may be associated with different priorities And many other features.
BugStation	Bugopolis	Web-based server appliance featuring Bugzilla with many enhancements designed to make Bugzilla easier and more secure. A centralized system for entering, assigning and tracking defects. Configurable and customizable.
Bug Tracker Software	Bug Tracker Software	Web based defect tracking and data sharing
Bug Tracking	Bug-Track.com	Free defect tracking system. Our system is fast and easy to use. We offers email notification, file attachment, tracking history, bilingual pages, 128-bit encryption connection and advance customization. Free demo.
Bugvisor	softwarequality, Inc.	Enterprise solution for capturing, managing and communicating feature requests, bug reports, changes and project issues from emergence to resolution with a fully customizable and controllable workflow
Bugzero	WEBsina	Web-based, easy-to-install, cross-platform defect tracking system
Bugzilla	Bugzilla.org	Highly configurable Open source defect tracking system developed originally for the Mozilla project
Census BugTrack	MetaQuest	Fully customizable bug tracking and defect tracking tool. Includes VSS integration, notifications, workflow, reporting and change history.
DefectTracker	Pragmatic Software	Subscription-based bug/problem tracking solution
Defectr	Defectr	A free online defect tracking and project management tool developed using IBM Lotus Domino and Dojo Ajax framework.
Dragonfly	Vermont Software Testing Group	Web-based, cross-browser, cross-platform issue tracking and change management for software development, testing, debugging, and documentation. It is available by subscription or for purchase as a self-hosted intranet/Internet application.
ExDesk	ExDesk	Bug and issue tracking software, remotely hosted, allows you to tracking software bugs and route them to multiple developers or development groups for repair with reporting and automatic notification.
FogBUGZ	Fog Creek S/W	Web-based defect tracking. Free eval, 90 day money back guarantee.
Fast BugTrack	AlceaTech	Fast BugTrack is a market leader in bug tracking solutions. Completely Web-enabled, quick to install, and easy to use, Fast BugTrack offers you the ability to track bugs, coordinate projects, and effortlessly manage the change process within your organization.
Footprints	Unipress	Web-based issue tracking and project management tool
IssueTrak	Help Desk Software Central	Offers issue tracking, customer relationship and project management functions.
JIRA	atlassian	J2EE-based, issue tracking and project management application. Extensible via Java API.
Jitterbug	Samba	Freeware defect tracking
JTrac		Generic issue-tracking web-application that can be easily customized by adding custom fields and drop-downs. Features include customizable workflow, field level permissions, e-mail integration, file attachments and a detailed history view.
Mantis		Lightweight and simple bugtracking system. Easily modifiable, customizable, and upgradeable. Open Source.
MyBugReport	Bug Tracker	Online testing tool that allows the different participants working on the development of a software or multimedia application to detect new bugs, to ensure their follow-up, to give them a priority and to assign them within the team.
OnTime Now!	Axosoft	Cloud Bug Tracking and Issue Tracking software that integrates with Visual Studios. Some features include a customer portal, wiki, Planning board, iPhone App, custom work flows, and more. Project management software suitable for Agile and Scrum development.
Ozibug	Tortuga Technologies	Platform-independent defect tracking system. Written in Java, it utilizes servlet technology and offers features such as reports, file attachments, role-based access, audit trails, email notifications, full internationalization, and a customizable appearance. Two editions of Ozibug are available, the fully featured Enterprise Edition including support and upgrades is available for purchase online through a secure payment server, while the basic Community Edition is available at no cost.
Perfect Tracker	Avensoft	Web-based defect tracking
ProblemTracker	NetResults	Web-based collaboration software for issue tracking; automated support; and workflow, process, and change management.
ProjectLocker	ProjectLocker	Hosted source control (CVS/Subversion), web-based issue tracking, and web-based document management solutions.
PR Tracker	Softwise Company	Records problem reports in a network and web-based database that supports access by multiple users. Features include classification, assignment, sorting, searching, reporting, access control, & more.
QEngine	AdventNet	100% web-based issue management software that offers you the facility of tracking and managing bugs, issues, improvements, and features. It provides role based access control, attachment handling, schedule management, automatic e-mail notification, workflow, resolution, worklogs, attaching screenshots, easy reporting, and extensive customization. The free version is completely functional and can be used for a maximum of 2 users.
SpeeDEV	SpeeDEV	Start using this from the very beginning of the project to track any kind of issue (Business, Technical, Bugs, Infrastructure); Rule-based assignment of issues for resolution; Notification/ Reminder for deadlines; Tracing Issues back to Requirements; Statistical Matrix for analysis. A complete visual design of a multi level rol based process can be defined for different types of issues with conditional branching and automated task generation.
Squish	Information Management Systems, Inc.	Web based issue tracking
Task Complete	Smart Design Te	TaskComplete enables a team to organize and track software defects using with integrated calendar, discussion, and document management capabilities. Can easily be customized to meet the needs of any software development team.
teamatic	Teamatic	Free enterprise defect tracking system
TrackStudio	TrackStudio	Flexible and customizable Java-based defect tracking software. Supports workflow, multi-level security, rule-based email notification, email submission, subscribe-able filters, reports. Has skin-based user interface. Supports ORACLE, DB2, MS SQL, Firebird, PostgreSQL, Hypersonic SQL and more. It may or may not be free, depending on how you intend to use it.
VisionProject	Visionera AB	Web based issue tracking and project collaboration tool designed to make projects more efficient and profitable.
Woodpecker IT	AVS GmbH	Web-based request, issue or bug tracking tool. You can use it for performing request, version or bug management. Its main function is recording and tracking issues, within a freely defined workflow.
yKAP	DCom Solutions	Uses XML to deliver a powerful, cost effective, Web based Bug/Defect tracking, Issue Management and Messaging product. Apart from having a pleasing interface and being easy to learn, yKAP features include support for unlimited projects, test environments, attachments, exporting data into PDF/RTF/XLS/HTML/Text formats, rule-based email alerts, exhaustive search options, saving searches (public/ private), Auto-complete for user names, extensive reports, history, custom report styles, exhaustive data/trends analysis, printing, role-based security. Apart from pre-defined values, yKAP allows the user to add custom values for system parameters such as Status, Defect cause, Defect type, priority, etc. yKAP is installed with complete help documentation.

Return to Top of Page

Bug Tracking Applications

Product	Vendor	Comments
assyst	Axios Systems	Offers a unique lifecycle approach to IT Service Management through the integration of all ITIL processes in a single application.
BridgeTrak	Kemma Software	Record and track development or customers issues, assign issues to development teams, create software release notes and more. Free trial.
BugRat	Giant Java Tree	Free Java software that provides a defect reporting and tracking system. Bug reporting by the Web and email.
BugSentry	IT Collaborate	Automatically and securely reports errors in .NET and COM applications. BugSentry provides a .NET dll (COM interop version available too) that developers ship with their products. Call the BugSentry.Sentry.Report() method to securely submit an issue. BugSentry will encrypt the issue with your public key, cache it locally, and try to send it to the BugSentry server. When received, BugSentry sends the developer and email. The developer can use a desktop client to download and decrypt issues. It is a fully hosted solution. No server necessary.
Bug Trail	Osmosys	Capture and track all your software bugs with Bug Trail. This easy to use tool allows you to attach screenshots, automatically capture system parameters and create well formatted MS-WORD and HTML output reports. Customizable defect status flow allows small to large organizations configure as per their existing structure.
BugZap	Cybernetic Intelligence GmbH	Bug tracking tool for small or medium-size projects, which is easy to install, small and requires no server-side installation.
Defect Agent	Inborne Software	Defect tracking, enhancement suggestion tracking, and development team workflow management software. Site license fee $399
Defect Manager	Tiera Software	Manages defects and enhancements through the complete entire life cycle of product development through field deployment
DevTrack Issue Tracking System	TechExcel	Issue tracking tool that includes configurable workflows, multi-issue/process tracking, customizable reporting, and email integrations and notifications.
Fast BugTrack	Alcea	Fast BugTrack is a market leader in bug tracking solutions. Completely Web-enabled, quick to install, and easy to use, Fast BugTrack offers you the ability to track bugs, coordinate projects, and effortlessly manage the change process within your organization.
GNATS	GNU	Freeware defect tracking software.
Intercept	Elsinore Technologies	Bug tracking system designed to integrate with Visual SourceSafe and the rest of your Microsoft development environment
IssueView	IssueView	SQL server based bug tracking with Outlook style user interface.
JIRA	Atlassian	Browser-based J2EE defect tracking and issue management software. Supports any platform that runs Java 1.3.x.
OnTime	Axosoft	Windows Bug Tracking and Issue Tracking software that integrates with Visual Studios. Some features include a customer portal, wiki, Planning board, iPhone App, custom work flows, and more. Project management software suitable for Agile and Scrum development.
QAW	B.I.C Quality	Developed to assist all quality assurance measurements within ICT-projects. The basic of QAW is a structured way of registration and tracking issues (defects).
QuickBugs	Excel Software	Tool for reporting, tracking and managing bugs, issues, changes and new features involved in product development. Key attributes include extreme ease-of-use and flexibility, a shared XML repository accessible to multiple users, multiple projects with assigned responsibilities, configurable access and privileges for users on each project. Virtually everything in QuickBugs is configurable to the organization and specific user needs including data collection fields, workflow, views, queries, reports, security and access control. Highly targeted email messages notify people when specific events require their attention.
Support Tracker	Acentre	Web enabled defect tracking application, one of the modules of the Tracker Suite software package. Support Tracker is based on Lotus Notes, allowing customers to leverage their existing Notes infrastructure for this bug tracking solution. Because Tracker Suite is server-based, Support Tracker installs with zero-impact on the desktop. User can create, track, and manage requests through Notes or over the Web. Requests are assigned, routed, and escalated automatically ts via Service Level Agreements, for proper prioritization and resource allocation. Support Tracker also features FAQ and Knowledgebase functionality.
SWBTracker	software with brains	Bug tracking system
TestTrack Pro	Seapine Software	Delivers time-saving features that keep everyone, involved with the project, informed and on schedule. TestTrack Pro is a scalable solution with Windows and Web clients and server support for Windows, Linux, Solaris, and Mac OS X, integration with MS Visual Studio (including .NET) and interfaces with most major source code managers including Surround SCM, and automated software testing tool, QA Wizard, along with other Seapine tools. Download a free Eval.
ZeroDefect	ProStyle	Issue management

http://aptest.com/bugtrack.html

Sample bug reports for web and product applications

On request from may readers I am updating sample bug report on separate page. Here are couple of sample bug reports and treat them as samples only. You can always make the changes in bug report format as per your requirements. It’s not mandatory to use same fields in same sequence as specified below. You can find out your own working template.
Read below articles on more guide on writing good bug report:

•  How to write a good bug report
•  Bug Life Cycle

Bug report sample 1: Web Project bug report
Summary: In CTR (Click through ratio) ‘Total’ row calculation is wrong
Product: Example product
Version: 1.0
Platform: PC
URL: (Provide url of page where bug occurs)
OS/Version: Windows 2000
Status: NEW
Severity: Major
Priority: P1
Component: Publisher stats
Assigned To: developer@example.com
Reported By: tester@example.com
CC: manager@example.com
Bug Description:
Reproduce steps:
1) Go to page: (Provide URL of page where bug occurs)
2) Click on ‘Publisher stats’ link to view publisher’s revenue detail stats date wise.
3) On page (Provide URL of page where bug occurs) check CTR value in ‘Total’ row of CTR stats table.
Actual result: Calculation of ‘Total’ row in CTR table is wrong. Also Individual row CTR for each publisher is not truncated to 2 digits after decimal point. It’s showing CTR like 0.042556767.
Expected result: Total CTR= (Total clicks/Total searches)*100
[Attach bug screenshot if any]
Please fix the bug.
************************************
Sample bug report 2: Application product Bug report sample
Application testing scenario:
Lets assume in your application you want to create a new user with his/her information, for that you need to logon into the application and navigate to USERS menu > New User, then enter all the details in the User form like, First Name, Last Name, Age, Address, Phone etc. Once you enter all these need to click on SAVE button in order to save the user and you can see a success message saying, “New User has been created successfully”.
Now you entered into your application by logging in and navigate to USERS menu > New user, entered all the information and clicked on SAVE button and now the application crashed and you can see one error page on the screen, now you would like to report this BUG.
Now here is how we can report bug for above scenario:
Bug Name: Application crash on clicking the SAVE button while creating a new user.
Bug ID: The BUG Tracking tool will automatically create it once you save this.
Area Path: USERS menu > New Users
Build Number:/Version Number 5.0.1
Severity: HIGH (High/Medium/Low)
Priority: HIGH (High/Medium/Low)

Assigned to: Developer-X
Created By: Your Name
Created On: Date
Reason: Defect
Status: New/Open/Active – Depends on the Tool you are using
Environment: Windows 2003/SQL Server 2005
Description:
Application crash on clicking the SAVE button while creating a new user, hence unable to create a new user in the application.
Steps To Reproduce:
1) Logon into the application
2) Navigate to the Users Menu > New User
3) Filled all the fields
4) Clicked on ‘Save’ button
5) Seen an error page “ORA1090 Exception: Insert values Error…”
6) See the attached logs for more information
7) And also see the attached screenshot of the error page.
Expected: On clicking SAVE button should be prompted to a success message “New User has been created successfully”.
Save the defect/bug in the BUG TRACKING TOOL.
//–>

http://www.softwaretestinghelp.com/sample-bug-reports-for-web-and-product-applications/

Mantenimiento correctivo y mantenimiento evolutivo

Una de las pesadillas de las empresas de desarrollo de software es la confusión (queriendo o sin querer) que existe en muchas casos entre los conceptos de mantenimiento correctivo y evolutivo. ¿Por qué pesadilla? Porque la garantía de los desarrollos afecta sólo a los mantenimientos correctivos y por tanto no se facturan y en muchas ocasiones se “cuelan” evolutivos como mantenimientos correctivos y se convierte en trabajo adicional para las empresas, no previsto y que en muchas ocasiones requiere un notable esfuerzo y que, por supuesto, no se cobra.
Un mantenimiento correctivo es aquel que tiene como objetivo solventar una deficiencia en un componente del sistema de información (puede ser software o documental). Entiéndase deficiencia como algo que debería funcionar o estar correcto y que no lo está.
Un mantenimiento evolutivo es aquel que pretende modificar algo que funcionaba o estaba correcto, con el objeto de aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario o por otras causas como pueden ser, por ejemplo, cambios normativos.
El problema está en la definición de qué es lo que debería funcionar o estar correcto en el sistema de información, es decir la delimitación clara de la frontera entre el correctivo y evolutivo. Y no es algo que esté nada claro en muchos casos, ya que por ejemplo, eso que esa funcionalidad que dice el cliente que debería estar y no contempla el programa, ¿es algo que se ha sacado ahora de la chistera o realmente se contempló en la definición y análisis del sistema de información?, ¿es algo que no se ha interpretado correctamente en el análisis?, ¿es algo que se suponía que se podía extrapolar del análisis aunque no aparezca explícitamente?.
Es cierto que hay muchos casos que las incidencias son de cajón y son correctivos y en la mayoría de las situaciones no dan problemas ni para el cliente, ni para el proveedor, que será consciente que son fallos suyos y los solucionará. También es cierto que hay evolutivos que son muy complicados de colar como correctivos, ya que una cosa es que la pared tenga que estar pintada de blanco o de color crema, que el pomo de la puerta sea plateado o dorado o que incluso el suelo sea de marmol o porcelánico y otra que te intenten comprar un piso de cuatro dormitorios por el precio de uno de un dormitorio. Sin embargo entre un caso (correctivos claros) y otros (evolutivos claros) hay todo un abanico de posibilidades que la mayoría de las veces dan lugar a conflicto (estos serán menos si el presupuesto del proyecto es holgado, el cliente es bueno, el proyecto se trata de una inversión para intentar conseguir más negocio con el cliente o a través del producto que se ha desarrollado, etc…).
Como ya he comentado en algún artículo en caso de conflicto casi siempre tiene las de perder el proveedor y lo más importante es tener asumida esa circunstancia. Eso no quiere decir que se deba decir a todo que sí, pero es más fácil negociar si no se pierde el tiempo en intentar remar a contracorriente.
Habrá negociación porque en los proyectos de desarrollo de software suelen cometer fallos las dos partes cliente y proveedor. Por esta razón siempre digo que las dos partes deben ser flexibles, ya que todos cometemos errores y además la naturaleza de los procesos de desarrollo de software no es rígida, sino en sí, un proceso evolutivo.

http://jummp.wordpress.com/2009/12/25/mantenimiento-correctivo-y-mantenimiento-evolutivo/

W3C ¿Es de utilidad para los Testers actualmente?

W3C

http://validator.w3.org/, es el link que nos lleva a este site y que propone las siguientes acciones:
1. Validate by URI
2. Validate by File Upload
3. Validade by Direct input

1. Validate by URI
Luego de ingresar una url, se debe pulsar el botón ‘Check’ para obtener el resultado del análisis. (existe la posibilidad de acceder a More Options)*

2. Validate by File Upload
Luego de seleccionar el archivo, se debe pulsar el botón ‘Check’ para obtener el resultado del análisis. (existe la posibilidad de acceder a More Options)*

(*) More Options
-Character Encoding
-Document Type
-List Messages Sequentially
-Group Error Messages by Type
-Show Source
-Clean up Markup with HTML-Tidy
-Show Outline
-Validate error pages
-Verbose Output

3. Validate by direct input
Luego de ingresar el Markup para validar, se debe pulsar el botón ‘Check’ (existe la posibilidad de acceder a More Options)**

(**) More Options
-Validate Full Document
-Validate HTML fragment
-Show Source
-Clean up Markup with HTML-Tidy
-Show Outline
-Validate error pages
-Verbose Output

Básicamente esta herramienta permite validar el lenguaje de marcas HTML.

La validación puede realizarse a partir de la URL de la página que deseamos validar (opción 1), o bien descargando el fichero a validar desde nuestro equipo (opción 1).

Tras la validación, la herramienta muestra un listado de las líneas del código HTML que no cumplen el estándar (siempre y cuando se haya seleccionado esta opción previamente desde ‘More options’), junto con una descripción del problema.

En algunos errores, además, añade una explicación de la posible causa, que puede ayudar a solucionar el error. (siempre y cuando se haya seleccionado esta opción previamente desde ‘More options’)

Entre las opciones avanzadas de validación existe la posibilidad de seleccionar el juego de caracteres y el tipo de documento utilizado en la página a validar (en caso de que no esté expresado en la primera línea de la misma).

El objetivo de usar esta herramienta -para el tester- es verificar y validar la calidad del código HTML.

Herramientas a nuestra disposición (algunas de ellas):

W3C (X)HTML Validation Service
W3C CSS Validation Service
W3C Link Checker
Links relacionados:

W3C
Wikipedia
Listado de herramientas para software testing
Testing Framework and Methodologies

http://testingbaires.com/debate-w3c-es-de-utilidad-para-los-testers-actualmente/

Spring cleaning your testware

In my family we have a tradition, every Spring we systematically go over all the house cleaning, organizing and mostly getting rid of all the things that we don’t need anymore.
We do this around the Jewish holiday of Passover, that is set to coincide every year with Spring in the Northern Hemisphere.
But from talking to friends who are not Jewish and don’t live in Israel I understood this is more than just a religious-driven tradition.  I even found an entry on Wikipedia about it under Spring Cleaning.

We are better at getting things than getting rid of them

A Universal truth about humans is that we are good at collecting stuff.
We have no problem buying a new t-shirt even if we already have 35 in our closet.  Or getting a stack of 50 blank DVDs to burn, even if we have not yet finished the stack of 15 DVDs we bought a year ago, just because there was a sale in our computer hardware store.
We like getting stuff, it’s in our nature…
On the other hand, we are really bad at getting rid of it.
When we realize the pants we took out of the closet are not our size anymore :-), or that the t-shirt you wanted to wear has been washed so many times it became see-through, we don’t immediately throw them away or given them out to charity.
We place them in our closet in the area of “things that I don’t think I’m gonna wear soon” and forget about them.  Until one day this area of things you are not gonna wear takes up half your shelves!
But don’t worry, you are not alone!  Most of us are just like you.
Nor does this only happen with our clothes/hardware/kitchenware/kids-toys/etc.  This happens with everything, including with our testware.

The art of collecting useless testware

The same thing I just described about t-shirt, DVDs and pants happens also in testware.
When you are looking for a test case to check a feature being updated in your application, you will look for a similar tests for approximately 45 seconds before deciding that you “might as well just write a new test for it”  (without realizing there are 2 tests that could have been slightly modified to cover this change).
Or, when part of your application is completely re-written and many of your tests become useless, you don’t delete them right away because you may “need to release a patch further along the road”.  But 2 years later, when there are no patches in sight and none will be created, you still keep these tests because “they are not harming anyone there”, and plainly you don’t have the time to review them and delete them right now…
If you look into your testware right now, and if you have not done any cleaning lately, it is reasonable to assume that between 10% to 15% of your tests are not relevant anymore, and another 15% to 20% of them need to be updated to match the current state and functionality of your AUT.

But this is not hurting anyone, right?
WRONG!

So you have a lot of useless tests, so what?!
It is not like you are paying more to electric company for them!  You are also not wasting any extra computers to store them!  And as they said countless times lately, storage space is so cheap nowadays that you should not even think about it anymore.
If so, what’s the big deal with having useless tests in my testing repository???
The big deal is that you are not looking at the problem from the correct angle.  The waste is not in computers, or electricity or storage…  these were the expensive resources 10 or 15 years ago.  Today the most expensive resources are the human resources – your team – and by having many useless tests in your repository you are wasting their time!
You are wasting the time it takes them to find the tests they need to run.  You are making it harder for them to understand if they need to create new tests or if they can re-use some the tests that are already in your Test Management System.
And maybe most importantly, by having a mix of good tests and bad tests in your repository you are increasing the chances of a tester that will run a wrong test and miss part of the issues that a good test would have detected quickly.

So what can you do about it?
3 steps to help you clean your testing repository quickly.

OK, so let’s assume you cannot drop what you are doing right now and take 3 days of all your team to go over your testing repository and clean it up.  There are still simple things you can do to start improving your process and make it easier for your team to clean up your tests in the future.

Step 1 – Organize your testing repository
The first step is the one that may provide the biggest immediate impact.
Most times the main problem with your tests is that your testers are not able to find them.
Once this starts happening then they either write duplicate tests (creating more useless stuff in your repository) or choose to run tests informally from their heads (maybe missing part of the things they should be checking).
To stop this from happening you need to organize your tests in a way that will help your testers find them easier and faster.
At the risk of being a little pretentious or immodest, we provide a pretty nice solution for this in PractiTest in the form of our Hierarchical Filter Trees, that let you organize and catalogue your tests in multiple ways at the same time (automatically organizing everything based on your tests’ fields).
One of the coolest things of this feature is that it allows you to “place” tests that check more than one area of your product under each of these areas (e.g. a test that checks your Website and your Reports Console and your User Management Module at the same time) instead of having to choose only one area (or folder) for each of your tests.  But enough of PractiTest for now…
If you are using any other test tool or even Excel to manage your testing you should try to create the most intuitive and simple classification in your test tree, use a convention that will let you manage test cases and the rest of your test ware.
When choosing a convention, the most intuitive one is usually based on your application’s structure.  Start from the products or components, and then go down 2 or 3 levels to Sub-Components, Features and even Screens.
Your convention also needs to take into account cases where one of your tests covers more than one product or components (like the case of end-to-end testing scenario we talked about previously).  You may choose to look for the “main component” for each test and set it under this categorization, and if this is not clear enough to have a number of “central components” where all the integration tests should reside in.
Conventions will never be perfect, and there will always be cases that fall out of it.  But it is better than every tester placing tests where he thinks they should be…

Step 2 – Mark your tests while you are running them
The second step aims at making it easier for you to do your Spring Cleaning once you have the time for it.
Add a new field or parameter to your tests that each of your testers can set when they are either running or reviewing their existing tests as part of their work, and ask them to them to set in this field one of the following 4 values:
Ready – if the test is OK and it can be run as is.
To Review – if you think something can be update in the test to make it better.  In this case you may also want to add a comment with why you set it to it.
To Repaire – when there is something that needs to be changed. In this case too, write down what you think should be fixed.
Obsolete – when the test should simply be discarded.
By having these fields you will be able to review them a lot easier.  You will also be able to see what tests are “abandoned”, by looking for tests that after a couple of cycles still have no value filled on this field.  Abandoned tests are usually useless and should also be discarded.

Step 3 – Set time aside in your schedule before your next “big project”
The last step is the trivial one.  You need to set time aside to clean your tests.
The best time (and often enough the only time) you will have is in the short span between projects.
If you plan this ahead and make sure that no one else has already assigned a task for you and your team, you may be able to review all your tests.  In case you are not able to go over all of them at least start from the most critical areas of your product.

Make it a habit for your testers to work correctly

Once you have a clean repository it will be easier for you as test lead or manager to ask your tester to work in a cleaner and more organized way.
Ask your testers not to write unneeded tests, and to always place tests in their correct are within the test tree.
No team will be perfect and with time your tests will again run into a small or larger level of chaos, but at least when you start from a clean page it takes it a little longer to reach this state.

http://qablog.practitest.com/2013/03/spring-cleaning-your-testware/