Are we Testers or QA Engineers?

This is one of the most charged discussions I’ve been in, and what makes it more annoying is the fact that it usually takes a political taste in many Organizations. In any case, I think I managed to understand the confusion and find my answer…
I was at SIGiST meeting this week in Tel Aviv, and among other things there was a presentation by a QA Manager from SAP who showed the Automation Harness they had developed in his team. Just a few words about the platform, it is pretty amazing (and this from the perspective of having managed the QA for QTP and QC in the past, and from working on PractiTest now).
In any case, in his introductory slide he said that he sees himself as a Test Manager and not a QA Manager, but that this was his formal title in SAP.
At the beginning it got me all fired up inside, since I do believe that in all the Organizations I worked so far I functioned as a QA Manager, and here was yet another person who limited our task and responsibility only to test execution.
Then as his presentation continued, I understood that he was right.
HE really is a Test Manager, and his responsibility is to create and facilitate the tests that other people use and run in order to test their software. He does not perform the extra task of running the tests as part of a strategically designed project that provides visibility into the status of the AUT and its development process.
Eureka!
Apparently there are Test Managers, I am simply not one of them since I am also in charge of the QA.
For me testing is only a tool. I use it in order to fulfill my objective of providing visibility. This does not mean that I am solely in charge of the Quality of the Product, this is a task & responsibility shared by all the people involved in the development process; I am the Stakeholder in charge of understanding and communicating the Quality Level achieved by the AUT to my peers.
So here is the end of a very long question for me.

http://qablog.practitest.com/2009/02/are-we-testers-or-qa-engineers/

Hiring Great Testers - Tester Roles

In my mind, there are basically three roles on a test team.  These three roles are: developers, scripters, and those who execute the test cases (runtime testers).  In reality there is a spectrum of capabilities on any team but I think most roles will be closely related to one of these three roles.
Test Developers are the heart of a modern test team.  There was a day when you could get away with hiring a few people to just use the product and call that a test team.  This is no longer the case.  Products are becoming more complex.  The lifespan of products is increasing.  More products are being created for developers instead of end users.  These have no UI to interact with so simple exploratory testing is insufficient.  To test complex products, especially over an extended lifespan, the only viable solution is test automation.  When the product is an API instead of a user interface, testing it requires programming. 
Test developers are programmers who happen to work on a test team.  It is their job to write software which executes other software and verifies the results.  The test developers need to be at least as skilled as the developers of the product.  They need to know whatever language their product is written in.  Their job is often as difficult or perhaps even more difficult than writing the product.  Sometimes the job can be done in a simple fashion where each function is just called with various parameters and a simple method of pass/fail is monitored.  This could be a success result or some notification from the program.  A better test developer will not rely on a program to tell him if the right things happened.  Instead, he will monitor the actual behavior.  For a simple function this might just be the return result but more often than not, it requires monitoring the output of the program and making a complex decision based on it.  Test developers are also responsible for creating the test harnesses and systems for their teams.
Scripters are those who have some programming ability but are not as skilled as a test developer.  They will usually know a programming language but on that is less complex than the language the product is written in.  Scripters may know Visual Basic, Perl, Javascript, or even C#.  More important than which language they know, what distinguishes them from a test developer is that their understanding of programming is less advanced.  They will understand the language syntax but their understanding of algorithms and data structures is likely less substantial. 
Scripters will often play a role where they spend a lot of time living the product.  They will use their programming skills to script the product (if it has such a feature) or to utilize tools to drive the product.  The tools could be UI toolkits like Visual Test or something written by test developers.  Because scripters have an understanding of programming they will be able to have a deep understanding of the product.  They will be able to quickly determine the root cause of a failure and see relationships between seemingly unrelated bugs.  Scripters play an important role on any team.  They often handle the bulk of the test triage efforts and closely monitor the needs of the users of the product.
In some teams the responsibility for setting up machines, installing builds, and executing test cases falls to a group I'll call Runtime Testers.  This role involves no programming.  Runtime testers usually don't have any significant programming knowledge and if they do, they don't often get a chance to utilize it.  They play a fundamental role, however.  Because they are the ones running all of the tests, they often have the best knowledge of the state of the product.  If you want to know what really does and does not work, ask one an execution specialist. 
Sometimes this role is relegated to merely clicking buttons.  They run an automated test and log some errors.  This is a waste.  They should be tasked with understanding the product and playing with it.  As I've stated many times in the past, there is a critical need for manual testing on most project.  These are the people best equipped to do that.  To get maximum value out of runtime testers, they should be encouraged to live the product.  To become experts in the functionality the way a customer might use it.  In doing so they can become advocates for the customer and find the usability issues and corner cases that automation cannnot easily find.
Each of these three roles is critical on a test team.  If you build a team with only one or two of the roles, you'll be missing something fundamental.  Each project will require a different mix of people.  Some need more test developers, others more runtime testers.  The importance of these roles comes into play not only when you task your team but also when you hire.  If someone is to be a runtime tester, hiring a CS grad may not be the best idea.  They will likely be bored and quickly move on.  Hiring a self-educated computer geek may be a better fit for the role.  Likewise, if you need test developers, hiring someone who only knows perl is probably not a good fit.  Instead, hire someone who is truly a developer.  My rule of thumb is that if they couldn't cut it as a dev, don't hire them as a test dev.

http://blogs.msdn.com/b/steverowe/archive/2007/01/16/hiring-great-testers-tester-roles.aspx

Back to Basics, write down your objective before you start testing

It happens to me all the time that I start testing and as I move along my steps (or my application if I am working on an exploratory task) the thoughts in my head and bugs that I find take me along paths and routes I didn’t plan ahead.
This is not an issue by itself, but the problem is that sometimes I finish my run and then I realize that I completely missed the objectives that prompted me to start testing in the first place…
This is why I started doing a simple exercise each time I start a test: write down my testing objectives on a piece of paper.  I then place this piece of paper next to my keyboard and start my test.
As I find or think of additional things that should be tested or reviewed I make an additional note on the piece or paper and continue; sometimes I start immediately with these new cases, other times I continue with my previous ones, but now I am sure I won’t forget them.
As I cover the things in my dynamic-yet-static list I mark them down and move on.
Since the piece of paper is right in front of my eyes, it is not something that I need to constantly open or refresh, its simply there.  And I always know what I need to cover in my tests before I can call my test complete and done.
Sometimes the beauty in life comes from the simple things…

http://qablog.practitest.com/2009/04/back-to-basics-right-down-your-objective-before-you-start-testing/

Recommended Reading for New Test Developers

