Please see my StickyMinds Blog for a new post inspired by Jeff Patton’s recent presentation to our Agile Denver user group. The Whole Team Approach isn’t just for developing the software! We need to really think Whole Company. Comments welcome!
I’ll be speaking at the Norwegian Developer Conference June 16 – 18 in Oslo. The conference puts out a free magazine which includ
es my article about Learning for Testers, along with lots of great articles from other speakers such as Jurgen Appelo, Roy Osherove and Chris Sells. The speaker lineup includes lots more exciting practitioners and experts: Mike Cohn, Brett Schuchert, Uncle Bob Martin to just name a few. If you plan to attend, please let me know, I’d love to see old friends and meet new people there!
The Software Quality Association of Denver held a workshop May 7 to share ideas about why testers need to learn, what they need to learn, and how they can learn all of that. I facilitated an enthusiastic crowd of about 80 people. The room wasn’t set up in a suitable way, but participants found creative ways to work. And creative they were. I’d like to summarize some of the outcomes.
We started by dividing into small groups to brainstorm the reasons why testers need to learn. Beyond the obvious “stay employed” and “do your job better”, some fascinating reasons came out: “To stay interested and sharp”, “self-esteem”, “curiousity”, “freedom” – I’ve always thought that job security is in your mind. If you believe you have valuable skills, you’ll know you can get a job no matter what happens. Now, that’s freedom!
Group Brainstorming Activity
Other reasons that I might not have thought of included: Help others learn, keep up with changing environments and be more flexible and adaptable, spawn new ideas. “Challenge yourself”, “Be a better contributor” – this is the attitude I want in my peers! There were several comments on the theme, “avoid reinventing the wheel” – find out what works and what doesn’t, build on previous learning and trials, make work easier and more efficient.
Another theme was “prevent stagnation”: keep your brain young, become more well-rounded, balance working hard with getting help when needed, be ready for the next opportunity, job satisfaction, and one of my favorites: “It’s fun to learn”. Well, yeah!
Our second group activity was to think of all the things we need to learn. I was gratified to see a lot of what some people call “soft skills”, what Diana Larson and Jim Shore call “essential skills”: negotiation skills, listening skills, stress management, leadership skills, management skills, team mentality, how to motivate people, conflict resolution, creative problem solving, how to work with developers, communicate without jargon, simplify concepts, how to think like a customer, politics, team dynamics. An especially intriguing item was “Who tells the truth?” It’s critical to know that, right?
Creative Use of Body and Chair for Brainstorming Surface
Flexibility and versatility were a theme here. Design patterns, programming/scripting languages, platforms, levels of abstraction, being able to speak the developers’ language were important outcomes. “Keep your brain in good learning shape” is something essential that hadn’t occurred to me before. One group noted the importance of learning estimating and planning skills. Long lists of test tools, processes, methodologies and other technical skills were also popular items on the “What to learn” lists.
This all sounds wonderful, but how do we learn all those diverse skills? Where do we find time to gain that experience? In our third group activity, the SQuAD groups came up with lots of innovative ways to learn.
One theme was trial and error. Learn from mistakes – what worked, what didn’t. Retrospectives are one way to do this. Experiment, do pilot projects, and importantly, build slack into the system so you have time to do this. A learning culture where mistakes are tolerated is a prerequisite for innovation and creativity.
Mentoring was another common theme, but a twist on this was not only to get a mentor, but to be a mentor. Mentor the tester next to you! Learn by teaching.
Collaborating within and across teams is another learning method that several groups came up with, but again with different ideas. Creating a shared space and being able to sit with people that have different skills is a great way to learn. Using wikis for collaboration is another. Pairing with other testers and with developers was suggested. Getting feedback from coworkers is another simple but effective idea. Our peers are a great resource.
If the sticky notes won't stick, brainstorm on the floor!
Participants had a lot of interest in learning about their business, learning the domain. To do this, they suggested brown bag lunches with Subject Matter Experts, using the product like a customer would, talk to experts, observe. One of my favorite ideas was “Write a manual!”
Some outcomes built on our existing skills that already help us be good testers. We’re good at asking questions, so ask! Ask followup questions. Learn about the product with exploratory testing. Do compoarison testing. Evaluate tools to learn more about them.
There are obvious online sources of information, such as webinars, podcasts, blogs and white papers. I was surprised how many groups listed “Google” and online searching as a way to learn (though it shouldn’t be surprising – we all do that all the time!) Social networking also came up a lot as a good way to get information and benefit from others’ experiences. In addition to mailing lists, we have many online communities at our disposal, such as Software Testing Club and Weekend Testing.
One group suggested applying principles from non-related areas. Our reading and learning shouldn’t be limited to testing or even software development. Inspire yourself by attending (in person or virtually) conferences such as TED: Ideas Worth Spreading.
I was gratified to see several groups suggest that we learn by doing. “Practice!” The best way to learn is just go ahead and try something.
Outcomes on Door
You can see the groups at work, and their ideas, on my Picasa site. Please take a look and think about what you will do today to learn something new.
I have LOTS to write about StarEast, but I’d like to start with the conference-within-a-conference that a group of us planned on our own. Well, I didn’t do much planning, but Matt Heusser took the lead and lots of other folks including Justin Hunter planned a couple of fun and enlightening events.
We were self-titled the “Rebel Alliance”. I don’t think we were rebelling against anything, there are just a lot of Star Wars fans in the group. (Though there was a good lightning talk suggesting good things we do rebel against). I was going to be a Bantha until someone reminded me of a gruesome scene involving one.
But I digress. We had dinner one evening, at which we even got t-shirts with a star fighter on it. So much fun to get to know people such as Yvette Francino, Shmuel Gershon, Lanette Creamer, Selena Delisie to name just a few (and how great to have lots of women!) I’ve known Adam Goucher awhile and met him at Agile 2009 (if not before), but it was great to see him and his fellow editor of Beautiful Testing, Tim Riley (who did a great keynote at the conference).
Shmuel Gershon's lightning talk
The next evening our group had our own lightning talks, which were as intriguing and creative (maybe more) than anything at the conference. Adam talked about pirates, and Lanette talked about herding cats. This photo of Shmuel presenting a new session testing tool he wrote shows how much energy the speakers had.
Jon Bach had surprising and thought-provoking exercises, as always. These are just a few examples.
At the Rebel Alliance Lightning Talks
Selena and Dan took lots of videos, I hope those will show up someplace. David Gilbert provided his own tasty home brew – what a treat! He did a good talk too, on what we’re rebelling against, and for – learning vs. pass/fail, programmer’s best pal vs. quality police.
Conferences always get my brain buzzing, just being around such smart and creative testing professionals. But being a part of this terrific group was amazing. From old friends like Janet Gregory to more recent friends such as Sean Stolberg and Dawn Cannan, to people I only knew on Twitter up to now, such as Alex Kell, to people I didn’t know at all before, like Mark Vasco - it was almost overwhelming! I wanted to talk to everyone at once!
After this experience, I suggest you consider this at your next conference: get a group of like-minded people together and plan an evening ahead of time. You’ll look forward to the conference that much more, and take exponentially more ideas home with you. And you’ll be part of a small community that hopefully will live on past the conference.
I boarded BA flight 218 to LHR last Wednesday evening, eager to attend and present a tutorial at ACCU 2010. I had heard about the volcano in Iceland weeks ago, but never knew it had potential to disrupt flight until we were about to board the plane. About midnight, after dinner and well into a movie, the pilot announced we were turning back due to the volcanic ash cloud. Wow, I was glad to be safe, but extremely bummed about ACCU. Even if the plane took off the next night, I couldn’t make it in time for my session, so I had to call the whole thing off.
As we all know now, tens of thousands (millions?) of people have now been inconvenienced or worse by the ash cloud. I was grateful not to be stranded in an airport away from home, and there was plenty to do back at work! But this cloud has a silver lining, at least for some of us.
Friday evening I checked Twitter as I worked. I noticed a tweet from @Dr_Black about visiting the Tattered Cover. That’s in Denver! Where is she? I didn’t know Sue Black personally, but I follow her on Twitter and know about her work for Bletchley Park, thanks to Antony Marcano. As a supporter of Bletchley Park, I also follow Kelsey Griffin. She and Sue were in Denver for a conference on museums and the web, presenting a session “Can Twitter Save Bletchley Park?”
We arranged to meet for breakfast on Sunday. I was so thrilled to meet them both – what a great opportunity! A few minutes into breakfast, Kelsey turned to me and said, “Are you the Denver speaker who couldn’t make it to ACCU?” She had heard all about it from a friend at ACCU. Such a funny coincidence, thanks to the ash cloud!
As their flight had been cancelled, they decided to go to D.C. the next day, but Sue and Kelsey had Sunday to kill. I asked if they’d like to come out to a ranch, and see a bit of Colorado outside of Denver. We had such a fun day together, driving in the foothills, and playing at my friend Anna Blake’s Infinity Farm. Sue and Kelsey each had a ride in the donkey cart, pulled by Chester – Kelsey even drove! Sue had a long ride on the lovely Max, with coaching from Anna. Edgar Rice Burro, the large pinto donkey, fell in love with Kelsey, and followed her around resting his chin on her. A great time was had by all.
Then we visited Garden of the Gods, a park in Colorado Springs with stunning rock formations at the foot of Pikes Peak. I was surprised that Sue and Kelsey had energy left over for dinner with me and my husband Bob!
I’m so grateful for the opportunity to spend time with these inspiring women, learn about Bletchley Park, pick their brains about how to organize volunteers for our Women in Agile project, discuss agile development, and just enjoy new friends. If not for the volcano, I’d have been having lunch in Cirencester with Dave Evans, Marta Ferraro and Mike Scott. Instead I spent the day with two Londoners in Colorado!
Lots of people stranded by the cloud are making lemonade. Some ACCU speakers are holding Open Space London – Volcano Version on April 20. Enrique Comba tweeted that he’s in Chicago visiting Obtiva, Corey Haines and other developers. My co-author Janet Gregory was stuck in Oslo after teaching our Agile Testing course there last week, with our ProgramUtvikling friends offering to help her out, but she managed to get out today (Monday) and back to North America. As I follow the #ashtag tweets, I’m surprised how many people I know that are stranded in various parts of the globe, and I hope they all get home soon. If you’re stuck somewhere, I hope you’re able to make new connections and learn more about the part of the world where you are!
Safe travels!
There are so many test frameworks, drivers and other tools out there I want to try. For example, Selenesse has been at the top of my list of things to try for months (and I’ll get to it sometime soon!) However, I couldn’t resist the offer from Pekka Klarck, one of the Robot Framework contributors, to give me a live one-on-one demo of Robot Framework a couple of weeks ago. This weekend, I finally had time to try to write my first test (really, to finish up a test that Pekka had started for me).
My first test is below. I always struggle mightily when I learn some new tool or language, and this was no exception. (Apparently my more-geeky friends also struggle with new things, but they don’t whine publicly about it like I do). The user doc for RF leaves a bit to be desired from a non-programmer perspective. However, they are actively improving it. With much help from Pekka (and suggestions from many in the Twitterverse who also use RF), I have gotten over this first beginner hump, I can see lots of possibilities.
You can write RF tests in various formats, including HTML tables. I like the plain text format, because to me, simple is good. It makes the tests more amenable to version control, because you can easily diff versions to see what has changed. If you try that with html table tests you’ll have lots of noise.
I love the flexibility of this tool. I am trying it out with the RF Selenium libraries, but you can use it with a variety of tools, including tools to test non-Web apps such as Java Swing. There’s a lot of potential there.
I like the fact that you can define whatever “keywords” you want, so you can create your own domain-specific language and the test can document itself and the code that it is testing. The inline-documentation aspect is also one of my favorite features of FitNesse.
My team is pretty happy with our current tools: FitNesse for testing behind the GUI, Canoo WebTest for GUI regression tests, and Ruby/Watir scripts to help with exploratory testing. We’ve long wanted to try Selenium, though, and RF would give us an easy way to do that. We’re always experimenting, and an experiment with RF will tell us whether there’s value in adopting it.
For myself, I think RF will be useful in my public presentations and classes. I’m always looking for ways to teach good test automation design, and I think I can do this fairly easily with RF. I’ve seen Dale Emery and Elisabeth Hendrickson do good demos with RF. I’ve also seen Antony Marcano, Andy Palmer and Gokjo Adzic do good demos with FitNesse, so I’m not saying one is better for this purpose than the other!
Here’s my test. I also copied it in below, though the spacing might be wacky there. I put comments in for myself that might help you, too. Download the RF-Selenium library demo and try it for yourself. If you have any issues I am glad to try to help. It would help me learn, too!
—-
lisas_first_test.txt
# new line and 2 spaces are cell delimiters.
# the asterisks have to start in the first col
# Look at the selenium keywords in http://code.google.com/p/robotframework-seleniumlibrary/wiki/LibraryDocumentation
# Look at the quick start guide for more http://code.google.com/p/robotframework/wiki/QuickStartGuide
Actually you don’t even need the # if you type up above the first table. Tables can be in any order. ‘*** Test Cases***’ is an example of a table.
Run it with ./rundemo.py lisas_first_test.txt
To start the server for the app under test manually, python httpyserver.py start
*** Test Cases ***
invalid account
navigate to the login page
type in username invalid
type in password xxx
click submit
verify the invalid account error message
*** Keywords ***
navigate to the login page
log hello, world!
open browser ${LOGIN PAGE} ${BROWSER}
title should be Login Page
${title} = Get Title
should start with ${title} Login
type in username [Arguments] ${username}
input text username_field ${username}
type in password [Arguments] ${password}
input text password_field ${password}
click submit
Click Button login_button
verify the invalid account error message
Title should be Error Page
Page should contain Invalid user name and/or password
*** Settings ***
Library SeleniumLibrary
Test Teardown close browser
*** Variable ***
${LOGIN PAGE} http://localhost:7272
${BROWSER} firefox
During a flurry of tweets and blog posts about whether or not ATDD is a good thing, I posted a blog on Stickyminds with my opinion. I’ve gotten some great comments, please add yours!
We like small stories. If we keep stories to a size we can finish in two or three days, there is less likelihood of a story “blowing up” because we vastly under-estimated it. Doing lots of small stories every iteration helps us get into a steady rhythm. We can manage our work in process more efficiently and keep cranking stories through.
Some pieces of functionality are too big to fit into a small story, so we have to break them down. This is a hard skill to learn, but trust me, everything can be broken down into smaller chunks, somehow. This can get to be somewhat artificial and go against the principle that a story ought to deliver something of value to the business that we can release. However, we think the tradeoff is worthwhile. When we work on a big new piece of functionality, we simply hide the new stuff by means of properties until it’s ready for prime time. I guess we could branch the code too, but we prefer to work on the main trunk.
If you have some bit of functionality that doesn’t go end to end, how do you test it above the unit level? How can you show it to customers? This requires a bit of extra effort, but again, we’ve found it worthwhile. (My team has been chopping stories ever-smaller for six years now).
Here’s an example. Our application manages 401(k) plans (employer-sponsored retirement plans, to which employees and employers may contribute). Right now we are rewriting the functionality that allows a plan participant to “roll in” money from a 401(k) plan at a previous employer. We also needed to add functionality to allow users to roll in money that is not tax-deferred; this is called “Roth” money. As part of this rewrite we are rewriting the back-end processing.
When this is all finished, users will go to the UI, enter the information about the money they’re rolling in, and when they submit, instructions will be created that will allow us to receive the money and buy appropriate shares in mutual funds on behalf of the participant. One story read something like this: “As a participant, I want the system to be able to create instructions for Roth roll-ins”. Originally the story was to process the instructions, but we realized that was too big a story and cut it down.
There’s no UI yet, and we aren’t even processing the instructions, so how do we test this? The developer created a FitNesse fixture to accept information that users would enter in the UI, send these inputs to the production code, and the code in turn would create the correct instructions. Then we could use a “data fixture” (or we could use DbFit) to verify the data in the database.
I started out by just writing a FitNesse test to execute the fixture with my inputs and verifying the database with my own SQL queries. Then I made an automated regression test by setting up data about the plan and user in the database, operating the fixture to create the instructions, verifying the instructions, and then cleaning up the data. Here is the “meat” of the test. The basic data is set up earlier in the test. The “do” fixture specifies the roll-in data just as the user would in the UI, then sends it to the code which creates instructions in the database. The test then checks the data in the database. We can confirm this code works, even without the UI or ability to process the resulting instructions. And we can try lots of different test cases.
FitNesse Test for Partial Functionality
My teammate Nanda Lankalapalli and I are working on an article about how our team deals with having remote team members. Recently someone on Twitter pointed me to a blog post on Scott Hansleman’s “Embodied Social Proxy or Crazy Webcam Remote Cart Thing“. My fellow tester Lori Thayer suggested I blog about our own crazy webcam remote cart thing, so people can see there are alternative approaches.
I got the “dolly” idea from Maykel Suarez. He and my other teammates set one up for me when I was a remote member of his team. They got the virtual presence idea from Hanselman, but added the dolly idea to make it easily mobile. My “Donkey Dolly” was on a wireless network and could be wheeled even from building to building – it was way fun to wave at people as I wheeled by them, and enjoy the grass and trees outside!
Our “Virtual Nanda” or virtual telepresence device consists of a rolling laptop cart, a good laptop with plenty of memory and speed, a good webcam that can be panned around the room, a good microphone and good speakers. (We definitely need a catchier name for it; since Nanda lives in India, we were thinking along the lines of the Bollywood Dolly). Any team member working remotely who wants to use it can VNC to it, log in, make a video call to it on Skype, and control the audio and video. The mic is good enough that conversations around the room are audible. The speakers are good enough that the remote person can be heard around the room. Here’s a picture.
Virtual Nanda
Here’s another picture showing more of the cart. Instructions for how to use it are taped to the front.
Another View
If more than one person is working remotely and wants to use the Virtual Nanda, we can’t use Skype for video. We still use it for audio, and use Yahoo IM for the video. All the components are securely fastened to the cart so nothing will fall off when it’s rolled around to wherever it’s needed. Unfortunately using a wireless connection isn’t a viable option, because our only wireless requires being on the VPN and that’s too slow. So we have a long network cable. The cart has a power strip attached to it that in turn has a very long power cord plugged into it. The network cable and power cord are long enough to wheel anywhere in the team room, and we just unplug when we have to roll it to another room.
Nanda uses the telepresence every day for the standup meeting, and for all other meetings. If he needs to talk to anyone in the office or vice versa, they just walk over to our area and talk to him just as if he were in the room. Anyone working from home is also free to use it. When I work from home, I stay on the virtual dolly all day, my teammates position it so I can see several of them when I move the camera around, and I just holler if I need anything. I wear a good USB headset to screen out background noise on my end and hear them better.
Look for a longer article about this and other aspects of making teams with remote team members work smoothly and successfully!
I’ve submitted three proposals to Agile 2010 and would love your feedback. Please review them – you will need to create a free account on the submission site if you don’t already have one.
Workshop: Who Pays for All the Fun? Selling the Value of Testing in Agile Projects
Tutorial: The Whole Team Approach to Testing
Talk: How Low Can You Go: Doing the Defect Management Limbo
I have a thick skin, so don’t hold back. I know there will be lots of great sessions, there’s a high standard, and I want to make a useful contribution.
Agile testing practitioner and coach
@lisacrispin on Twitter
