Becoming a Lead, Pt. 1

At Microsoft, there are two classifications of people:  Individual Contributors and Managers/Leads.  Individual contributors are those who spend most of their time doing the work that makes software spring into existence.  These are the programmers, testers, and program managers that create the products.  Managers and Leads are those who spend a large part of their time making sure everyone else has time to do real work.  Leads are usually those who have a few people reporting to them and Managers are those who have leads or other managers reporting to them.  Those of us who are managers pay attention to schedules, product roadmaps, bug trends, people development, and—most importantly—making sure that our people are not blocked.

There comes a time in many careers where a person makes the transition from an individual contributor to a lead.  There are some big differences and not all of them are obvious.  This series of posts will cover many of those aspects.  The things I talk about will be specific to the software industry but should be applicable in any occupation.  Before I start, however, let me give some thoughts on the prerequisites for becoming a good lead.

Great leaders are grown, not born.  No one comes out of school ready to be a great lead.  It takes a solid foundation before you can effectively lead.  If you try to lead without that foundation, you’ll end up being more Pointy Haired Boss than Great Leader.  To get a solid foundation, spend some time (several years at least) doing whatever it is you expect to be leading people at.  As this blog is about the software industry, spend several years programming or testing (or both) before trying to lead testers or developers.  Once you become a lead, you will have less direct exposure to the technology.  You’ll need a solid background to understand everything those reporting to you are working on.

Not everyone is cut out to be a lead.  I’ve seen too many times when a great developer is forced to become a manager.  What results is often the loss of a good programmer and the creation of a bad manager.  I’m very much with the author of First, Break All the Rules.  One of his basic premises is that people have certain talents and if you don’t have the right talent for a particular job, the best you can be is mediocre.  For instance, I’m not artistically inclined.  I could go to art school and get lots of training, but I’m never going to be a great artist.  Likewise, if you are not naturally a leader, you’ll never make a great one.  With the right talent, and the right training, a person can become a great leader.  Without both, they never will. 

How do I tell if someone is a natural leader?  I have a thought experiment I like to apply.  If I put together 3 people on a project and tell them what the goal is but don’t assign any of them roles, by the end of the project one of them will be contributing more to the overall direction than the others.  Someone will be the person designating who works on what.  This is not the bossiest person.  Without a talent for leadership, the person will be seen as pushy and their leadership will be rejected.  The good leader will lead without having to claim the mantle of leadership.  Instead, it will be given to him/her by the others on the team.  It may not be verbalized, but there will be one person the others look to for help making decisions.  That’s the natural leader.

I once had a report who claimed he wanted to be a leader.  I gave him responsibility for an area and another person to help him do the work.  A few months later, the helper was doing his own thing.  He was being given no direction.  Needless to say, when this person came to me and asked why I didn’t make him a lead, I just had to point to that incident.  When given the chance to lead, he didn’t take on the role.  Leadership is a behavior, it is not a title.  If you think you want to become a manager, do so because you enjoy leading, not because you want the title or the prestige.

http://blogs.msdn.com/b/steverowe/archive/2006/03/08/546210.aspx

Automatización de pruebas de software.

Las pruebas automatizadas constituyen una necesidad casi absoluta en los proyectos que impliquen la creación y desarrollo de software, estas incluyen una amplia gama de beneficios que no están disponibles para las pruebas manuales.

En la actualidad existe una gran variedad de herramientas para realizar pruebas automatizadas. Estas proporcionan una ventaja evidente partiendo de tiempo y conservación de los recursos, sin comprometer la calidad del procedimiento de prueba, la exactitud de los informes finales y la eficiencia del proceso de pruebas, son efectivas y económicamente factibles. El uso de las mismas permite tener más comodidad en la elaboración de los errores y fallos que se producen antes de que el producto de software es liberado, o en momentos en que hay una necesidad de proporcionar asistencia al cliente para resolver los defectos encontrados.

Las pruebas automatizadas han mejorado enormemente el proceso básico de perfeccionamiento de aplicaciones web y sus beneficios se encuentran disponibles para desarrolladores. A continuación se citan algunas de sus ventajas:

• Confiables: Las pruebas realizan con exactitud diversas operaciones cada vez que se ejecutan, de tal modo que evita posibles errores humanos.
• Recursivas: Evidencian cómo el software reacciona bajo diferentes condiciones, cuando se está probando una misma operación repetidamente.
• Programables: Permiten programar pruebas sofisticadas que pongan en evidencia la robustez del software que se pruebe.
• Abarcadoras: Facilitan la construcción de un ambiente de pruebas que cubra cada característica del software.
• Reutilizables: Permite reutilizar pruebas en diversas versiones.
• Factibles: Se pueden ejecutar más pruebas en menos tiempo y el número de los recursos se reduce.
• Rápidas: Su ejecución es perceptiblemente más rápida.
• Flexibles: Las pruebas deben ser fáciles de entender, de modificar y de extender.

