Taking a Step With Ruby

Last month, I questioned what we on a test team would gain from learning Ruby and how we could apply it in our daily work.  We already use QuickTest Pro to automate much of our testing.  QTP is a powerful tool that allows us to interact with our applications and gives us a platform for VB script utilities.  With this, what can we expect from Ruby?

A few days ago, we took the first step as a team to see what there is to see.  We bought copies of Brian Marick’s “Everyday Scripting with Ruby for Team, Testers, and You.”

One of the things I like about Marick’s approach is that he stays away from GUI testing.  He mentions it and brings up WATIR, the web GUI automated testing framework for Ruby, but he focuses the book on smaller, very practical goals.  For example, instead of teaching how to automate a web page, he uses the example of building a utility to send text message to yourself when a long-running process completes.  He shows Ruby as a bionic arm for a tester, not a full-fledged robot tester.  From the perspective of learning (no one on our team has much experience with Ruby or similar object-orientated languages such as Python), this approach seems like a great idea.  It results in small projects that are easy to complete, practical to use, and valuable for building skills.

Our goal as a team is work through the book and exercises over the course of a few months.  This will be one of those voyages where we don't know exactly where we are going or when we will get there.  Wish us luck.

Give up the “Need” for Testing

We currently staff our development projects according to a standard ratio of programmers to testers – each project has a dedicated test resource who is expected to perform most or all of the testing.  With the prospect of rapid growth, we may not be able to keep our same ratios, and testing may be stressed.  While thinking about this challenge, I played with the idea changing our test model so that testing is built around a core test team, not around a required ratio on each project team.

Doing this would require the test team to give some things up.  For example, we would have to give up the notion of testing or QA being an independent verification entity.  This concept is a left over from traditional, waterfall development.  In agile, teams hold to a “whole team” philosophy where all members of a team work together to complete a job, no matter their formal roles.  Testing does not always have to be done by testers.  And testers may take on other roles, such as requirements analysis.

You would also have to give up the notion of the guaranteed need for a test resource.  This is an uncomfortable spot to put yourself in, but it is probably helpful to consider yourself expendable from time to time. It can be a great motivator to prove your value.

So, when you give up the “need” for testing resources, what do you have left?  You have to sell yourself and your team on your own merits.

What should the role of the test team be?  Simply, you should do what you do best: 

 ·  Develop, execute, and analyze regression tests.  In a continuous integration environment, good regression tests and great analysis are an essential safety net and the best way to provide immediate feedback on quality.

 ·  Develop test tools and find the most efficient ways to solve testing problems.

 ·  Provide insight into test analysis and help teams find weak spots in their code.

 ·  Ask questions.  Good testers are great question askers.  Keep asking these questions; they are one of the best tools to building quality into products.

 ·  Be a trusted advisor and provide trusted assessments. 

 ·  Finally, know your craft really, really well -- this cannot be understated.  If testing resources are not “needed,” they will be used only when they are respected and valued.

This is one of those times when you have to give up something in order to gain it.  Give up the guaranteed need for testing and give up the limits of conventional testing.  It is an existential leap with some risk, but the potential reward is a lean, efficient test team.