I've previously written about how to teach yourself to be a test developer.  That post included an extensive reading list.  It assumed that you were a tester and wanted to learn to be a test dev.  What if you are a new CS grad and you just got hired as a test developer?  What should you read to get a leg up on the competition?  What follows is my list of recommendations.  Some of this list assumes you'll be working in C++.  If you are going to be working in C# or Java or some other language, you'll have to make substitutions.
Testing Skills:
I'm not a big advocate of formalized testing skills.  There are those who think there is as much to learn about testing as there is about design and development.  I don't happen to subscribe to that philosophy.  Testing isn't trivial, but I'm not convinced it is rocket science either.
My only recommendation in this area is James Whittaker's How To Break Software.  This book is very practical.  Not a lot of theory but it will give you a good, working knowledge of how to test software.
Programming Skills:
With a CS degree you should have learned the basics of programming.  I liken this to learning a written language.  You know what sentences, verbs, and nouns are.  This makes you capable of writing but doesn't make you a good writer.  School projects tend to be small and throw-away.  You don't often have to deal with large code bases and the quality of the code itself is often not related to the grade achieved.
The Practice of Programming by Kernighan and Pike.  This gives you a lot of tips on how to write good software.  Short and meaty.  A great book.
Refactoring by Martin Fowler.  This book consists of two parts.  The first part explains the concept of refactoring.  How and when to make pre-existing software better.  The second part is a lexicon of refactoring patterns.  These are recommendations to handle specific situations in code.  The latter half of the book I find less useful.  Feel free to skip it.  However, the first half is extremely useful.  Make sure to read this.
Design Patterns by Gamma et al.  Also known as the "Gang of Four" book.  The most enlightening part of the book is the first few chapters.  It shows how to design an editor using an object-oriented approach.  I personally found this to be an "a-ha" moment.  If you didn't cover design patterns in school, read this book.
Design Patterns Explained by Alan Shalloway.  Great explanation of practical use of design patterns.  Read this before you start designing programs.  You'll find yourself writing better code and you'll find maintenance a whole lot easier.
Advanced C++ Skills:
These books will help you go beyond the basics.  Going back to my written language example, consider this to be like gaining a strong vocabulary.  You can communicate your ideas with just basic vocab words but to communicate the nuance, you need a deeper understanding of the language.
Effective C++ by Scott Meyers.  If you feel comfortable with C++, this is a great next book.  It will help you to avoid many of the gotchas in C++.  This book will help you be a better programmer at the syntax level and have a much deeper understanding of the language as a whole.  Skip the More Effective C++ book though.  It's not a bad book but there are better uses for your time.
Inside the C++ Object Model by Stanley Lippman.  Deep explanation of how C++ works under the covers.  If you want to be a coding guru, give this book some of your time.

http://blogs.msdn.com/b/steverowe/archive/2007/01/24/recommended-reading-for-new-test-developers.aspx

Ejercicios Diagrama de flujo - parte 4

Ejercicios de diagrama de flujo varios.
Los demás ejercicios Parte 1   Parte 2   Parte 3   Parte 4   Parte 5   Parte 6   Ejemplo 1   Ejemplo 2   Ejemplo 3   Ejemplo 4   Ejemplo 5

Indique si una persona puede participar o no en las elecciones del 2018. Link

 

Dada una cantidad en pesos mexicanos, obtener la equivalencia en dólares estadounidenses, asumiendo que la unidad a cambiar es un dato desconocido. Link

  

 

 

Calcular el numero de pulsaciones que una persona debe tener por cada diez segundos de ejercicio si la formula es (220-edad)/10= N de pulsaciones. Link

 

 

 

 

Evalua el área que deja un círculo al estar dentro de un cuadrado. Link

 

Diagrama de flujo que realiza el efecto de marquesina (marquee en HTML). Link

 

Diagrama de flujo que realiza el desplazamiento de una palabra de 7 carácteres de un extremo de la pantalla, a otro extremo, utilizando coordenadas. Link

 

Fuente: http://mis-algoritmos.com/ejemplos/diagramas-flujo.html

 

Why Writing Software Is Hard

Scott Rosenberg just published a new book called Dreaming in Code about a project to create a new personal information manager called Chandler.  As many software projects, this one is late.  Rosenberg was recently interviewed about the subject of software projects falling behind. He has some interesting thoughts on the issue. 
Are projects like Vista just poorly run projects?  Were they late because they were undisciplined?  Or was there something else at work?  Rosenberg doesn't give a clear answer but he does seem to indicate that it's impossible to estimate software times because it has never been done before.  He says,
"[A]s long as you are not trying to do something new -- if you are doing something that has already been done -- then you have a frame of reference to estimate how long it is going to take, and to guess how many people are going to be required, and so on. And of course in other fields of engineering where we do the same thing over and over, the same is true. If we are going to build a house, there are always imponderables, and every site is different, but you have a rough idea: two-story house, and such and such a set of features, it is going to take a certain amount of time."
This is true.  If you've done it before, you can probably estimate it.  However, if you haven't done it before--and with software you probably wouldn't be writing it if you had--there is really no way to accurately know how long it will take.  I think this is largely true, as I have argued elsewhere.  Software is unforgiving (the reason for most security holes).  Writing a program is more like research than simple engineering.  No one blames Monsanto for being late developing a cure for cancer (that I know of anyway) but Microsoft gets killed for being late with Vista.  Part of that we, as programmers, bring on ourselves.  To be a good programmer means you are smart.  Mere mortals often have a difficult time understanding how to write even simple programs.  Because of that, we often times overestimate our abilities and underestimate the size of the problem.  We don't have the information to make an accurate calculation but we refuse to admit that. Instead, we insist that everyone else trying to write software was just undisciplined and that we can do it better.  Unfortunately, we can't.
My takeaway from all this:  don't try to estimate the whole project up front.  Stay agile.  Come up with a list of work and churn through it at whatever rate is possible.  Have lots of checkpoints and don't be afraid to change your plans.

http://blogs.msdn.com/b/steverowe/archive/2007/02/03/why-writing-software-is-hard.aspx

7 habits of highly effective testers

I’m currently reading a book by Stephen R. Covey called “The seven habits of highly effective people”, highly recommended if you need to understand how to balance and focus your life and your work.
The book got me thinking about the fact that looking back over my career I have also noticed some habits that seem to be present in many of what I would call the most effective testers I’ve worked with.
The list does not follow any specific order…
1. Context awareness: always understand the higher objective of what you are doing
An effective tester always knows how the task she is doing helps to answer an important and relevant question for the project.
Instead of blindly running tests these testers understand the current context of the project, what areas are important and how to contribute as part of the team. They clearly understand their role within the project and look for ways to play it in the best possible way, based on the current and ever-changing state of affairs.
2. Self awareness: realize your personal advantages and limitations
A good tester knows what he’s good at and in what areas he needs help. This doesn’t mean that he will run away from a task if he has a limitation with it, but he will accept and even look for help without feeling he is being undermined or professionally hurt.
Whenever possible he will try to look for tasks in the areas where his marginal contribution is higher.
3. Hands on attitude: a need to stay connected with the concrete tasks taking place
This is more relevant for managers and team leaders, but an important habit of a good test manager is not to get disconnected from the tasks taking place in his team. Even if this means sacrificing (or better yet, delegating!) some managerial tasks in favor of some manual testing work “in the trenches”.
Not only does this help improve the moral of the team, but it gives real visibility and understanding of the application under test and the real issues affecting the project.
4. Value of communication: explain simply and correctly
An indispensable trait of an effective testers is to be understood.
Not only does she test the correct things right, but she is able to explain to everyone in the team (technical or not!) what she found and how does it affect the overall project.
5. Teamwork: collaborate to achieve synergies
There are obviously tasks that are better done alone, but whenever necessary good testers know how to reach for help or even lend a hand.
Effective testers are usually liked and respected by the whole team, and they understand that teamwork and collaboration are a key to doing things more effectively, faster and better.
6. On-Going Improvement: self & external criticism to keep-on growing
The realization that we can always make things better is a distinctive trait in many of the testers I classify as great. These people are always open to criticism and understand that (in most cases) the feedback comes from a friend who wants to help them improve.
Most importantly, these people are not only open to external criticism, but they develop tools and techniques that allow them to evaluate their own work and look for ways to improve it.
7. Urge to learn: thirst for the expansion of knowledge
Maybe linked to the on-going improvement habit is the one to keep learning and looking for new knowledge sources.
Effective testers will be the ones bringing up new technologies, tools and techniques to do things better; they will try them out, and adopt or discard them based on the results they got. They will surf the Internet, participate in all sorts of forums and communities, and read books looking for new knowledge sources that will benefit them and the team.


