tag:blogger.com,1999:blog-51238740459421522102024-02-08T13:26:32.807-05:00Leading Software Testing in an Agile WorldAgile development means more than scrum meetings, and agile testing is not mini waterfall. This is the story of my search for the best approaches to software testing in an agile world.Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-5123874045942152210.post-66653755516174812842013-01-04T20:10:00.000-05:002013-01-04T20:10:48.300-05:00Moving onto a new locationHi all,<br />
<br />
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. <br />
<br />
We will blog at <a href="http://thetechnicaltester.blogspot.com/">http://thetechnicaltester.blogspot.com/</a> and we will tweet using hashtag #rubytestBob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com1tag:blogger.com,1999:blog-5123874045942152210.post-61816651774980766112012-02-28T20:09:00.001-05:002012-02-28T20:09:28.184-05:00Ruby Programming Challenge: Scrabble Utility<br />
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
This is another in a series of Ruby programming challenges that we do to keep the tech skills strong on our test team.</div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
<br /></div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
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). </div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
<br /></div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
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 (<a href="https://webmailksq.chathamfinancial.com/owa/redir.aspx?C=9f96999a8add4a1fa3f41b4a273edb20&URL=http%3a%2f%2fen.wikipedia.org%2fwiki%2fScrabble_letter_distributions%23English" target="_blank">http://en.wikipedia.org/wiki/Scrabble_letter_distributions#English</a>).</div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
<br /></div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
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.</div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
<br /></div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
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!</div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
<br /></div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
Here is the existing code:</div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
<br /></div>
<div class="x_MsoNormal" style="font-family: Calibri, sans-serif; font-size: 11pt; margin-bottom: 0.0001pt; margin-left: 0in; margin-right: 0in; margin-top: 0in;">
<span style="font-family: Arial, sans-serif; font-size: 11.5pt;">require 'open-uri'</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">def restrict(html, starting_regexp, stopping_regexp)</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> start = html.index(starting_regexp)</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> stop = html.index(stopping_regexp, start)</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> html[start...stop]</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">end</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">url = 'http://homepage.ntlworld.com/adam.bozon/Dictionary.htm'</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">page = open(url)</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">text = page.read; nil</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">words = restrict(text, /AA/, /ZYZZYVAS/)</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">array_words = words.split</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">@longest_word = ''</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">letters = ['Q', 'W', 'E', 'R', 'T', 'Y', 'U', 'I', 'O', 'P']</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">array_words.each do |word|</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> @all_okay = true</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> word.each_char.each do |character|<span class="x_apple-tab-span"> </span></span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> if (letters.include? character).to_s == 'false' then</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> @all_okay = false</span><span style="font-size: 13.5pt;"><br /></span><span class="x_apple-tab-span"><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> </span></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> break</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> end</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> end<span class="x_apple-tab-span"> </span></span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> if @all_okay then</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> puts word</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> <span class="x_apple-tab-span"> </span>if word.size > @longest_word.size then</span><span style="font-size: 13.5pt;"><br /></span><span class="x_apple-tab-span"><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> </span></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> @longest_word = word</span><span style="font-size: 13.5pt;"><br /></span><span class="x_apple-tab-span"><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> </span></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">end</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;"> end</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">end</span><span style="font-size: 13.5pt;"><br /></span><span style="font-family: Arial, sans-serif; font-size: 11.5pt;">puts @longest_word</span></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com3tag:blogger.com,1999:blog-5123874045942152210.post-84760554205867092652012-02-21T20:55:00.000-05:002012-02-21T20:55:25.404-05:00Cool Ruby Tools -- Sinatra and Web Applications<br />
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.<br />
<br />
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 :))<br />
<br />
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.<br />
<br />
Time to get back to RubyMine and programming -- lots to do before work tomorrow.<br />Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0tag:blogger.com,1999:blog-5123874045942152210.post-67301286079448776032012-01-19T09:00:00.000-05:002012-01-19T09:00:04.252-05:00No More Automated Test Engineers<br />
<div>
<b id="internal-source-marker_0.8659588764421642"><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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 <a href="http://leadingsoftwaretestinginanagileworld.blogspot.com/2011/11/whole-team-test-automation.html">“Whole-team” Test Automation post</a>. If everyone is an automator, then there is no need for an automator.</span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">BTW:</span><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> 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 </span><span style="font-family: Arial; font-size: 15px; font-style: italic; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">and </span><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">mad testing skills.</span></b></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com5tag:blogger.com,1999:blog-5123874045942152210.post-23262844138764704162012-01-15T19:13:00.000-05:002012-01-15T19:13:41.278-05:00Regular Expressions: A Tester’s Best Friend<br />
<div>
<b id="internal-source-marker_0.8659588764421642"><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Implementation note: </span><span style="font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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!)</span></b></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0tag:blogger.com,1999:blog-5123874045942152210.post-57463231713519098692011-12-20T21:14:00.001-05:002011-12-20T21:14:47.332-05:00Let’s Write an Automated Test Framework<br />
<div style="background-color: transparent;">
<span id="internal-source-marker_0.7674553506076336"><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="background-color: transparent; background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="background-color: transparent; background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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?</span><br /><span style="background-color: transparent; background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><i style="font-weight: bold;"><a href="http://www.imdb.com/name/nm0000144/"><span style="background-color: white; color: #136cb2; font-family: Arial; font-size: 13px; vertical-align: baseline; white-space: pre-wrap;">Westley</span></a><span style="background-color: white; color: #333333; font-family: Arial; font-size: 13px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">: 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. </span></i><span style="background-color: transparent; background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><div style="background-color: transparent;">
<b id="internal-source-marker_0.7674553506076336"><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Of course, in the next moment, he learns about the Rodents of Unusual Size (ROUS) -- the third of the problems.</span></b></div>
<span style="background-color: transparent; background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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. </span><br /><span style="background-color: transparent; background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Look out HP, I think we might write a framework.</span></span></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com5tag:blogger.com,1999:blog-5123874045942152210.post-20904124815481209022011-12-04T17:22:00.001-05:002011-12-04T17:23:46.436-05:00The Role of Reputation in Agile Testing<br />
<div style="background-color: transparent;">
<span id="internal-source-marker_0.06390465376898646" style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">In Agile development teams, your reputation is more important than ever.</span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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. </span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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. </span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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.</span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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. </span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">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. </span></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com3tag:blogger.com,1999:blog-5123874045942152210.post-10268306548508471842011-11-27T22:15:00.001-05:002011-11-27T22:17:30.868-05:00Test Automation and the Art of Poetry<br />
<div style="background-color: transparent;">
<span id="internal-source-marker_0.40124757518060505" style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">You never know where life will take you. In college, I studied literature – and mostly stayed away from the math/computer science buildings on campus. For some reason, I was interested in the early English Renaissance and Sir Philip Sidney. In one of Sidney’s works, </span><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: italic; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">A Defence of Poesie</span><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> (also known as </span><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: italic; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">The Defence of Poetry</span><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: italic; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">and An Apology for Poetry</span><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">) , he writes about the purpose of poetry and his interpretation of art.</span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">College was a long time ago, and I don’t remember a lot of my study of Sidney. One thing I do remember is that Sidney wrote that </span><span style="background-color: transparent; font-family: Arial; font-size: 15px; font-weight: bold; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">the finest art hides its art</span><span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">. The best art or poetry looks easy. The finest art, the art that takes the greatest talent and the hardest work, looks simple when done well. I like to think about this when I think about test automation.</span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">A good test automation framework should look simple. In fact, it should look stupid simple. It should be something that you can explain to someone without a lot of big words or long manuals. It should be easy to read without having to think too hard. </span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">With this as a guiding principle, I think a good automation program should rely on abstraction. You can present complex ideas by breaking the ideas into simple, generalized parts. The simpler parts are often easy to describe so that people can understand them. Good test automation should be abstracted to the business level. By abstracting to the business level, you increase readability and open your work to others. You don’t have to be specialist to understand what is going on -- just the same as you shouldn’t need to be a PhD literary critic to appreciate good poetry.</span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">You may have some clever code and some complex code, but when it is implemented, it should look simple. In an automation framework, the implementation should look simple. In the actual code libraries that support your framework, the code should look simple. If not, refactor. We expect the application developers to do this with their code; we should do the same.</span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><br />
<span style="background-color: transparent; font-family: Arial; font-size: 15px; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">If it looks complex, it is probably either or bad automation or bad poetry. The next time you are looking for a case for simplicity, look no further than Sir Philip Sidney. Simplify, simplify, simplify!</span></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com1tag:blogger.com,1999:blog-5123874045942152210.post-39003023785332584722011-11-16T22:08:00.001-05:002011-11-16T22:10:16.792-05:00Great Day for Ruby Programming (and Our Test Team)<br />
While reviewing some Ruby blogs and forums, I found<br />
<br />
<a href="http://www.beginnerruby.com/ruby-executables/package-ruby-scripts-as-executables-with-ocra/">http://www.beginnerruby.com/ruby-executables/package-ruby-scripts-as-executables-with-ocra/</a><br />
<br />
This information on the ocra Ruby gem is breathing new life into our scripting program. Using Ocra, we can package our Ruby scripts into executables that we can distribute easily. Ocra creates .exe files that include references to all the related files and Ruby gems used in a script. These executables can be run on machines without worrying about any dependencies -- you don't even need to install ruby on a machine. This is one of the most liberating things I have seen in a while.<br />
<br />
Since we started with our Ruby study on the test team, we have developed utilities ranging from a services testing framework to a utility for updating expected results for automated tests to another utility for releasing locks in our QC/QPT tests. These utilities are great, but they suffered because it is a bother to install ruby, all the associated gems, and referenced files on each machine. Because it is a bother (we are sort of lazy), we often didn't do it, and the great work we did gathered dust.<br />
<br />
Using Ocra today, we created executables, and this great work from the past year came back to life. After we verified that this gem works (thanks Josh), it is hard not to get excited about the possibilities. We developed libraries in our bigger projects (the services test framework, most noteably) that we have referenced in other projects. Now, I am thinking of other places we can use these resources. <br />
<br />
It is all coming together. The test team with the biggest tool kit wins. Death to boring work.<br />Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com3tag:blogger.com,1999:blog-5123874045942152210.post-34295267134794980382011-11-10T21:01:00.000-05:002011-11-16T20:24:05.339-05:00“Whole-team” Test AutomationAt my company, we practice the art of “whole-team test automation.” Very simply, this means that test automation is not a specialized skill on our test team. For us, the ability to develop automated tests is a required skill for all members of our test team. At our company, highly skilled automated test engineers are common as dirt.<br />
<br />
If you thinking that this seems like a lot of work, you are right. It takes an effort. So, why would we invest in this idea?<br />
<ul>
<li>In agile development, rapid development of automated tests is critical. While we still struggle with keeping up with automation during sprint work, the option is always there for the testers and the scrum teams to do what is best for the project. This may mean aggressively developing regression tests throughout the project. It is not acceptable for one project to have good coverage just because they happen to have the good automator – all projects deserve technically skilled testers.</li>
<li>At many companies, automated tests are developed, executed, and owned by a separate group within the test team. This creates a two-tiered test team. It creates a situation where the most technical members become more technical because they have the most practice and the least technical members have no opportunities to grow their skills. That sucks if you not technical and have no opportunity to grow.</li>
<li>The more technical a tester is, the more tools the tester has in his toolkit, and the better the tester will adapt to new situations. The new and changing situations range from new technologies such as services testing to a fundamental change in how software testing is done. Adapt or die.</li>
<li>Agile testers are developers. As members of a software development team, everyone should know how to code. It is good for your self esteem, and it helps you gain and keep the respect of the other developers on your team.</li>
</ul>
If you are convinced that we are on to something, how do you go about it?<br />
<ul>
<li>Build or select a suitable test framework and implementation methodology, and develop a transparent approach to testing. For this, we chose HP’s BPT framework with QTP as the underlying automation engine. Using BPT and our “Archetype” implementation technique, all members work together and take advantage previous work and each other’s skills. With a good framework, new team members can build tests, and experienced automators have opportunities to work on challenging work.</li>
<li>Good recruiting. <a href="http://leadingsoftwaretestinginanagileworld.blogspot.com/2010/10/testers-need-not-apply.html">Regular, run-of-the-mill “QAs” are not right people for the team</a>. Be prepared for this to take a long time. Because of the history of testing (a combination of “QA” process types and non-technical manual script runners), many good people stay away from testing jobs. My only advice here is to start with high standards, don’t let your standards drop, and keep hope. Great people are out there. And in my opinion, most recruiters will not be your friend. They will pressure you to take conventional candidates. Be aware of recruiters.</li>
<li>Be prepared to train people . Some of the most obviously experienced candidates will take the most time. Many experienced automators do not work in a whole-team automation environment. As a result, they tend to build tests for themselves and not for the team. There is often “unlearning” that has to happen. </li>
<li>Promote technical skills. <a href="http://leadingsoftwaretestinginanagileworld.blogspot.com/2010/11/learning-ruby-or-python-what-does-that.html">Learn new programming languages</a> and new technologies. This year when we studied Ruby together, we spent some time looking at Rails projects. By looking at and studying Rails, we accidentally learned about MVC frameworks. </li>
<li>Devote enough time. In addition to the sprint work that we do (with or without other testers), <a href="http://leadingsoftwaretestinginanagileworld.blogspot.com/2010/10/magic-of-automation-hour.html">we devote an hour each day to work together on automation</a>. This way, we share ideas, learn from each other, set high expectations for each other, and continue to practice our art. There is a bonus with this approach when you are working on projects that are not interesting. If your project stinks, you can work with other team members on their automation needs. Everyone wins.</li>
</ul>
As you live with the “whole-team” automated test philosophy, be prepared for things you do not predict. Train your team, give them the tools and support, give up control, and let them surprise you.Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com3tag:blogger.com,1999:blog-5123874045942152210.post-32997264746169547362011-11-08T09:31:00.002-05:002011-11-16T20:38:28.244-05:00Programming Challenges for the Test Team<span class="Apple-style-span" style="background-color: white;">This is a follow up to a earlier post on <a href="http://leadingsoftwaretestinginanagileworld.blogspot.com/2010/12/taking-step-with-ruby.html">Ruby programming</a>. This is part of the continuing effort to raise the technical bar on the test team (and to keep it high). Here is the latest Ruby Challenge:</span><br />
<span class="Apple-style-span" style="background-color: white;"><br />
</span><br />
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;">A farmer has a 40-pound rock that he uses with a balance-type scale to measure grains and feed. He lends that rock to a neighbor, and the neighbor accidently breaks the rock. It is broken into four pieces. He returns the rocks to the farmer and is very apologetic. The farmer, unexpectedly, is pleased. He says with these four pieces of rock and the balance-scale that he can now measure everything from 1 to 40 pounds. What is the weight of each rock?<o:p></o:p></span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;"><br />
</span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;">I know that some of the team know the answer (or at least remember the riddle). But the answer doesn’t really matter. Here is the challenge: Using Ruby (or some other programming language), write a script that tests your guess. <o:p></o:p></span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;"><br />
</span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;">As a bonus, write an algorithm that derives all the possible combinations of stone weights.<o:p></o:p></span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;"><br />
</span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;">Bonus points for elegant code.<o:p></o:p></span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;"><br />
</span></div>
<div class="MsoNormal" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial initial; background-repeat: initial initial;">
<span class="Apple-style-span" style="background-color: white;">Bragger’s rights for the first good script. </span><span class="Apple-style-span" style="background-color: white;"><o:p></o:p></span></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com1tag:blogger.com,1999:blog-5123874045942152210.post-4559561875906303302011-09-21T10:30:00.000-04:002011-09-21T10:30:48.660-04:00Migration from BPT 10 to 11: Changes to Data Tables<div class="MsoNormal">In standard QTP, data tables are the work horses for managing test data.<span> </span>They are used for data driving tests, passing data from one action to another, storing large volumes of test results, and for iterating tests.<span> </span>In BPT, data tables take a back seat to other means of managing test data, most notably, test parameter data.<span> </span>But even in BPT, there is a place for data tables.<span> </span>For example, test data read from associated Excel files can be read in at run time and table data from the application under test can be stored in the component data table and reviewed in the test logs.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In BPT 10, each component has a local datasheet.<span> </span>Because each component runs independently (remember the slow execution speed of BPT 10 – one component is loaded, it runs, the component is closed, the next component is loaded, it runs, …), there is no global data sheet. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">There is a key benefit in BPT 10 to the way tests are constructed.<span> </span>In a component, you can create data tables named “Actual” and “Expected.”<span> </span>If this component is used more than once in a test, you don’t have to worry about name contention – the scope of data table names is in a single instance of a component.<span> </span>In standard QTP, all data tables are exposed to the entire test and you have to make sure that no data tables share the same name. In BPT 11, tests share much more in common with standard QTP tests, and data tables must now be unique.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In my migration from BPT 10 to 11, I had to rethink some of my key assumptions about how I use data tables.</div><div class="MsoNormal"><br />
</div><ol start="1" style="margin-top: 0in;" type="1"><li class="MsoNormal">Because of the appearance of the global data sheet in the business component, I changed from using the DataTable.Import method to DataTable.ImportSheet.<span> </span>The Import method loads the Excel sheet into the first data table. In BPT 10, the first data table is a local sheet; in BPT 11, the first data table is the global sheet.<span> </span></li>
</ol><div class="MsoNormal" style="margin-left: .25in;"><br />
</div><div class="MsoNormal" style="margin-left: .5in;">A surprise change for me when I ran my components migrated from 10 in 11 is that the imported data was not where I expected it to be.<span> </span>This caused verifications to fail.<span> </span>I was further surprised when some of my tests ran extra iterations.<span> </span>Tests ran extra iterations because the import method added rows to the global datasheet, and the global datasheet determines the number of iterations a test runs.</div><div class="MsoNormal" style="margin-left: .5in;"><br />
</div><div class="MsoNormal" style="margin-left: .5in;">ImportSheet enables you to specify which sheet to import and where to place it.<span> </span>When using ImportSheet, you have to know the name of the data sheet you want to overwrite – if your test iterates, this must be a unique name.</div><div class="MsoNormal" style="margin-left: .25in;"><br />
</div><ol start="2" style="margin-top: 0in;" type="1"><li class="MsoNormal">Because the scope of data sheet names is not longer local to business components, you must manage the names of the sheets and make sure the names are unique.<span> </span>As you do this, consider analysis of test results.<span> </span>If your test has 10 iterations, there may be 10 instances of the “Expected_Result” sheet.<span> </span>Getting the iteration value of component at run time is difficult so I chose to make the sheets unique by adding part of a time stamp to the name.<span> </span>Ten instances of a sheet with similar names is difficult to analyze.<span> </span>To give clarity, I added a line to the log file identifying which data sheet goes with which iteration.</li>
</ol><div class="MsoNormal"><br />
</div><div class="MsoNormal">Here is a summary of the changes I made:</div><div class="MsoNormal">BPT 10:</div><div class="MsoNormal"><span style="font-family: Courier; font-size: 11.0pt;">DataTable.Import GetCurrentTestPath() & "\" & strQCExcelSheet<o:p></o:p></span></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">BPT 11:</div><div class="MsoNormal"><span style="font-family: Courier; font-size: 11.0pt;">strUniqueSheetName = “Reference_” & Minute(Now) & Second(Now)<o:p></o:p></span></div><div class="MsoNormal"><span style="font-family: Courier; font-size: 11.0pt;">Reporter.ReportEvent micDone, strUniqueSheetName, “Look for reference data at “ & strUniqueSheetName<o:p></o:p></span></div><div class="MsoNormal"><span style="font-family: Courier; font-size: 11.0pt;">DataTable.AddSheets(strUniqueSheetName)<o:p></o:p></span></div><div class="MsoNormal"><span style="font-family: Courier; font-size: 11.0pt;">DataTable.ImportSheet GetCurrentTestPath() & "\" & strQCExcelSheet, 1, strUniqueSheetName<o:p></o:p></span></div><div class="MsoNormal"><span> </span></div><div class="MsoNormal">Generally, the migration from BPT 10 to 11 did not require changes to the automation code.<span> </span>Underlying BPT is QTP, and QTP code did not change.<span> </span>The change in how BPT handles data tables may be unnoticed in many implementations, depending on which features of BPT are used.<span> </span>For those who push the limits of how BPT handles data, this undocumented change to data tables will be a stumbling block.<span> </span>I suppose there is a price to pay to get BPT to perform at an acceptable speed.<span> </span>I’ll pay this one.</div><div class="MsoNormal"><br />
</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com1tag:blogger.com,1999:blog-5123874045942152210.post-21907497561948809382011-04-13T18:05:00.000-04:002011-11-16T20:24:46.593-05:00Checklist for Agile TestingDuring a recent test team discussion, we reviewed the key features of agile software testing. As a team, we all have a good idea of what is important with agile testing and how it is different from conventional testing. We worked on the checklist to give us a tool for keeping our agile test mindset fresh. <br />
<br />
Use the checklist to question your own agile test performance. It is good for a self examination or a discussion with your project team. For example, you can use it to share your vision of agile testing with a team that is new to agile development.<br />
<br />
For most of the questions, "yes" is the best answer. It is doubtful that you will answer "yes" (or whatever the best answer is ) for all the questions -- use the questions and answers to provoke thought.<br />
<div align="center" class="MsoNormal" style="text-align: center;">
<br /></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;">Leadership<o:p></o:p></b></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l1 level1 lfo1; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Am I taking items off the mental shelf space for the lead programmer, scrum master, and/or business user?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l1 level1 lfo1; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Am I the scrum master for the project? If not, could or should I have been?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l1 level1 lfo1; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I help the scrum team understand risks?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l1 level1 lfo1; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Do I organize work for the project?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l1 level1 lfo1; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Have I made decisions in the best interest of the project? Did I give up ownership and did I take on ownership of right things to make the project successful?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l1 level1 lfo1; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I help new team members learn the project?</div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;">Analysis<o:p></o:p></b></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l2 level1 lfo2; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Am I documenting the project, opening tickets and describing requirements?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l2 level1 lfo2; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Am I writing user stories?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l2 level1 lfo2; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I come up with any of the requirements for the project? <i>This is an indication that you are actively participating in the project.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l2 level1 lfo2; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I define and/or develop tests at the beginning of the sprint? <i>Early work is good work.</i></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;">Collaboration<o:p></o:p></b></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l3 level1 lfo3; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Are other members of the scrum team helping with testing? <i>In agile, any member of the team should be able to test.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l3 level1 lfo3; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Do I feel like I am up to date with programmers and business users throughout the sprint? <i>A catch-up period later in the sprint is a bad sign.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l3 level1 lfo3; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>During meetings, do I write on the white board? <i>This is an indication that you are actively thinking, communicating, and participating in the project.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l3 level1 lfo3; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Have I sat with a programmer while he or she wrote code for the project?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l3 level1 lfo3; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Have I sat with the business users? </div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l3 level1 lfo3; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Have I tested on the programmer’s workstation recently? <i>This is key to providing really immediate feedback.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l3 level1 lfo3; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Is there a lot of scrum team chatter? <i>Teams that talk to each other are more agile than those that don’t.</i></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;">Testing<o:p></o:p></b></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Am I giving really fast feedback to programmers on the most important things?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Am I known as “Fast Feedback [your name]” or “Quick Test [your name]?”</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Are the programmers comfortable coding for the full sprint? <i>Good agile testing can directly increase the productivity of the programmers.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I add value as a testing expert? For example, did I help business users perform good test analysis?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I build any tools to help verify the project?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I update existing automated tests that changed because of my project work?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did I use the simplest solutions for the problems I worked on?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Did we get user acceptance feedback very early and very often in the sprint?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Have I built regression tests for new functionality before or while it is being built?</div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>How long are issues sitting with me before I turn them around? <i>Issues should sit no longer than a day or two.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>How old are the bugs we are finding on the project? <i>The only good bug is a dead bug, and the best dead bug is one that didn't live long.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Is a lot of testing taking place at the end of the sprint? <i>Best answer is "very little." Make an effort to test early and regularly throughout the sprint. If you are testing a lot at the end, you are probably not being very agile.</i></div>
<div class="MsoNormal" style="margin-left: .25in; mso-list: l0 level1 lfo4; tab-stops: list .25in; text-indent: -.25in;">
<span style="font-family: 'Courier New';">o<span style="font: normal normal normal 7pt/normal 'Times New Roman';"> </span></span>Was more than one person involved in user acceptance sessions? Do the users I worked with represent the user community well?</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com2tag:blogger.com,1999:blog-5123874045942152210.post-67925041120251180992011-03-02T21:00:00.001-05:002011-03-03T20:06:40.943-05:00Distributed Agile Test Teams -- Making It WorkI just returned from a trip to Krakow, Poland where I visited with members of my test team. Our test team is split between two offices. In one office, we have programmers and testers, and in the other office, we have testers and no programmers. Because of this, it is not possible for all the scrum teams to be colocated. This creates some challenges, but so far, everything has been a solveable problem. In some ways, using distributed agile test teams is not idea, and in other ways, it is a big strategic advantage. <br />
<br />
Here are some things we do to make distributed agile testing work:<br />
<ul><li>Make the best use of the overlap hours. In our case, we have at least three overlap hours between Poland and the eastern US. These hours are precious. During this time, we have stand-up scrum meetings and we work on test team projects. </li>
<li>Invest in the right tools. This means buying or building tools that enable everyone on all teams to have the same advantages. For example, we migrated to Quality Center when we opened the Poland office. QC is just about as responsive in Poland as it is in the US.</li>
<li>Communicate! We use video conferencing, collaboration software, and instant messaging everyday. Cheap tools can erase the miles and bring your teams together. We have started using Adobe Connect for video conference and collaboration. One cool feature of this is the ability to record meetings. This gives the abilty for programmers to pass along a quick recorded demo of the day's work to the tester on the other side. User acceptance test sessions can be recorded -- in fact, a UAT performed during off hours can be reviewed later in another office.</li>
<li>Travel between sites. New hires in our Poland office spend several months in the US working the development and testing teams. A big success factor is building strong relationships. It is difficult to really get to know and to trust someone if you only talk on the phone or communicate through email. The benefits to people traveling and to the people being visited outweight the costs of traveling.</li>
<li>Find the right projects. Regression test analysis and many test automation-related projects are easily done in Poland. Most new functionality projects are more easily done in the other office where there is better access to programmers and business users. </li>
<li>Hire the right people. This is always important, but it is really important when you have to rely on trust and communication with people that you don't see on a regular basis.</li>
</ul><br />
<br />
What I have found so far is that the issues related to distributed agile testing are common with distributed agile development. If you are looking for more information on distributed agile development, here is a great resource:<br />
<span class="Apple-style-span" style="color: #0000ee;"><u><a href="http://download.microsoft.com/download/4/4/a/44a2cebd-63fb-4379-898d-9cf24822c6cc/distributed_agile_development_at_microsoft_patterns_and_practices.pdf">http://download.microsoft.com/download/4/4/a/44a2cebd-63fb-4379-898d-9cf24822c6cc/distributed_agile_development_at_microsoft_patterns_and_practices.pdf</a></u></span>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0tag:blogger.com,1999:blog-5123874045942152210.post-77128191442788565242010-12-20T14:01:00.000-05:002010-12-20T14:01:23.140-05:00Taking a Step With Ruby<div class="MsoNormal"><a href="http://leadingsoftwaretestinginanagileworld.blogspot.com/2010/11/learning-ruby-or-python-what-does-that.html">Last month</a>, I questioned what we on a test team would gain from learning Ruby and how we could apply it in our daily work.<span style="mso-spacerun: yes;"> </span>We already use QuickTest Pro to automate much of our testing.<span style="mso-spacerun: yes;"> </span>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?</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">A few days ago, we took the first step as a team to see what there is to see.<span style="mso-spacerun: yes;"> </span>We bought copies of Brian Marick’s “Everyday Scripting with Ruby for Team, Testers, and You.”</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">One of the things I like about Marick’s approach is that he stays away from GUI testing.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>He shows Ruby as a bionic arm for a tester, not a full-fledged robot tester.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>It results in small projects that are easy to complete, practical to use, and valuable for building skills.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Our goal as a team is work through the book and exercises over the course of a few months.<span style="mso-spacerun: yes;"> This will be one of those voyages where we don't know exactly where we are going or when we will get there. </span>Wish us luck.</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0tag:blogger.com,1999:blog-5123874045942152210.post-51769823216334314712010-12-01T19:38:00.001-05:002010-12-02T20:33:45.883-05:00Give up the “Need” for Testing<div class="MsoNormal">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.<span style="mso-spacerun: yes;"> </span>With the prospect of rapid growth, we may not be able to keep our same ratios, and testing may be stressed.<span style="mso-spacerun: yes;"> </span>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.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Doing this would require the test team to give some things up.<span style="mso-spacerun: yes;"> </span>For example, we would have to give up the notion of testing or QA being an independent verification entity.<span style="mso-spacerun: yes;"> </span>This concept is a left over from traditional, waterfall development.<span style="mso-spacerun: yes;"> </span>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.<span style="mso-spacerun: yes;"> </span>Testing does not always have to be done by testers.<span style="mso-spacerun: yes;"> </span>And testers may take on other roles, such as requirements analysis.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">You would also have to give up the notion of the guaranteed need for a test resource.<span style="mso-spacerun: yes;"> </span>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.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">So, when you give up the “need” for testing resources, what do you have left?<span style="mso-spacerun: yes;"> </span>You have to sell yourself and your team on your own merits.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">What should the role of the test team be?<span style="mso-spacerun: yes;"> </span>Simply, you should do what you do best:<span style="mso-spacerun: yes;"> </span></div><div class="MsoNormal"><br />
</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;"><span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;"><span style="font-family: Times New Roman;"> </span>·<span style="font-family: "Times New Roman";"> </span></span></span>Develop, execute, and analyze regression tests.<span style="mso-spacerun: yes;"> </span>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.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;"> <span style="font-family: Symbol;">·</span><span style="font-family: "Times New Roman";"> </span>Develop test tools and find the most efficient ways to solve testing problems.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;"> <span style="font-family: Symbol;">·</span><span style="font-family: "Times New Roman";"> </span>Provide insight into test analysis and help teams find weak spots in their code.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;"> <span style="font-family: Symbol;">·</span><span style="font-family: "Times New Roman";"> </span>Ask questions.<span style="mso-spacerun: yes;"> </span>Good testers are great question askers.<span style="mso-spacerun: yes;"> </span>Keep asking these questions; they are one of the best tools to building quality into products.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;"> <span style="font-family: Symbol;">·</span><span style="font-family: "Times New Roman";"> </span>Be a trusted advisor and provide trusted assessments.<span style="mso-spacerun: yes;"> </span></div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;"> <span style="font-family: Symbol;">·</span><span style="font-family: "Times New Roman";"> </span>Finally, know your craft really, really well -- this cannot be understated.<span style="mso-spacerun: yes;"> </span>If testing resources are not “needed,” they will be used only when they are respected and valued.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">This is one of those times when you have to give up something in order to gain it.<span style="mso-spacerun: yes;"> </span>Give up the guaranteed need for testing and give up the limits of conventional testing.<span style="mso-spacerun: yes;"> </span>It is an existential leap with some risk, but the potential reward is a lean, efficient test team.</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com1tag:blogger.com,1999:blog-5123874045942152210.post-19633808182662691152010-11-11T16:53:00.004-05:002010-12-03T08:09:39.170-05:00Learning Ruby (or Python), What Does That Get Us?<div class="MsoNormal">In a recent team meeting, we discussed ways to increase our technological capacity. Currently, we have a fairly technical test team. Many of us are very good (or getting very good) at VB script, we have passable SQL skills, and possess a variety of backgrounds that include technical training and programming. As far as most test teams go, we are very technical, and we have the interest to take it further. The question is “where?”</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">One idea that came up was for us to learn another scripting language, such as Ruby or Python. The next thought, though, was what do we do with that knowledge? Hmm. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Using a scripting language with a testing library such as WATIR or Selenium, we can interact with web objects. Having the ability to interact with web objects and script test logic is a powerful thing. With this, you can write many utilities to assist with testing. These utilities do not have to be full-fledged, stand alone automation tools, but they are great levers for hybrid testing, tool-assisted manual testing.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">But we have QTP (and presently, enough licenses). So what would Ruby or Python get us that we don’t already have? Here a couple thoughts in no particular order:</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;">* Technical prestige. VB Script is a great tool, but it doesn’t get as much respect as other languages. Jerks.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;">* License extender. If you use Ruby or Python for day-to-day tasks, you do not tie up expensive QTP licenses.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;">* Professional growth. Learning and using open-source tools enables you to evaluate different tools and to participate in more industry discussions.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;">* An open mind. Learning how to perform a task using different tools opens you to different approaches to other things.</div><div class="MsoNormal" style="margin-left: 0.15in; mso-list: l0 level1 lfo1; tab-stops: list .05in; text-indent: -0.15in;">* Interaction with the open-source community. Becoming proficient with these tools may give you an opportunity to give back.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Now, we need to find the time to learn Ruby (or Python)</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0tag:blogger.com,1999:blog-5123874045942152210.post-78270890621491125512010-10-28T16:00:00.000-04:002010-10-28T16:00:07.842-04:00Am I Agile or Mini Waterfall? Do I care?<div class="MsoNormal">After our development team migrated to agile, we assumed that we are an agile test team.<span style="mso-spacerun: yes;"> </span>After some time and belly button staring, we came to the conclusion that we were a mini-waterfall test team and not very agile.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">We tested and delivered code every four weeks, and we went to scrum meetings.<span style="mso-spacerun: yes;"> </span>It looked agile, but our mini waterfall approach was very traditional.<span style="mso-spacerun: yes;"> </span>Programmers and product owners designed and implemented the product enhancements, and testers stood against the wall waiting for code to test at the end of the sprint.<span style="mso-spacerun: yes;"> </span>We were second-class members of the development team.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">The move to agile testing started by dealing with the denial that we were not already there and by trying to articulate what exactly agile testing is.<span style="mso-spacerun: yes;"> </span>While not everything changed (we still analyze and test software), we changed our testing philosophy.<span style="mso-spacerun: yes;"> </span>We found ways to change our role from tester to “developer.”<span style="mso-spacerun: yes;"> </span>We took steps to own the early days of a sprint be taking on more of a business analyst role. <span style="mso-spacerun: yes;"> </span>We engaged the product owners earlier and more often, changing from software watchdog to advocate for functionality and usability.<span style="mso-spacerun: yes;"> </span>And we actively sought ways to provide immediate feedback throughout the sprint, reducing the end-of-sprint rush.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">So, should you care if you are mini waterfall or agile?<span style="mso-spacerun: yes;"> </span>Agile testing gave us something that we lacked with mini waterfall, a way to become full share members of the development team.</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com1tag:blogger.com,1999:blog-5123874045942152210.post-27954539701467282612010-10-26T21:03:00.001-04:002010-12-03T08:08:56.474-05:00How HP Failed BPT<div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><span style="font-family: 'Times New Roman', serif; font-size: 12pt;">HP failed Business Process Testing (BPT) when it rolled the automated test framework out several years ago, and it has not really done much since.<o:p></o:p></span></div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><br />
</div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><span style="font-family: 'Times New Roman', serif; font-size: 12pt;">HP marketed BPT as a way for non-technical content experts to build automated tests. The original tutorials showed an implementation where the non-technical content experts designed and built components (the reusable building blocks of tests) by simply stringing together objects and keywords. Then, the content experts drag the components together to build tests. That tutorial demonstrated the functionality of BPT, but it failed to even give a hint about how to implement it successfully.<o:p></o:p></span></div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><br />
</div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><span style="font-family: 'Times New Roman', serif; font-size: 12pt;">Non-technical content experts are the wrong group to use when building the infrastructure for a test system. The system is good, but it is not automagic.<o:p></o:p></span></div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><br />
</div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><span style="font-family: 'Times New Roman', serif; font-size: 12pt;">Non-technical content experts should never be the ones to decide the scope and purpose of components. The components are way too important, and the approach is way too random. There are too many ways to define a component, and if you don’t have a pattern or model in mind, you will end up with a bunch of components that are redundant, inefficient, and hard to maintain. The strategy for designing components should be treated like a software development activity. An automator should be involved here.<o:p></o:p></span></div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><br />
</div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><span style="font-family: 'Times New Roman', serif; font-size: 12pt;">In addition to confusing the issue of who should design components, HP provided no advice on how to design them, and there is still a fair amount of confusion about this. For example, should we build components that perform a business process? That makes sense based on the name, “Business Process Testing.” But, when you have a component called “Register a New Member,” you are limited to using the same positive flow. How would you use that component if you wanted to verify negative tests such as what happens when you attempt to register a new member with an invalid social security number? Business processes like this would make sense if you only wanted to test “happy path” cases.<o:p></o:p></span></div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><br />
</div><div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0in;"><span style="font-family: 'Times New Roman', serif; font-size: 12pt;">After this confusing rollout, BPT languished without a lot of attention from HP or the testing community. This has been really frustrating to those of us who use and see the value of BPT. As I see it, BPT is the perfect tool for agile testing. It is a great tool for getting the power of automation to all members of the team without being limited by the level of technical skills.<o:p></o:p></span></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0tag:blogger.com,1999:blog-5123874045942152210.post-68795998744269006742010-10-25T21:54:00.001-04:002010-10-26T06:35:34.184-04:00Testers Need Not Apply<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"></span></span><br />
<div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">The fault may be mine and the job description I have posted, but I am not seeing the candidates I would like to see for my agile testing team. This is causing me to slow down and question what I want.</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><br />
</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">A few minutes of brainstorming and here is what I came up with (“up with which I came,” if you prefer): </span></span></div><div><ul><li><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">A question asker who makes no assumptions about requirements or how to test</span></span></li>
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">
<li>A project manager who can herd developers</li>
<li>A negotiator adept at talking to gunmen in hostage situations and skilled at getting programmers to do his bidding</li>
<li>A questioner of authority</li>
<li>A nerd repelled by bureaucracy and unnecessary process</li>
<li>A get-it-done-no-matter-whose-job-it-is person who can own a project</li>
<li>A curious technician who knows how to build testing tools</li>
<li>A voracious reader and active learner who takes responsibility for professional skills and knowledge</li>
<li>A programmer and an automator (automation skill are not the same as programmer skills, but that is another story)</li>
<li>A lovable pain in the ass who looks for practical solutions, not the “process” that is always done</li>
<li>An optimist who has not been beaten down by bad experiences in conventional “QA” organizations</li>
</span></span></ul></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><br />
</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">After reading a pile of resumes and talking with a number of candidates, I am not finding what I am looking for (or “that for which I am looking,” jerk). I don’t think that my expectations are unreasonably high. I want great, smart investigators who don’t know “no.” Too many testers have been taught to limit themselves and to have low expectations. Too many testers don’t take pride in professional knowledge and growth.</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><br />
</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">I am beginning to think that maybe I don’t want a “tester.” Many testers have to unlearn what they know about testing before they can learn to be true agile testers. They have to unlearn limits. That unlearning may not be worth the effort. </span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><br />
</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">Hopefully, I will find the right agile tester from the testing community, but I may look for a smart recent graduate – someone I can train and never let have low expectations. </span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><br />
</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;">In testing, we often create our own limits. I hate that.</span></span></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><br />
</span></span></div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com6tag:blogger.com,1999:blog-5123874045942152210.post-51707169651140673192010-10-24T19:43:00.002-04:002010-10-28T22:10:48.727-04:00The Magic of Automation Hour<div class="MsoNormal">We had a problem. As a test team, we had two conflicting goals. We needed to develop new automated regression tests, and we needed to work with developers and product owners at the beginning of the sprint. Before introducing automation hour, we didn’t do either well. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">We develop software in four-week sprints. In QA, our goal is for everyone to develop automated tests – we don’t want automation to be a specialized skill. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Before we introduced automation hour, we found ourselves working on our backlog of automation projects after one sprint was completed – during weeks one and two of the following sprint. When we focused on automation at the beginning of a sprint, we missed out on the planning and requirements discussions with programmers and product owners. When we did become involved with the sprint work, we were behind and didn’t know the project well. Weeks three and four were full-on testing efforts and our work on automation stopped. We were never in sync with the developers.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">About a year ago, we started automation hour. Automation hour is one shared hour a day that everyone on the QA team sets aside to work on automation. We now work on automation during all four weeks of the sprint, even the hectic third and forth weeks of the sprint. During weeks one and two, we limit our time on automation work to the hour, and this gives and encourages us to find ways to involve ourselves more fully in the opening days and weeks of the sprint, long before anything is ready to test. We are able to follow automation hour during weeks three and four because we spread out our automation work evenly throughout the sprint. <br />
<br />
Automation hour has freed us to focus on the broader aspects of agile testing while continuing to grow our automated test coverage.</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0tag:blogger.com,1999:blog-5123874045942152210.post-37061863211969013402010-10-23T13:32:00.000-04:002010-10-23T13:35:15.833-04:00Introduction<div class="MsoNormal">In this blog, I intend to discuss topics related to agile testing: manual testing, automated testing, innovation, and professional growth. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Some of my perspectives are colored by my frustration with how QA/test teams typically operate: testers are second-class team members with minimal technical and professional skills who have little influence on the projects being developed. Additionally, most automated test implementations are failures, either too simple or too complex to work. Among other things, I will share our approach to automated testing using HP’s Business Process Testing (BPT).</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I look forward to sharing ideas and perspectives with you and learning from your feedback…Bob</div>Bob Joneshttp://www.blogger.com/profile/17476923603844846075noreply@blogger.com0