Las pruebas automatizadas se ejecutan mediante el empleo de herramientas que facilitan las tareas de un probador de software.

lgunas pruebas de software tales como las pruebas de regresión intensivas de bajo nivel pueden ser laboriosas y consumir mucho tiempo para su ejecución si se realizan manualmente. Adicionalmente, una aproximación manual puede no ser efectiva para encontrar ciertos tipos de defectos, mientras que las pruebas automatizadas ofrecen una alternativa que lo permite. Una vez que una prueba ha sido automatizada, ésta puede ejecutarse repetitiva y rápidamente en particular con productos de software que tienen ciclos de mantenimiento largo, ya que incluso cambios relativamente menores en la vida de una aplicación pueden inducir fallos en funcionalidades que anteriormente operaban de manera correcta. Existen dos aproximaciones a las pruebas automatizadas:

• Pruebas manejadas por el código: Se prueban las interfaces públicas de las clases, módulos o bibliotecas con una variedad amplia de argumentos de entrada y se valida que los resultados de obtenidos sean los esperados.
• Pruebas de Interfaz de Usuario: Un marco de pruebas genera un conjunto de eventos de la interface de usuario, tales como teclear, hacer click con el ratón e interactuar de otras formas con el software y se observan los cambios resultantes en la interface de usuario, validando que el comportamiento observable del programa sea el correcto.

La elección misma entre automatización y ejecución manual de pruebas, los componentes cuya prueba será automatizada, las herramientas de automatización y otros elementos son críticos en el éxito de las pruebas, y por lo regular deben provenir de una elección conjunta de los equipos de desarrollo, control de calidad y administración. Un ejemplo de mala elección para automatizar, sería escoger componentes cuyas características son inestables o su proceso de desarrollo implica cambios continuos.

En el desarrollo contemporáneo de software existe una tendencia creciente a usar Frameworks como los denominados XUnit (por ejemplo JUnit y NUnit) que permiten la ejecución de pruebas unitarias para determinar cuándo varias secciones del código se comportan como es esperado en circunstancias específicas. Los casos de prueba describen las pruebas que han de ejecutarse sobre el programa para verificar que éste se ejecuta tal y como se espera. La automatización de pruebas es una característica clave del desarrollo ágil de software en donde se le conoce como "desarrollo guiado por pruebas". En ellas, las pruebas unitarias se escriben antes que el código que genera la funcionalidad. Sólo cuando el código pasa exitosamente las pruebas se considera completo. Cuando hay cambios, el programador descubre inmediatamente cualquier defecto que rompa los casos de prueba lo cual baja el costo de la reparación. Dos inconvenientes de este estilo de trabajo son:

1. Algunas veces se "desperdicia" la capacidad del programador escribiendo las pruebas unitarias. El entrecomillado se debe precisamente que asegurar la calidad del producto no es desperdicio alguno.
2. Normalmente se prueban los requerimientos básicos o el flujo normal del caso de uso en vez de todos los flujos alternativos, dado que extender las pruebas más allá de la prueba base eleva el costo del producto. En algunas ocasiones los flujos alternativos son probados por un equipo de pruebas más o menos independiente del equipo de desarrollo.

Muchas herramientas de automatización de pruebas proveen características para grabar y reproducir acciones del usuario para posteriormente ejecutarlas un número indefinido de veces, comparando resultados obtenidos con resultados esperados. La ventaja de ésta aproximación a la automatización es que requiere de menos desarrollo de software, sin embargo el confiar en éstas características del software lo hace menos confiable en la medida que muchas veces dependen de la etiqueta o posición del elemento de interfaz, y, al cambiar, el caso de prueba debe ser adaptado al cambio o probablemente fallar. Una variante de estas pruebas es la prueba de sistemas basados en la web en las que la herramienta de prueba ejecuta acciones sobre el navegador e interpreta el HTML resultante. Una variación más es la automatización sin scripts, que no usa grabación y reproducción de acciones sino que construye un modelo de la Aplicación Bajo Prueba (AUT en sus siglas en inglés, ABP) que permite a la persona que prueba ("tester") que cree pruebas simplemente editando parámetros y condiciones.

Data-driven testing