The fact that I came up with 7 habits is pure chance and I will be happy if other people can keep adding to this list and take it to 8, 9 or even 20 habits we should all have to be effective testers!

http://qablog.practitest.com/2009/09/the-7-habits-of-highly-effective-testers/

What Is Your Greatest Weakness?

If you've interviewed much, you've probably been asked this question.  Art Vandalay examines some of the potential answers and their outcome on his blog.  There's also an interesting conversation in the comments over there.  The consensus of those being interviewed seems to be that it is a no-win question.  The managers seem to find it useful.  Which is it? 
I've spoken to people who use this question and asked them what they get out of it.  Their answer is usually "You'd be amazed what some people will say."  True, but if they're really that badly behaved and that intelligent, couldn't you find out some other way?  If you ask a question only to weed out the most incompetent, perhaps there are better uses for that time in the interview.
I see little value in this question.  As Art points out, there are four possible answers:

1. Lie/Evade - Claim you have no weaknesses or attempt to change the subject.
2. Answer with a weakness that is really a strength - Say something like "I am a perfectionist"
3. Honesty - Answer with your truly biggest weakness.
4. Wiggle out - Give a true weakness but only a very mild one.

Given these 4 choices, the best possible answer is #4.  The first will often upset an interviewer looking for "honesty".  Unfortunately, this question is designed to get you to be dishonest so the interviewer should avoid the question.  The second is lame and probably runs into the same problems as #1.  The third will probably end the interview.  Everyone has weaknesses and without context, your biggest weakness will often dominate the mind of the interviewer.  Game over.  The fourth has some honesty to it but isn't enough to get you thrown out of the interview room. 
As an interviewer, I don't want to put my future employees in a position where they are struggling to find the answer I want to hear rather than the truth.  Why should I put them in a position where lying by avoidance is the best answer?

http://blogs.msdn.com/b/steverowe/archive/2007/02/08/what-is-your-great-weakness.aspx

¿Como escribir un buen reporte de Fallas/Bugs?

El punto de escribir un reporte de bug es que el bug sea corregido.

By Cem Kaner.

¿Por que es necesario escribir un buen reporte de bugs?
Si el bug/falla se reporta eficientemente las probabilidades de que sea solucionado rápidamente serán mayores. Entonces la solución de una falla dependerá de la eficiencia con que se reporte la misma.
Si vamos a un ejemplo, comúnmente vemos que si una falla no se reporta bien, el desarrollador va a devolver la misma como no reproducible (ya que la información provista no le permite generar la falla en sus ambientes). Esto puede generar que se aumente la carga de trabajo para el tester (el bug vuelve a sus manos y tiene que revisar si la falla que pasó ocurre realmente) y que el tester sienta herido su orgullo ya que según el desarrollador, el tester pasó una falla que no es tal. Esto puede llegar a generar un mal ambiente de trabajo y se puede perder el objetivo de las tareas de cada uno, que es indicar la falla por un lado y solucionarla por el otro (para poder entregar a tiempo y con calidad), volviéndose un tema de idas y vueltas (y de búsqueda de culpables) que se podría haber evitado con un correcto reporte del bug.
¿Cuales son los problemas más comunes con los reportes de fallas?
Creo que determinados problemas se dan se dan más allá del rol de la persona que reporta la falla y otros problemas se dan más que nada por cuestiones de roles, por experiencia o directamente por que la empresa en la que se desarrolla la actividad no tiene bien definido el proceso.
Los problemas más frecuentes suelen ser:

• Redactar la falla de manera excesivamente coloquial y ambigua (esto puede ser grave más que nada cuando el que reporta es un tester, no tanto en el caso de un usuario final al que hay que interrogar un poco más)
• Dar solo una captura de la falla sin indicar que se estaba haciendo cuando sucedió el bug (suele suceder cuando reportan fallas los analistas o los usuarios finales).
• No incluir en la descripción de la falla cual era el resultado esperado para los pasos realizados.
• No determinar un patrón con el cual el incidente ocurre antes de reportar el mismo. Esto me parece muy importante para ser directos en cual es el problema y para que desarrollo lo pueda reproducir.
• No leer el incidente reportado siguiendo los pasos uno mismo para ver que la descripción es clara para el que lo lee.
• No incluir información que dada las características del bug, la misma es de relevancia. Por ejemplo indicar solo que se ingresaron datos inválidos, pero no incluir cual fue el dato en cuestión.

¿Cuales son las causas más comunes por lo que se da esto?
Por lo que pude recabar en la consulta realizada en el grupo de Testing en Linked In, las causas más importantes que provocan estos problemas son:

1. Falta capacitación.
2. Falta de tiempo (a menor capacitación mucha mayor necesidad de tiempo para determinar y definir el problema)
3. Falta de reglas claras dentro de la organización/proyecto.
4. Falta de generarse una rutina propia que se adapte a nuestras skills y nos genere una disciplina que nos sea cómoda y útil para los demás que leen la falla.

¿Cuales son los lineamientos básicos a seguir para reportar un bug eficientemente?
Los puntos básicos que tiene que tener un bug son:

• Reporter: Tester que lo reportó. Esto facilitará la comunicación entre el que lo reportó y el que lo va a solucionar.
• Versión: Indica la versión de la aplicación en que se detectó la falla.
• Ambiente: Indica sobre que ambiente de pruebas ocurrió la falla.
• Componente: Indica sobre que componente/módulo/submódulo/pantalla se detectó la falla.
• Plataforma y Sistema Operativo: Indica sobre las características de hard y sistema operativo de la maquina en donde se detectó la falla.
• Navegador: Indica el navegador que se estaba utilizando cuando se detectó la falla.
• Prioridad: Se indica “cuando” debe arreglarse la falla. Este parámetro nos ayuda a indicarle al desarrollador con que urgencia necesitamos la corrección del bug.
• Severidad: Indica el impacto de la falla sobre la aplicación.
• Resumen: Descripción corta que describe la falla en forma simple y concreta.
• Descripción: Detalle de los pasos realizados para poder reproducir la falla, junto con los datos utilizados y la generación del escenario para que ocurra el bug.
• Falla: Descripción que indica cual es el error exactamente.
• Esperado: Descripción de que debería ocurrir en lugar de la falla.
• Adjuntos: Cualquier material complementario que sirva para ayudar al desarrollador a solucionar la falla (screenshots, logs, documentos, etc…)
• Estado: En que situación se encuentra la falla para indicar si ya puede ser tomada por el desarrollador, si ya fue solucionada o si todavía no puede revisarla.

¿Que consideraciones debo tener al momento de reportar el bug/falla?
Al momento de reportar un bug/falla debemos tener en cuenta las siguientes consideraciones:

• Los bugs deben tener identificadores únicos
  Si bien muchas herramientas de bugtracking asignan automáticamente un ID único a los bugs, muchas veces se reportan fallas por medio de mails, saltando la registración en la herramienta y dejando el bug perdido en el limbo hacia donde será muy difícil hacer referencia o realizar un seguimiento. Entonces, siempre hay que registrar los bugs con un ID único (ya sea mediante una herramienta para bugtracking o solo una planilla en txt o excel)
