Performance Testing - High Priority

Of course depending on the kind of applications performance testing should be a high priority stuff but sometimes its an easy task, sometimes kind of difficult but another times mostly impossible. Why is that? Because of the way that the application was developed increases the level of risks of good performance tests. If the application was developed under OOP guidelines then it will be easier but here it might appears another problem.... there is no politics or regulations about how to apply OOP which also increases the risks of testing.

Again, as I have suggested already its a good approach to create the test cases looking at the code in order to avoid risks, and of course has a better impact with testing.

Going back to performance test, as it can be done by reusing the unit-test scripts why don't developers do that? or execute them as part of the unitesting. It should be good that testing receives the results of Unit-testing and performance testing executed by the owner of the development. This approach will help us all to get a better idea about limitations and individual performance.

Because of the evolution of the systems and because they gets integrated with more and more applications performance test should be executed either by Developers or Testers but done....

Read More

White Box Techniques...

Even when Black box testing techniques are cheaper and easier to perform than White-Box; white-box should be a priority while we are trying to roll out. We all know about time pressure, about testers availability and testers skills but this technique can save us from big headaches:

* It's great to validate the documentation, in some cases to create it. I've been dealing with some companies that prefer developing than documenting. If you check the structure of the application you have to able to complete all models.

* It's great to create functional tests cases from the code. It might have more impact and find more bugs. It might check some code impossible to reach with 100% functional test.

All companies thinks, when you mention White Box testing that they need a NASA engineer, it's true that not all testers know how to do this but is not more expensive that leaving bugs into the code.

Read More

Cosmetic Bugs

If cosmetic bugs are very low priority should we leave them and get focused on high priority tests or try to find them asap as they generates the first impact on customers?

Thats a stupid question but most of testers spend lot of time trying to find cosmetic bugs when they should try to find real bugs (I mean with Functional Impact)

Read More

No Testing Consequences

Ultimamente he tenido contacto con empresas que sufren las consecuencias de no testear o de no hacerlo adecuadamente. Lo cual causa terribles perdidas a nivel tecnologico y negocios.
A nivel tecnologico muchos desarrollos y hardware involucrado quedan obsoletos luego de una cancelacion de proyecto por errores no identificados a tiempo.
A nivel negocios las perdidas son importantes, cubrir costos generados de cualquier tipo puede ser una pesadilla. Resignar ganancia no es un problema, el real problema es la consecuencia: Mala imagen en el mercado.
Como concientizar a las empresas, que conocen las consecuencias, de que el testing no genera ganancia inmediata pero si a largo plazo. Cuando ocurrira esta apertura de mente para ganar nuevos mercados?


Lately, I've been in contact with companies suffering consequences about NO-Testing or wrong testing. It generates both technical and financial losses.
Talking about Tech level lot of developments and hardware stuffs got obsolete after a cancellation as a result of undiscovered bugs.
Due Business, it might become a nightmare to think about all costs generated. Isn't a big deal to resign revenue but the big problem would be your negative image now on into the market.
If all companies already know their consequences of no-testing it has no point to even try to offer this service to them . Testing needs a new mindset, a different one. It doesn't generates an immediate revenue but it will do it in long-term.
When people will try to get new markets and better business image?

I've added new links that I recommend to take a look like Morpheus Systems from London that belong to Matt Hobbs.

Read More

Cual es el orden sugerido de ejecucion de tests? Which is the Testing order?

Por lo general pensamos que ejecutar pruebas es todo el testing cuando en realidad eso solo representa el 40% del testing. Porque se da tanta importancia a una sola actividad cuando los errores se pueden encontrar antes y con menor costo. Yo creo que es una cuestion de cultura el no ver mas alla de lo que creemos importante.

Testing no es solamente ejercitar el software para detectar defectos o fallas, Testing se aplica a cada una de las etapas conocidas del desarrollo de Software. Cada etapa, documento involucrado, porcion de software, planeamiento es testeable y debe ser testeado antes de ejecutar los System Tests.

Ademas involucrar los testers en etapas tempranas del desarrollo trae muchos beneficios, como ahorro del tiempo de ejecucion de tests, familiarizacion con el futuro sistema.

El ciclo elemental de Testing cuenta con las siguientes etapas:

• > Planeamiento y Control
• > Analisis y Disenio.
• > Ejecucion e implementacion
• > Evaluacion y reportes
• > Actividades de cierre

Cada una de estas actividades internas al area de testing estan relacionadas con las etapas del desarrollo del software para "testearlas" y encontrar fallas antes de tener el codigo listo.

Solo dento de la etapa de ejecucion se realizan los test de:

