Video - Testing in an Agile Environment by James Bach

A nice video about Testing in Agile Environment by James Bach.

Some key notes from the video:

Testers are like the headlights of a car.  Testers don't steer the product/project, they illuminate the status of the product to the different stakeholders

Some of the important things that a tester needs to do during a sprint planning phase

• Learn (Ask a lot of questions)
• Know about Testability
• Observability
• Controllability (control states, configurable)
• Simplicity - Some features can take longer to test than to develop - Alert the Dev and managers about this
• Going through spec and highlighting dodgy things

Other points:

• Testing directly on the developer machine (Shake n Bake) - a session for 90 minutes or lesser
• Try to test defects as soon as they are fixed, that's when the developers are still thinking about the defects.

To be aware of:

Automation - tendency to be biased towards automation, play with tools rather than testing

The art of debugging

In software, everyone faces issues almost daily.  We need to be highly equipped to solve those issues.  Not all problems are straightforward to find out and require a lot of debugging to be done.  Hence debugging skills is of prime importance.  I would like to reiterate that everything in software development is an art.  Similarly debugging is also an art.  In this post I will focus on how to debug a software problem.

• Understand the architecture
• The more the number of components in a system, the more complex it gets to solve an issue.  It is critical to understand the architecture of the software / the module in order to debug a problem.  Suppose your system has a client web browser and at the server side a web server and a database server.  What if this setup is required to be able to work through a VPN connection? And you get an error in your web server mentioning that you "Could not connect to the database server", where do you think the problem might be.  The problem might be anywhere.  Hence it is very important to understand the architecture if you want to solve the problem quickly.
• Analyze the entire picture
• Once you get the entire picture, analyze the entire picture and try to see where the symptoms are lying.  I refer symptoms here because whatever you see is only a symptom, we need to trace to the problem in order to solve it.
• From the symptom, try to trace the problem
• Many problems tend to have more than one symptom, look out for those and try to get those hints.  In our example, "Could not connect to the database" is a symptom.  The problem might be due to various reasons.