• Una falla debe ser reproducible para reportarla
  Si el bug no es reproducible, no es un bug. Para fallas que ocurren en forma aislada, podemos realizarnos una nota personal para investigar luego y determinar que condiciones deben ser dadas para que el mismo se produzca, pero reportar una falla que nosotros mismos no podemos reproducir no es muy productivo ya que solo cargaremos la herramienta de bugs con fallas que serán devueltas como no reproducibles, ese será su único destino, generando una perdida de tiempo por parte del tester en reportarlo y por parte del desarrollador en revisarlo y probar variantes para reproducirlo.
• Debe reportarse cada paso realizado para reproducirlo
  Toda la información que podamos darle al desarrollador para que pueda reproducir la falla siempre será bienvenida, no debemos obviar ningún paso que sea relevante para llegar al error en cuestión. Una buena practica es reproducir el error una o más veces siguiendo solo los pasos que escribimos, como si no lo conociéramos, esto nos ayudara a detectar información de más (o faltante) y si la falla es reproducible con la información que se detalla.
• Ser especifico
  No se debe escribir suposiciones o ideas sobre lo que esta ocurriendo u otra cosa que no sea la información relevante para poder reproducir el bug.
• Describir el bug de forma simple y corta en el resumen del mismo
  Es importante que el desarrollador puede hacerse una idea del bug con solo leer el summary/resumen del mismo, para que al entrar a leer la descripción del mismo ya tenga una idea de hacia adonde apunta el camino.
• Investigar el patrón con el que ocurre el bug
  Hay que tener en cuenta que los bugs siguen siempre un determinado patrón para ocurrir, ya que los mismos son fallas en el código. Debemos esforzarnos para encontrar el patrón que hace que se pase siempre por la sección de código donde esta la falla.

http://josepablosarco.wordpress.com/2010/12/09/%C2%BFcomo-escribir-un-buen-reporte-de-fallasbugs/

Beware of Single Focus Roles

I recently attended a talk advocating combining the management of test development and development.  Some of the reasoning for this was to force the quality decisions to fall onto one person.  This makes a lot of sense.  It is important to understand why.  Many times in large software development projects we compartmentalize the various roles.  This is true not just of test and development but also roles like performance, security, customer service, etc.  This compartmentalization has a direct effect on how people operate.  When someone is responsible for only one aspect of a product, they will often make the right choices for their aspect but the wrong ones for the product overall.
In the traditional software model, test and development are two distinct silos.  The disciplines report to different people and perform different jobs.  This creates tension between the roles.  This tension arises not just because of the variance of roles but also because of the variance of purpose.  Development wants to add features and test wants to constrain them.  To ship a quality product, you need to strike a balance.  Too many features and the quality will be too low.  People won't tolerate it.  Too much quality and there won't be enough features to attract customers.  Imagine a field.  One one side is quality and the other features.  Now imagine a line drawn between them.  To increase quality, you must decrease features.  Each decision is a tradeoff.
Security is also an area that is fraught with tradeoffs.  The Windows of old shows what can happen if not enough attention is paid to security.  Trusted Solaris shows what happens if you pay too much.  Not enough attention and the system becomes a haven for viruses, bots, etc.  Too much and the system is years behind, runs slow, and is very hard to use. 
Performance can be similar.  Many changes that increase performance are intrusive.  Making them involves trading stability for performance.  Other times the performance wins are not visible to the end user.  Are they still worth making?  Finally, if you are not allowed to degrade performance, it is very hard to add new features.  Assuming your previous implementation was not poorly designed, it can be nigh unto impossible to add functionality without increasing CPU usage.
In each of these cases--and many others--a person or team tasked with improving only one side of the coin will make decisions that are bad for the product.  Recall that good engineering is about making the right tradeoffs.  To make them, one must consider both what is to be gained and what is to be lost.  When we give someone a role of focusing solely on security or performance or adding features, we skew their decisions.  We implicitly make one side of the coin trump the other.  If a person's review is based only on the performance improvements they made in the product, that person will be disinclined to care about how important the new functionality is.  If they are tasked solely with securing a product, they will tend not to consider the functionality they break when plugging a potential hole.
The right decisions can only be made at the place where a person is accountable for both sides of the tradeoff.  If the different silos (test, dev, security , performance) are too far separated, this place becomes upper management.  This is dangerous because upper management often does not have the time to become involved nor do they have the understanding to make the right decision.  Instead, it is better to drive that responsibility lower in the chain.  Having engineering leads (not dev leads and test leads) as the talk advocated is one way to accomplish this.  One person is responsible for the location of the quality line.  Another way is to increase interaction between silos.  Personal bonds can overcome a lot of process.  Sharing responsibility can work wonders.  Consider dividing the silos into virtual teams that cut horizontally across disciplines.  Make those people responsible as a group for some part of the product.  As is often the case, measuring the right metrics is half of success.

http://blogs.msdn.com/b/steverowe/archive/2007/03/21/beware-of-single-focus-roles.aspx

El error técnico de Facebook del 21Junio2013

Important Message from Facebook’s White Hat Program

Con fecha 21 de Junio de 2013 a las 13:50hs, Facebook reportó el bug en su blog, explicando lo ocurrido.

“Lo más interesante del caso, sin embargo, es la forma en que Facebook inicia su comunicado al respecto: “…nos tomamos la privacidad muy en serio…” y “…ninguna compañía puede prevenir al 100% la existencia de bugs”. En otras palabras, no importa qué tanto se preocupen por tu privacidad, siempre es posible que haya una falla en el sistema. Como siempre, la mejor recomendación es ser cautelosos en cuanto a lo que se sube a las redes.

Según admitió Facebook a última hora del pasado viernes, la información de más de 6 millones de sus usuarios, incluyendo el número de teléfono celular y la dirección de email, quedó expuesta frente a usuarios no autorizados durante el pasado año.

Se trata de una falla técnica, según la empresa, en su archivo masivo de información de contactos, que además contiene los datos de sus más de 1.100 millones de usuarios de todo el mundo.

Los usuarios de Facebook que realizaron un download de su de su lista de amigos, obtenían información adicional que no deberían tener, gracias a esta falla técnica.

Desde la siguiente página, se puede acceder a varios apartados referidos con el argumento de búsqueda: Testing
http://developers.facebook.com/bugs?search_view=search&search_ids[0]=113956392036151&&search_statuses[0]=open
Desde esta otra página, se puede reportar un ‘error técnico’:
http://www.facebook.com/help/326603310765065/

http://testingbaires.com/el-error-tecnico-de-facebook-del-21junio2013/

Can Code Be Truly Self-Documenting?

