Moving onto a new location

Hi all,

I have not been an active blogger here for the past year.  This doesn't mean that I have run out of ideas, but I  am changing my approach.  No more lone wolf.  I will now collaborate with a team of technical testers working together to change the world of testing.

We will blog at http://thetechnicaltester.blogspot.com/ and we will tweet using hashtag #rubytest

Ruby Programming Challenge: Scrabble Utility

This is another in a series of Ruby programming challenges that we do to keep the tech skills strong on our test team.

This challenge starts with some existing code.  This script was written to find the longest word that can be written using only the letters in the top of keys on a keyboard.  The script opens a web site with Scrabble words and reads in all the words and then processes against an algorithm (BTW, the algorithm can be written more efficiently). 

Here is the challenge:  Based on the existing code, enhance it (or scrap it completely) so that it useful as a Scrabble utility.  1.  Given a list of characters (“ASFAGJS”, for example), determine the longest Scrabble word that can be created (Scrabble rules:  each character can be used only once). 2.   Also, given the same list of characters, determine what word scores highest (http://en.wikipedia.org/wiki/Scrabble_letter_distributions#English).

BTW, depending on how you run this script, there is an inefficiency that you may want to solve.  Each time the existing code runs, it goes to the internet to get the word list.  If your script runs for more than one set of characters, it would be efficient if you get the list of words only once.

While working on this challenge, I expect you will need to be comfortable with ruby arrays and hashes.  If the solution comes easy for you, feel free to enhance things further – be creative!

Here is the existing code:

require 'open-uri'
def restrict(html, starting_regexp, stopping_regexp)
 start = html.index(starting_regexp)
 stop = html.index(stopping_regexp, start)
 html[start...stop]
end
url = 'http://homepage.ntlworld.com/adam.bozon/Dictionary.htm'
page = open(url)
text = page.read; nil
words = restrict(text, /AA/, /ZYZZYVAS/)
array_words = words.split
@longest_word = ''
letters = ['Q', 'W', 'E', 'R', 'T', 'Y', 'U', 'I', 'O', 'P']
array_words.each do |word|
 @all_okay = true
 word.each_char.each do |character|            
   if (letters.include? character).to_s == 'false' then
     @all_okay = false
             break
   end
  end    
  if @all_okay then
    puts word
            if word.size > @longest_word.size then
              @longest_word = word
            end
  end
end
puts @longest_word

Cool Ruby Tools -- Sinatra and Web Applications

As I have written before, during the past year, our test team has been working with Ruby to grow our technical skills.  We have learned a lot and written a couple great testing utilities (Ruby Smalls - for small utilities).  We have published our Smalls as executables using the Ocra gem (a really slick packaging utility).  But there are times when deployed executables are not the best answer.  Recently, we have been looking at building our testing tools as web applications.  With Ruby, there is the grand daddy, Ruby on Rails, and there is the cool daddy, Sinatra.

Using Sinatra  (http://www.sinatrarb.com/), I  can build and run web-based applications that run Ruby code.  Sinatra enables me build pages and services with html and executable Ruby.  Sinatra is a good choice when you don't need the full framework and resources of a Rails project.  (Also, I have not learned Rails yet :))

After reviewing Sinatra with our architecture lead and a couple hours of playing, I can tell a couple things.  I have a lot to learn; I think it will be fun to learn; and there are cool possibilities.  For example, we could build a platform for our Ruby Smalls that anyone on our intranet could access and use, or we could use this as the basis of an automated test framework.

Time to get back to RubyMine and programming -- lots to do before work tomorrow.

No More Automated Test Engineers

As I reviewed several candidates’ resumes recently, something bothered me.  The open position is for an Automated Test Engineer for Agile Teams.  I am looking for an automated test engineer, but I find that I am bothered by the automated test engineer role.  After I thought about this for a while, I realized that I am still thinking about the “Whole-team” Test Automation post.  If everyone is an automator, then there is no need for an automator.

The common thing about the automation engineers I have met with and interviewed is that their current career path depends on the ignorance of their testing colleagues.

Even though it may seem to be disingenuous (I grew my career as an automation engineer), but I see no place for it anymore.  The presence of an automation engineer at a company is a sign of a problem.  In all likelihood, it means that a two-tiered system exists in the company’s test team.  In a proper agile test team, all members of the team have the skills of automated test engineers and are ready to use them whenever they are needed.

BTW:  I recruit for automation engineers because the industry has not caught up with us yet. I look forward to a day when the base expectations of a software tester include high levels of technical proficiency and mad testing skills.

Regular Expressions: A Tester’s Best Friend

Okay, I feel I am entitled to a bit of hyperbole, but I think regular expressions are great.  I like them for two reasons.  One is they are a programming language, and many programmers do not know regular expressions very well.  It is always great when the testing team has a technical advantage over the application developers.

The first reason is a bit lame.  The real reason I like regular expressions is that they enable you to have some much power in your automated tests while keeping the test framework very simple.

For those unfamiliar with regular expressions, regular expressions enable you to match patterns in strings of text using a simple syntax of reserved characters and patterns.  Regular expressions range from something simple like “Bob.*Jones” where “.*” is essentially a wildcard where matches include “Bob the wildman Jones” and “Bob Jones”  You can also make regular expressions to make sure that a value matches a date format or social security format or use a regular expression match an application validation message where the message changes in some predictable way when a test runs.

In our test framework, we use regular expressions for all automation components involved with verification.  For example, we use many “verify data” components.  In these components, you enter the expected value for a field in the application under test.  All our fields are regEx enabled, and typically this means that you enter an exact string value or a regular expression pattern to match in the test.  This means you have a very simple test with a lot of power.

Implementation note:  There was a point of the development of our automation framework, we had to make decisions about whether to use regular expressions and how to use them.  As much as it pains me to say, the biggest factor was whether the use of regular expressions would be too hard for testers.  Fortunately, we decided that testers are smart enough to handle regular expressions (and of course, they are!)

Let’s Write an Automated Test Framework

I am a huge one-time fan of HP’s BPT framework.  Test execution may be slow, but it is the best tool I have found for a growing test team to use in a whole-team test automation environment.  BPT has powerful abstraction of test scripts to make it easy for business-focused people and new test team members to build tests.  It enables automators to build tests using simple keyword-driven techniques and more powerful and sophisticated test scripts when the situation demands it.  As soon as I learned to ignore the misguided documentation from HP on how to use BPT, it became a very powerful tool.

Over the past year, I have been struggling with the new (and supposedly improved) version of QC/BPT.  The past year has been a mess.  What was a promising enterprise solution for long-term use has, in my mind, crumbled into a pile of what-could-have-been.  As it looks now, it is time to write an open-source automated test framework.

There are many others who have gone down this path.  Most have mixed results (we have looked for other frameworks that meet our needs and haven’t been satisfied with anything yet).  I am still convinced that BPT (as we implemented it) is the best test automation framework out there.  And since so few other people have found BPT (or found it to be a suitable solution for them), I think my team is uniquely (I am sure we are not alone) suited to drive the development of this project.  We have seen what works well.  We have solved the key problems of automation Fire Swamp -- Remember the movie the Princess Bride (1987) when Westley and Buttercup escaped from the Lightning Quicksand?

Westley: No, no. We have already succeeded. I mean, what are the three terrors of the Fire Swamp? One, the flame spurt - no problem. There's a popping sound preceding each; we can avoid that. Two, the lightning sand, which you were clever enough to discover what that looks like, so in the future we can avoid that too.

Of course, in the next moment, he learns about the Rodents of Unusual Size (ROUS) -- the third of the problems.

In the case of test automation, the three terrors are lack of readability, lack of maintainability, and lack of flexibility.  By using our implementation of BPT, we know what problems to avoid.

Look out HP, I think we might write a framework.

The Role of Reputation in Agile Testing

In Agile development teams, your reputation is more important than ever.

In traditional development teams, your peers certainly had opinions about you  They might love you or hate you or have no idea who you are.  The formal process of traditional development protected you, and it limited the impact that your reputation had on your professional work product.  For example, people from other groups may have approve test scripts you write.  Or you might execute test scripts written by someone else.  Your personal responsibility for your work was limited.  As long as you mechanically performed your tasks, you were covered.  

All that changes in agile.  In the most agile of shops, agile teams are self organizing, and the agile tester has a lot of discretion.  You are no longer protected by process. You can succeed or fail on your own.  

The roles on agile teams are not clearly defined in a traditional sense -- everyone should work together to complete the task, regardless of a person’s formal role.  Agile teams should be self organizing and figure out the best way to do things on their own.  What is best depends on a lot of things:  time, skills, interests, and trust.  Trust is based on reputation, and reputation is based on the sum of your past work.

At my company, we adhere strongly to the principles of agile, and development teams make a lot of their own decisions.  For example,  the amount of coding that happens during a sprint ultimately depends on the feeling of the team.  Of course, our teams are committed to delivering the most functionality they can each sprint, but the code has to be clean and the team has to have confidence in the work product.  

We deliver develop and deliver code in a two-week sprints.  In two weeks, there are only ten business days, and all our code is delivered into production at the end of the sprint.  Whether programmers feel comfortable creating new code for seven days or nine days during a sprint depends on things like testing confidence.  From the testing perspective, we need to provide good regression coverage (and share our results regularly with the team), and we must make everyone feel good about the sprint-level work we are doing.  It is, of course, essential to keep up to date with testing (immediate feedback), but the perception of success is greatly influenced by our reputation.  In this sense, a tester’s reputation has a real impact on the output of the development team.