Una vez teniendo el script para prueba automatizada, con poco esfuerzo más podemos obtener mucho más beneficio de esta misma nave. En este caso, podemos parametrizar la prueba y hacer que cada valor ingresado en cada campo sea tomado de un data pool (fuente de datos de prueba, tal como una tabla o archivo), y así estar probando distintos escenarios.

 Nuestros datos de prueba necesitan pueden ser una tabla con las siguientes columnas, que corresponden a los campos de la forma de registro de cliente: First_Name, Last_Name, Country_Name, City_Name, Address, Balance.

 Entonces tendremos un datapool con estas columnas. Luego podremos pensar distintas combinaciones de valores para probar. Por ejemplo, valores nulos, o valores muy grandes, strings muy largos, balances negativos, etcétera. Así, la misma prueba la puedo ejecutar con todas las combinaciones de datos que se me ocurran con tan solo ingresar los valores en una tabla. Esta ejecución la puedo hacer cada vez que se necesite, obteniendo información sobre el estado de la aplicación en forma casi inmediata.

 Si esta prueba la tuviera que ejecutar en forma manual con cada dato de prueba interesante, me llevaría más tiempo que ejecutarla automáticamente. O sea, los beneficios de este caso de prueba automatizado se ven directamente en este ciclo de pruebas, y no recién en el siguiente ciclo de pruebas de regresión. Son beneficios a corto plazo, con lo cual, visto de esta forma, es muy conveniente comenzar a automatizar.

 De acuerdo a lo que cuenta Cem Kaner en uno de sus artículos automatizar una prueba lleva entre 3 y 10 veces más que ejecutarla en forma manual (este artículo es de 1997, pero es aún vigente, o en tal caso, el costo es menor). Incluso, si en los siguientes ciclos de prueba tenemos cierto costo de mantenimiento de estos casos de prueba, imaginemos que también de 10 veces más que el costo de ejecución manual, también obtendremos beneficios si ejecutamos 11 veces la prueba de regresión.

Why Does Software Have Bugs?

What is a software bug?
A software bug is a failure or flaw in a program that produces undesired or incorrect results. It’s an error that prevents the application from functioning as it should.
Why does Software have bugs?
There are many reasons for software bugs. Most common reason is human mistakes in software design and coding.
Once you know the causes for software defects it will be easier for you to take corrective actions to minimize these defects.

Top 20 reasons for software bugs

1. Miscommunication or no communication
Success of any software application depends on communication between stakeholders, development and testing teams. Unclear requirements and misinterpretation of requirements are two major factors causing defects in software. Also defects are introduced in development stage if exact requirements are not communicated properly to development teams.
2. Software complexity
The complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity. And the use of object-oriented techniques can complicate instead of simplify a project unless it is well-engineered.
3. Programming errors
Programmers, like anyone else, can make mistakes. Not all developers are domain experts. Inexperienced programmers or programmers without proper domain knowledge can introduce simple mistakes while coding. Lack of simple coding practices, unit testing, debugging are some of the common reasons most issues get introduced at development stage.
4. Changing requirements
The customer may not understand the effects of changes, or may understand and request them anyway – redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of keeping track of changes may result in errors. Enthusiasm of engineering staff may be affected.
In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control.
5. Time pressures
Scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made. Unrealistic schedules though not common but major concern in small scale projects/companies results in software bugs. If there is not enough time for proper design, coding and testing, it’s quite obvious that defects will be introduced.
6. Egotistical or overconfident people
People prefer to say things like:
‘no problem’
‘piece of cake’
‘I can whip that out in a few hours’
‘it should be easy to update that old code’
instead of:
‘that adds a lot of complexity and we could end up making a lot of mistakes’
‘we have no idea if we can do that; we’ll wing it’
‘I can’t estimate how long it will take, until I take a close look at it’
‘we can’t figure out what that old spaghetti code did in the first place’
If there are too many unrealistic ‘no problem’s’, the result is software bugs.

7. Poorly documented code
It’s tough to maintain and modify code that is badly written or poorly documented; the result is software bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable code. In fact, it’s usually the opposite: they get points mostly for quickly turning out code, and there’s job security if nobody else can understand it (‘if it was hard to write, it should be hard to read’).
Any new programmer starting to work on this code may get confused due to complexity of the project and poorly documented code. Many times it takes longer to make small changes in poorly documented code as there is huge learning curve before making any code change.
8. Software development tools
Visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs. Continuously changing software tools used by software programmers. Keeping pace with the different versions and their compatibility is a major ongoing issue.
9. Obsolete automation scripts
Writing automation scripts takes lot of time especially for complex scenarios. If automation teams record/write any test script but forget to update it over the period of time that test could become obsolete. If the automation test is not validating the results properly it won’t be able to catch the defects.
10. Lack of skilled testers
Having skilled testers with domain knowledge is extremely important for success of any project. But appointing all experienced testers is not possible for all companies. Domain knowledge and the tester’s ability to find defects can produce high quality software. Compromise on any of this can result in buggy software.
Here are few more reasons for software bugs. These reasons are mostly applicable for software testing life cycle:  
11. Not having proper test setup (test environment) for testing all requirements
12. Starting to write code or test cases without understanding the requirements clearly.
13. Incorrect design which leads to issues being carried out in all phases of software development cycle.
14. Releasing software patches frequently without completing the software testing life cycle.
15. Not providing training to resources for the skills needed for developing or testing the application properly.
16. Giving very less or no time for regression testing.
17. Not automating repetitive test cases and depending on the testers for manual verification every time.
18. Not prioritizing test execution.
19. Not tracking the development and test execution progress continuously. Last minute changes are likely to introduce errors.
20. Wrong assumption made while coding and testing stages.

http://www.softwaretestinghelp.com/why-does-software-have-bugs/