I know I'm stepping into the middle of a holy war here but I've been in some conversations on this subject lately and thought it might be worth laying out my thoughts.  Recently a coworker in another part of the company told me that they are not allowed to put comment in their code.  The argument is that code should be self documenting and any comments in the code will become incorrect over time.  Is that really true?
The idea stems from the Extreme Programming(XP) movement although it could be a misinterpretation of their views.  Certainly Vasilli Bykov argues that it is.  They argue against large amounts of documentation for sure.  To an extent, they are right.  At some point the returns on documentation diminish.  A lot of work can go into creating detailed documentation which quickly get out of date.  People update the code without updating the comments or the specs and suddenly they are worse than worthless.  Is that then a condemnation of all comments?  No.
First off, let's take on the idea that code is self-documenting.  It is not.  Not fully anyway.  Code is ultimately designed to tell a computer how to accomplish a task.  It's not foremost intended to tell a human how to accomplish a task.  For that we have prose.  While code is often readable by a human and should be made as easily intelligible by a human as possible, that is still not its primary task.  Anyone who has tried to take over an undocumented code base--even one with clean code--will tell you it is difficult.  You have to read the whole thing at least twice.  Once to build up your token list and the second time to decipher how the tokens interact.  Not everything is obvious without tracing out the actual execution in your mind (or a debugger).  This is a time consuming process.  And don't even get me started on "modern" programming fancies like keeping each function to a screen and deep callstacks.  Those have terrible implications for readability.
Comments have a lot of utility in programming.  They tell the next user what to expect.  There are two sorts of comments that are most useful.  High level comments help the next guy understand how everything works together.  Low level comments can help explain a complex piece of code or justify a particular decision. 
High level comments might be class level or even file-level.  They explain what the intent of this part of the program is, some information about how the various classes and functions interact, etc.  When first tackling a new codebase, these kinds of comments can be invaluable.  Trying to build up an understanding of the architecture of code by reading each function is like trying to see the pattern in a mosaic using a magnifying glass.  It's really hard.  It's better to step back and take in the whole picture at once.
I once had to make some modifications to Postgresql for a class.  To do this I had to understand how the various pieces worked together to make sure I modified all the right parts.  There were no specs available but most of the files had a header block which explained what the functions and data structures in the file did.  This proved invaluable.  Instead of having to go understand each structure, then see how the functions used them, then finally to understand how the myriad functions interacted with each other, I could read this synopsis and focus on just the parts that mattered to me.  I also quickly got a sense of whether I was making modifications in line with the original intent or not.  Without any comments, I would have spent much longer trying to accomplish the same task.
Low level comments are usually interspersed within a function or method.  They should serve two primary purposes.  First, they should explain any complex actions going on.  Math is notoriously hard to understand from code.  This becomes even more true if it is optimized.  Comments telling you that a lookup table is being used to implement clipping is a lot easier to understand than to go look at the table and surmise its purpose from the values in it.  The other really valuable purpose is to explain any deviation from standard practice.  Sometimes the obvious solution is incorrect.  There are bugs caused by side effects or subtle corner cases which go unnoticed.  If you were to write the code to fix the bug in those cases without comments, the next guy is likely to undo your fix and recreate the bug.
Other sorts of comments can be useful too.  A header block on a function or method describing the purpose and what each parameter does is a lot faster to read and interpret than trying to divine the same information by reading the whole function.  It's not that it cannot be done.  It can.  It just takes a long time.
So code can't be fully self-documenting.  But if the comments are out of date, isn't that worse than no comments at all?  An argument can be made that it is.  It takes a while to notice that the comments are wrong and then you have to go back to the code anyway.  In that case, you might as well not have had any comments.  This argument, however, is based upon the premise that the comments will inevitably become incorrect.  I dispute that.  The answer is simple:  update the comments when you change the code.  When code is refactored, the comments must be refactored as well.  Not doing so is just as bad as not running the unit tests or not checking return values.
Of course the response is that this never happens.  Does that have to be the case?  Changing code without changing the comments is introducing a bug.  Not a computer-level bug but a programmer-level one.  This is poor programming.  Don't do it.  Code reviewers should be vigilant for this sort of thing and flag any wrong comments as errors.  Once upon a time no one tested the code they wrote.  No one had it reviewed.  No one wrote unit tests.  Most of these are part of a standard best-practices regimen today.  Can't updating comments just be added to the list of best practices?  I see no reason it cannot.
Comments are, in my mind, an indispensable part of healthy software.  Good programming is not just about communicating with the computer but also with the next programmer.  At some point you'll move on and someone else will have to work in your codebase.  At that point comments become important not only for reducing ramp-up time but critical to avoid making the same mistakes twice.

http://blogs.msdn.com/b/steverowe/archive/2007/04/07/can-code-be-truly-self-documenting.aspx

Ejercicios Diagrama de flujo - parte 3

 Ejercicios de diagrama de flujo sobre vectores de números.

Los demás ejercicios Parte 1   Parte 2   Parte 3   Parte 4   Parte 5   Parte 6   Ejemplo 1   Ejemplo 2   Ejemplo 3   Ejemplo 4   Ejemplo 5
 
Arreglo: Un Arreglo es una estructura de datos que almacena bajo el mismo nombre (variable) a una colección de datos del mismo tipo y lmacenan los elementos en posiciones contiguas de memoria. Tienen un mismo nombre de variable que representa a todos los elementos. Para hacer referencia a esos elementos es necesario utilizar un índice que especifica el lugar que ocupa cada elemento dentro del archivo.

Tipo de Arreglos

• Unidimensionales
  

  Vector: Es un arreglo de “N” elementos organizados en una dimensión donde “N” recibe el nombre de longitud o tamaño del vector. Para hacer referencia a un elemento del vector se usa el nombre del mismo, seguido del índice (entre corchetes), el cual indica una posición en particular del vector.

• Bidimensionales
  

  Matriz: Es un arreglo de M * N elementos organizados en dos dimensiones donde “M” es el numero de filas o reglones y “N” el numero de columnas. Para representar una matriz se necesita un nombre de matriz se necesita un nombre de matriz acompañado de dos índices.
  Mat [R,C] Donde R indica el renglón y C indica la columna, donde se encuentra almacenado el dato.

   

Lee un Vector numérico de dimensión 10 y determina cuantos son positivos, negativos y neutros, imprimiéndolos y contabilizándolos, para finalmente imprimir el conteo en pantalla. Link

Rellena una matriz cuadrada de 7*7, y calcula la suma de cada renglón o fila, y cada columna, y luego las almacena en un vector. Link

 

 

 

Lee una matriz de 5*6, e imprime la suma total de la matriz. Link

 

 

Lee un vector numérico de dimensión N, y multiplique el vector por un escalar X. Link

 

 

 

Lee un vector numérico de dimensión N, y calcula la sumatoria de sus elementos. Link

 

Breaking Down the Test/Dev Barrier

Similar to the solution I consider in my post on single-function roles, the Braidy Tester has a provocative new post entitled, "Let's Go Bust Some Silos" wherein he asks what happens when you get rid of the test/dev silos and have everyone work together under one roof.  Instead of having one group write dev code and not test it much and another team who wrote tests but didn't understand it much, have a single team which writes and tests fluidly.
One of his commenters, Jim Bullock, raises some good concerns about such an arrangement.  Is it really possible for someone focused on the creation to be objective enough to test?  Do we need someone tasked with breaking things to get over the tendency to see ones own success?  He also suggests that having test/dev silos help different sorts of personalities get along.  There might be some merit to this.  On a team where test and dev are integrated, a non-coding tester is likely to be treated as inferior.  On a test-only team, their value is probably more highly regarded.  This need not be so, but too often it is.
In considering this question, it is interesting to consider why we have separate testing teams to begin with.  How did they come about?  At one point all you had were developers.  They tested their own stuff.  Later, independent testers came into the picture and organized on independent teams.  Why was that?  If anyone was there for this formation or knows of books which speak of it, let me know.
I suspect that this happened because developers were found too busy to give sufficient time over to testing.  The desire for more features made it hard to take the time to test.  In a day without unit tests, the time it took to test was very large.  Stopping to do so might mean missing a deadline.  Based on that, it makes sense to bring in someone whose whole time is taken up by testing.  There is no pressure for that person to add features at the expense of testing.  Today, however, when we have automated tests and unit tests which can give us a lost of testing without a lot of time, do we still need this separate role?