• * Component Testing (Mas conocidos como UniTests)
• * Integration Testing (Mediante distintas metodologias, Bigban, Funcional, etc...)
• * System Testing (Functional y No Funciona)
• * User Acceptance Testing

-----------------------------------------------------------------------------------------------

It's very common to find people thinking that executing test cases is Testing but that only represents 40% of testing. Why we focus in only one task? Is it a cultura thing? Why dont we watch beyond the horizon?

Testing applies to every known stage of Development Software Process. Each stage, document, software, plan is testeable and must be tested before we perform system tests.

Besides, getting testers involved in early stages give us many benefits like saving time, identify potential bugs, etc...

The elemental Test cycle has the following Stages

• > Planning and Control
  
• > Analysis and Design
  
• > Execution and implementation
  
• > Evaluation and reports
  
• > Closure Activities
  

Each of these stages are related with those stages at development process level to be tested and find bugs.

Just at the execution stage we perform:

• * Component Testing (Mas conocidos como UniTests)
• * Integration Testing (Mediante distintas metodologias, Bigban, Funcional, etc...)
• * System Testing (Functional y No Funciona)
• * User Acceptance Testing

Read More

Conocimientos basicos de los testers

Conocimientos Básicos de los Testers:

• •Normas de Calidad
• •Lenguajes de Desarrollo
• •Lógica
• •Base de Datos
• •Seguridad Informática
• •Sistemas operativos. Principalmente Unix/Windows
• •Aplicaciones Web.
• •Programación Orientada a Objetos
• •Hardware
• •Management
• •Recruitment

Como ayudan las empresas a desarrollar estos conocimientos? O no ayudan?

Read More

Frases Celebres Testers vs Devs (Negociacion) - Famous phrases Testers vs Devs (Negotiation)

Al comienzo de mi carrera pensé que solo en Argentina los desarrolladores usaban estas frases para excusar bugs o justificar algo pero con el paso de los años note que es una característica común en ellos. Mi frase preferida es

En Desarrollo (en el ambiente) funciona perfectamente!.

Quien no la habra escuchado. Como si eso hiciese desaparecer magicamente el bug o como si fuese un justificativo valido. Quizás sea gracioso leerlo así pero genera un gran desafío para el Tester hacer entender al Desarrollador que realmente es un bug o que el hecho que funcione en su PC no es ningún justificativo sin entrar en discusiones. Sabiendo que muchos profesionales que desarrollan se siente observados por el area de testing o como si estuviesen bajo una continua evaluacion los testers deben ser habiles mediadores no generadores de conflictos. En empresas donde no hay un procedimiento claro sobre casos de usos o donde se deja la posibilidad a que el Desarrollador use su imaginacion, cuando el sistema se encuentra en Test se escuchan frases como:

* Esa funcionalidad nunca se especifico.
* No lo realice como el cliente lo solicito porque encontre una mejor manera de hacerlo.(Muy pocas veces es asi)
* Nadie se va a equivocar cargando informacion, etc.

Voy a postear mas frases celebres en breves, lo importante de todo esto es nunca discutir sino negociar y hacer entender los errores reales a los desarrolladores. Trabajar para que no se sientan perseguidos o bajo constante evaluacion.




At the very beggining of my professional career I though that only Argentinean Developers excuses their errors but after few years I've noticed that its a common characteristic. My favourite phrase is:

It works in Dev (Environment)!.

A magical phrase to disappear the bug or to justify a mistake. It might sounds funny but its a big challenge for testers to deal with the developer and make him understand without argueing.
Keeping in mind that many developers feels they are under an on-going evaluation by the Test Area; Testers have to become skilled mediators.
In companies where there are unclear processes about how to create Use Cases or the developer has the chance of using his imagination, while the system is being tested you can hear phrases like:

* This functionality wasn't specified.
* I didn't do it as expected because I found a better way to do it.(Mostly wrong)
* Nobody will make a mistake loading information, etc.

I'm going to post more phrases but the most important thing here is never argue but negotiate and make developers understand bugs. Also, work to make them feel that they are not under evaluation.

Read More

Nacimiento del Blog - First comment

Hoy nace el Blog sobre Calidad de Software. No con la finalidad de presentar informacion academica sino de publicar experiencias personales en este campo y buenas practicas.
Si bien en este momento estoy radicado en Argentina tengo clientes de otros paises ademas de dictar la unica Diplomatura de Testing de Software en el pais.
Espero que sea de utilidad.

Saludos


Today it's launched this blog about Software QA. I don't want to publish Academic information but personal experiences in this field and good practices.
I'm based in Argentina but I've customers from another countries and currently teaching a Diploma in Software Testing.
Hopes this helps you.

Best Regards

Read More