http://blogs.msdn.com/b/steverowe/archive/2007/04/07/breaking-down-the-test-dev-barrier.aspx

It's Difficult to Grow a Test Developer

A lot of testers begin life as software test engineers.  That is, they execute tests but don't do any (or much) programming.  The dream of many testers is to become a test developer or a developer.  Reciprocally, the dream of many test managers is to grow their testers into test developers.  Is this a realistic dream?  It can be, but probably isn't in most cases.
It's very hard to become a self-taught developer.  When we look out at the computer landscape we see plenty of self-taught programmers so it looks easy.  However, for each one that succeeds, many more fail.  Why is that?  Two reasons I suspect.  First is that some people are just not cut out to be programmers.  Second, and perhaps more important, is that it is really hard.  Becoming a good programmer* requires a lot of knowledge.  That means a lot of reading (online or books) and a lot of practice.  It turns out that it is a lot easier to desire to be a programmer than to put in the work to become one.
I covered the first point in my post entitled You Can't Teach Height.  Studies show that a good number of people, even those interested in programming, cannot grok it.  My suspicion is that this has to do with the abstract nature of programming.  This isn't to say that they can't program at all but they can't program well and as the difficulty goes up, more and more drop off.
The second reason is the one that gets a lot of people.  I've seen many try to make the leap and only a few succeed.  Those that did had to put in a lot of work on their own time.  Those that didn't often weren't willing to put in time outside of work.  Anyone desiring to go from tester to test dev with just the time they spend on the job is probably going to be disappointed.  It takes a whole lot of effort to become a competent programmer.  I laid out my recommendations in one of my earliest posts.  I call for learning not just the syntax but also the essentials of computer science.  You can program without these but if you don't pick them up you'll never be great.  Learning them, however, takes a lot of time and effort. 
Most of the time employers won't give you that time.  They want you to be productive and anyone learning to program is not productive.  The simplest things take a long time.  There is almost always a more competent programmer on the team somewhere and if work needs to be done, it will be given to him.  It's not that most managers discourage learning to program.  They'd like it to happen.  They just won't often budget enough of your time to actually do it.
Now that I've said how hard it is, are there things that testers can do to increase their odds?  What about test managers?  I'll cover the issue from both perspectives in future posts.

* It is important to note what I'm talking about here.  It's not too hard for someone to teach themselves enough C# to write an ASP.Net page or enough perl to parse some log files.  That, however, is a far cry from being able to write a test harness, analyze performance, or automate the testing of a COM object.

http://blogs.msdn.com/b/steverowe/archive/2007/04/20/it-s-difficult-to-grow-a-test-developer.aspx

Entrevista: ISTQB y sus Certificaciones: Alcance, Beneficios y Proyección

Sumario

Entrevista a Marcelo Cusmai acerca del alcance, beneficios y proyección de las Certificaciones de ISTQB.

ISTQB, Certificaciones

Introducción

Si nos pusiéramos a investigar hace cuánto que las ‘Certificaciones’ en Software Testing están siendo difundidas en nuestro país (Argentina), podríamos ver que es relativamente muy poco el tiempo.

En virtud a ello, y como vengo siguiendo el tema desde sus comienzos por diferentes canales, además de los anuncios y debates que se publican al respecto desde nuestro grupo de discusión en LinkedIn: TESTING & QA, le propuse a Marcelo Cusmai (miembro del grupo de discusión) entrevistarlo para que nos contara sobre este tema, entendiendo que es uno de los referentes en Argentina.

Entrevista (TB: TestingBaires / MC: Marcelo Cusmai)

TB: Marcelo, si bien visitando el sitio oficial de QAustral se puede acceder a todo tipo de información sobre las Certificaciones en ISTQB, ¿Cómo podrías brevemente explicar porqué es útil y/o necesario que un Tester obtenga este título?

MC: Además del conocimiento, y el ordenamiento de contenidos del programa, al igual que en otras disciplinas informáticas, una certificación internacional asegura que el profesional tiene un conocimiento calificado sobre un tema en particular. En el caso de un profesional de sistemas certificado en determinado lenguaje de programación, norma o práctica, una certificación no asegura que sea un excelente profesional, pero sí asegura que sabe de lo que habla. En el caso de las certificaciones de Software Testing sucede lo mismo, por esa razón se observa mucha supervisión en los mecanismos de certificación.

En términos profesionales ser certificado es un diferenciador importante y de valor agregado. En muchas de nuestras búsquedas que tenemos abiertas para equipos en el exterior y que se observan en nuestra web y portales de empleos, ser certificado es un requisito puesto por los mismos clientes del servicio de testing.

En términos operativos, marketing y comerciales, se facilita mucho el lenguaje y los alineamientos de trabajo al momento de iniciar servicios con empresas en otras regiones e incluso con colegas que a la larga nos asociamos para avanzar en determinados terrenos. Mucho de esto último ha sido observado por los responsables de ISTQB en Europa que han creado el programa de Partners para empresas desde 2012.

TB: Actualmente ¿Cuáles son las acciones que estás llevando a cabo para difundir este tipo de certificaciones?

MC: En el caso de ISTQB FL disponemos actualmente de una red muy amplia ya que fuimos los terceros en Latinoamérica y los primeros en Argentina y Chile en ofrecer y disponer de programas oficiales, las disertaciones, los contactos empresa y la llegada a particulares por diversos medios facilitaron mucho dar a conocer en forma masiva y no tan sectorizado el objetivo de la certificación y del conocimiento que propone. Por otra parte nuestro corazón de negocio es el servicio de Testing y Calidad de software en muchas variantes, proponer cursados y certificaciones ISTQB en distintos niveles, certificaciones IREB y otros entrenamientos, surgió como una tercer linea de actividades institucionales y se desprendió de una necesidad de docencia sobre la temática que nos requerían incluso universidades amigas.

TB: ¿Consideras que en Argentina han aumentado los Certificados? y si fuera así, ¿Qué beneficios le trae a la empresa tener personal certificado?

MC: En términos directos sobre el contexto informático en general sí ha aumentado el número de certificados, pero más que eso ha aumentado el dominio de determinados valores de conocimiento propuestos por la certificación. Sobre todo en el modo y tratamiento del producto y algunos puntos que no estaban contemplados por las normas de procesos. No todos los profesionales que estudian o toman cursos sobre ISTQB FL o AL se certifican, muchos profesionales solo quieren tener el conocimiento y aplicarlo en su tarea cotidiana, aportar valor agregado a su equipo y no necesariamente rendir la certificación. El conocimiento sobre técnicas, métodos y otros detalles de la actividad es principalmente lo que aumenta a cada minuto.
En cuanto a beneficios en las empresas son muchos, supongo que los protagonistas directos podrían enumerar cientos y sumar experiencias particulares, pero por decir algunos y por experiencias incluso de nuestro factory, se pueden observar determinados cambios de conducta y optimizaciones de tiempos, unificación de vocabulario, dinámica con otras áreas y seguridad. El “saber que hacer” ante determinadas situaciones y tener un respaldo de teoría fundamentada es muy importante y es algo que se desprende directamente del conocimiento y apoyo que propone el Syllabus. Además en los equipos en distintas regiones, asegurar que todos nos referimos a lo mismo cuando utilizamos un termino es muchas veces vital. De ningún modo es lo mismo trabajar en un equipo de testing profesional que con innovadores, y con esto no quiero decir que sea necesario ser certificado para ser profesional, pero como decía anteriormente un certificado sabe de lo que esta hablando, o al menos ha tenido que pensar mucho y estudiar la temática. El valor del conocimiento en un concepto de grupo de trabajo también aporta un valor agregado de importancia a cualquier institución.

TB: ¿Tiene QAustral algún tipo de estadística que le indique el mapa actual en Argentina de Certificados?

MC: Antes de que comenzáramos a proponer esta certificación a nuestros clientes y dictarla en forma abierta, había en el país solo 8 certificados en el Board regional que pertenecían a una multinacional en Argentina. También había un número impreciso de alrededor de 30 profesionales con los que hemos tenido contacto que habían rendido exámen en el sistema Prometric o certificado en el exterior. En los dos primeros años de nuestra actividad y refiriéndonos solo a ISTQB FL certificamos mas de 100 profesionales, no todos realizaron cursados, seminarios o talleres. Actualmente en Argentina, y ya con el conocimiento instalado y con variantes de formación se encuentran entre 150 y 200 certificados, el Board HASTQB tiene unos 130 registrados, y como decía anteriormente hay un número de profesionales que ha rendido en el exterior o por el sistema Prometric que estaba vigente hasta 2011, actualmente solo esta vigente en la región el sistema Pearson Vue por lo que los que rinden en esa modalidad también son registrados directamente en el Board.

TB: ¿QAustral esta trabajando en concretar alianzas con las Comisiones Oficiales, Universidades, Polos Tecnológicos, Clusters y/o Empresas Privadas o del Estado?

MC: La primer actividad de la firma en relación a compartir conocimiento social y profesionalmente no fué la presencia de ISTQB o IREB como certificaciones. En 2006 creamos la primer diplomatura oficial de Argentina en Testing de Software, en conjunto con la Universidad Empresarial Siglo XXI, posteriormente también trabajamos con otras Universidades en diplomaturas y cursos como con UTN, El Cluster Tecnológico de Jujuy, el de Córdoba, Cessi, y algunas agrupaciones tecnológicas en España y UK.
Constantemente estamos trabajando en avanzar en este tipo de conocimientos y apoyando incluso la aparición de nuevos proveedores en la región. En cuanto a alianzas para dictados tanto de certificaciones como de cursos en general contamos en este momento con no menos de cinco asociados directos en Argentina que nos permiten tener presencia en distintas provincias, como CcyD en Buenos Aires o Capa Ocho en Rosario. En este último caso al igual que Qaustral en Cba son certificadores Pearson Vue, eso permite que quienes cursen certificaciones pueden rendirlas en el mismo centro, y tener diversas posibilidades de adquirir vouchers de exámen con nosotros. También contamos con asociados en el exterior que en muchos casos comenzaron siendo clientes, y actualmente tenemos muchas actividades en conjunto. Localemnte tenemos una serie
de actividades planificadas también con instituciones oficiales y privadas, que si el tiempo lo permite vamos a desarrollarlas en Bs As y Córdoba y se trata de una serie de seminarios y cursos gratuitos y arancelados de bajo costo destinados a brindar conocimiento a Testers iniciales o profesionales interesados en enriquecer su formación. Esto no tiene nada que ver con ISTQB pero me parece oportuno para responder a la pregunta.

TB: ¿QAustral tiene algún tipo de comunidad donde el Tester interesado pueda acceder a información y beneficios?

MC: A nivel institucional se cuentan con las herramientas circulares existentes en la web, comunidades en Facebook, Linkedin, Twitter y presencia de Blogs que se relacionan con diversos medios, entre todas las comunidades contamos con unos 600 seguidores. En cuanto a beneficios, mas allá de ser los lugares donde primero anunciamos formaciones o seminarios arancelados o gratuitos, búsquedas laborales y novedades, en algunos casos proponemos premios relacionados, por ejemplo en algunas formaciones de 2011 y principios de 2012 organizábamos al finalizar el curso un exámen simulado y al puntaje más alto le costeábamos la certificación. Es decir que era un beneficio real y que queda de por vida , si el tester aprueba, claro. Igualmente ahora tenemos algunas otras actividades que en marco de relaciones de interés real en la temática aportan un crecimiento mutuo en relación al conocimiento.

TB: ¿Cuáles son las ventajas a nivel profesional que brinda esta certificación?

MC: Esta es una pregunta que contiene varios matices según la región donde se formule, incluso en la misma Argentina, según se formule en los principales polos donde se encuentran los certificados en este momento o en otras regiones mas alejadas. Pero términos generales es un valor que posee el profesional de por vida, es un diferenciador y es una valoración de interés sobre una temática en particular.
En el contexto actual de Argentina, un Tester Certificado ISTQB FL, posee valiosas oportunidades laborales, sobre todo en un mercado con gran rotación de perfiles informáticos y con necesidad de conocimiento calificado constantemente. En el país contamos con un Staff joven en relación al Testing de Software Profesional, y no me refiero a la edad de los profesionales, sino a que es una actividad que comienza su pico profesional en 2006, antes de eso también se encontraban actividades de testing pero no al nivel y cantidad profesional de la actualidad. Si se observa el crecimiento de normas en el mundo y la creación de Boards, se puede ver que todos estos ámbitos son jóvenes, en su mayoría han iniciado actividades oficiales en 2001 o 2002. En este contexto de constante crecimiento de conocimiento y también de requerimiento de esta profesión, ser certificado es un diferenciador de gran valor. Cada institución o empresa puede brindar determinados beneficios y oportunidades a sus equipos y una certificación profesional es un aporte de conocimiento que el Tester lleva consigo durante toda su vida activa laboralmente.

TB: ¿Están pensando en organizar reuniones ‘físicas’ y/o ‘virtuales’ para mantener actualizada a la comunidad de Testers certificados?

MC: Este año ya hemos realizado reuniones virtuales y envíos compartiendo algunas novedades que han aparecido en las ultimas versiones de Syllabus o incluso en nuevas oportunidades de certificación, y no solo de ISTQB. Si bien estas propuestas han sido desarrolladas solo para quienes se han formado en nuestras instalaciones estamos abriendo las propuestas para el profesional en general desde el mes de Noviembre, ya que también vamos a publicar en las comunidades.

TB: ¿Qué le recomendarías al Tester que todavía tiene dudas sobre si encarar o nó el estudio de esta certificación?

MC: Entiendo que el conocimiento nunca esta demás, sino que en este caso en particular es muy necesario ya que se encuentra evolucionando constantemente. Entiendo que la disponibilidad al conocimiento es una buena cualidad para cualquier profesional, y no solo refiriéndome al conocimiento que propone ISTQB en todos sus niveles, sino también otras propuestas como IREB o CAT según la especialización de cada profesional. En el caso de ISTQB es la que más certificados posee en la actualidad en relación al tratamiento del producto, incluso el nivel Advanced ha sido tomado como fuente en las nuevas normas ISO.

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

MC: Algo que puede ser de Interés y que pretende marcar la apertura de un evento Testing Camp en 2013 son los seminarios y talleres Testing Camp que desarrollaremos en la segunda quincena de Noviembre, donde asistirá uno de los principales traductores de Syllabus que viaja desde España . En estos eventos de dos jornadas y arancel de bajo costo tendremos cupos limitados para seminarios que no se dictan habitualmente y que son de gran utilidad en la especialización de Testing como puede ser Trazabilidad, Requerimientos y seminarios de exámen, entre otros temas, en Capital Federal.

Agradezco a Marcelo Cusmai por su predisposición con la entrevista y todo lo que nos ha aportado.

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

Te invito a que te unas al grupo y puedas conocer las novedades de nuestra actividad y participar de las discusiones.

http://testingbaires.com/entrevista-istqb-y-sus-certificaciones-alcance-beneficios-y-proyeccion/

Teaching Your Team To Program

The world of testing is becoming a lot more technical than it once was.  While there is still a need for strong exploratory testing, the need for test automation is increasing dramatically.  Test automation requires programming at some level.  Good test automation requires skilled programmers.  Thus the need for test developers is increasing.  As I've said before, learning to program is hard.  As a manager of a team of non-programmers (or semi-literate programmers), is there a way to train them to become what you need?  Is it better to just go hire programmers and teach them to test?  As I've said elsewhere, I think it is easier to teach a programmer to test than to teach a tester to program.  This post, however, is about doing just that:  developing programmers out of an intact test team.  Here is my advice on how to do that.
First, don't expect everyone to make the transition.  For some it will be impossible.  For others, there will be little interest.  Remember, you still need manual testing.  You don't want your whole team to convert.  Look for the ones that show interest and aptitude.  To find the ones who really show interest, you have to make it clear you don't expect everyone to move.  You have to make it clear that this isn't a promotion.  If getting promoted (or keeping your job) requires learning programming, everyone will want to.
Provide opportunity to learn.  Expecting people to know how to program before you give them the opportunity to do so will guarantee failure.  If you only give programming assignments to those who already know how, you won't develop any new programmers.  Learning programming on your own time is something only a few will be able to accomplish.  It is hard.  Instead, find some tools you need written or features you need added to existing tools and offer the chance to work on them.  See who grabs the opportunity and push them.
Give them time to learn.  Beginning programmers won't be productive.  It will take them 10x as long to do something as an experienced coder.  That's okay.  You have to budget for that time.  The payoff will come later.  It is important that management guard that time also.  I've seen many times when management hands out an opportunity but then quickly piles up the non-programming work so there is no time to learn.  If you ask someone to write a tool, make sure they have long, uninterrupted blocks of time to focus on it.  As an upper-level manager, hold your leads accountable for providing this time.
Provide mentors.  Books and blog posts only cover so much.  There are a lot of little details and corner cases they don't discuss.  New programmers need someone they can approach to ask questions.  Getting stuck on a problem for 2-3 hours is healthy.  Being stuck for 2-3 days is discouraging.  If you have test-developers on your team, utilize them.  If you don't, talk to the dev manager about using his people in this role.
Make it an assignment.  Hold the aspiring programmers accountable for their output.  Learning to program shouldn't be extra credit.  When things get busy, extra credit falls by the wayside.  Instead, make it part of their commitments for the period.  Discuss the assignment during your 1:1s.  If they don't get it done (whatever done means) by review time, hold it against them.  It has to be treated like any other assignment.  If they didn't get their test pass done, you would care.  They need to know you'll care if they don't learn how to program.
Give real assignments.  Don't ask them to write something you're going to throw away.  Have them working on production code.  Pick a simple tool.  Better yet, have them augment an existing one.  The assignments should also be in the same language as the application.  Teaching them to program Visual Basic in Visual Test isn't training them to understand your product.  Their utility will be limited if they can't interact with the developers.  Finding mentors will also be harder.
Finally, give them an escape hatch.  Programming isn't for everyone.  If someone determines it isn't for them, let them go back to exploratory testing or whatever they were doing before.  Forcing someone to learn something they don't want to is doomed.

http://blogs.msdn.com/b/steverowe/archive/2007/04/26/teaching-your-team-to-program.aspx

Teaching Yourself To Program

Following up on my last post, I'll give some instruction for those testers who want to become programmers.  As I said, last time, don't expect to learn everything you need to at work.  The forces in play will almost certainly conspire to keep you from being able to.  If you desire to expand your horizons and become a programmer (either staying in test or moving to dev), here are some ideas that can aid you in your journey.
Look for opportunities to program.  Take advantage of them when they appear.  There's always an extra tool that needs to be written.  There's always a feature that would be really nice to have added to an existing tool.  If you want to get support for your learning, this is your best chance.  If you can do it and show the benefit to the team, you'll often be rewarded by more opportunities.  The only way to get good at programming is to program.  Practice every chance you get.  I've seen plenty of aspiring developers ignore chances to develop tools at work.  The ones that do rarely--if ever--make the leap.
Start small.  When you are starting out, it is usually easier to add functionality to an existing program than to write something from scratch.  This is because you have a structure to work with.  When you are learning to program, you don't know how to put all the pieces together.  You'll learn that, but starting out it can be hard.  Working on something similar to an already-existing feature can be a good place to start.
Learn the language of your application.  While Ruby, Python, or Visual Basic may be appealing and even easier to learn, unless they are the language the application you are testing is written in, you'd be best not to spend your time learning them--yet.  Eventually, yes, but they won't really help you get where you want to go.  There are two reasons for this.  First, the most effective test automation is done in the native language of the application.  Anything else doesn't align quite right and will make reaching the corners hard.  Second, the people you can learn the most from--the application's developers--can only help you if you speak their language.
Ask a lot of questions.  Potential candidates often ask what working at Microsoft is like.  I invariably tell them that it is a very supportive environment.  When you ask a question, you always get a detailed answer and usually a history lesson about why it is that way.  I suspect that we're not alone in that respect.  Most developers enjoy what they are doing and want to share that joy.  If you ask them a question about how their program works or even about some project you are doing (that test tool you are writing) and the problem you are stuck on, they'll often be happy to help.  Be careful not to take too much of a person's time and be especially careful not to ask the same question twice, but don't be afraid to ask.  Part of learning on your own is asking questions of those more skilled than you.  My rule of thumb is to spend a few hours trying to solve any problem.  If you still don't have an answer, go ask someone.
Be prepared to put in the work.  The job you were doing before you decided to go down this route didn't go away.  You'll still need to do it.  Learning to program isn't simple.  It will take time.  The combination is going to take a lot of time.  Be prepared to show up early or stay late to work on your project.
Don't quit.  There will be times when you get too busy to learn.  There will be bugs that stump you for a long time.  Don't lose track of what you are doing.  Don't get out of the habit.  Don't take on projects and then let them languish for months.  You have to keep going.
Put in time outside of work.  Read.  Either online or on dead trees.  A lot.  Practice.  A lot.  Pick up a side project and work on that.  Open source make a good place to start.  Just working on something of your own does too.  Work on programming a game or writing a tool.  It's not even important that you finish so long as you are working.  If you want to become a developer, it should be because you enjoy programming.  Use this joy to your advantage.  What you learn on the side will help make the stuff you do at work make more sense and go faster.

http://blogs.msdn.com/b/steverowe/archive/2007/04/26/teaching-yourself-to-program.aspx