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!
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.
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
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.
Chris McMahon has blogged about our Writing About Testing group. I’m so grateful to Chris for starting this group. We have a wonderful bunch of testers/writers. I really enjoy helping members who are new to writing get published for the first time. I also really appreciate the great help and advice I get about my own writing.
Now, if I can just find the time to write! Check out my News page to see why I’m so busy. (I’ve also been on vacation for nine days! Back to work soon, hopefully with lots of new energy and ideas after this nice rest!)
Last sprint we had a half-point story, which in our world should be about a day of coding and testing, to do some “simple” text content changes on a wizard in our web application. It’s been a year since we had updated this part of the application (it mainly gets used from late January to mid-March). While we were planning our sprint, we didn’t think too hard about how the wizard worked, and how many permutations it involves over the span of time that our end users are using it.
First Try
Our product owner asked me for screenshots of some of the pages, and had his mockups of the changes ready to go in a Word document before the start of the sprint. We wrote test cases on our wiki accordingly.
Second Try
One of the programmers started working on the story and realized the code had a lot of different cases that depended on dates and statuses of various items. He printed out some of the code and went over it with the product owner to get the appropriate text for each of the cases. The original mockups we had were no longer useful.
Third Try
When I started to test the updates, I kept getting confused. There were subtle differences between the different permutations, and several different target and deadline dates involved. I showed the new pages to the product owner, and he got confused himself, and kept making more changes to the text and even to the logic behind what text is displayed when. The programmer patiently updated the code over and over again, but I could tell he was losing the will to live.
I finally cut and pasted paper mockups myself for each possible condition with the text I thought was correct, went over it with the product owner who made his changes, and the programmer worked from the paper mockups. This did the trick, but by now, the half-point story had taken eight days instead of one.
What We Learned
In hindsight, we think that we should have started by researching all the different possible permutations before we started on the story, giving the PO a screen shot for each one, and having him give us paper mockups for each condition. This would certainly helped me test, as I tend to be more visual, rather than being able to mentally interpret what the code should produce.
When we showed this to more of the stakeholders, they asked if anyone besides the PO and us had reviewed the new text. We had been depending on the PO to do this, so we didn’t show it to anyone else until the coding was finished. Next time, we’ll ask the PO if other stakeholders have reviewed his changes.
Sometimes stuff just happens, but if we always remember to get a mockup for each change needed and each case, it might save us time in the future.
There’s a lot going on – I have new articles published and lots of tutorials, workshops and other events coming up. Please check out my News page for details.
It’s that time of year for resolutions. One important agile principle (to me, at least) is the idea of continuosly improving. We are always looking for experiments to try, ways to work better. (There’s discussion on Twitter right now about the label ‘agile’ – maybe it’s time to drop it and just let it be the way we develop software! But that’s another post!)
Recently I wrote a Sticky Minds blog post about being nice. On New Year’s day, I read one of those newspaper articles you see every year that gives advice on sticking to resolutions. It suggested that rather than resolve to “being nicer”, set specific goals, such as, “I will compliment one of my co-workers each day on one of their accomplishments”. That seems smart.
So, instead of resolving to act nicer, I will resolve to notice and appreciate each day at least one of my teammates’ contributions. I also want to pair for some period of time with a coworker at least a couple of times a week. It would help me improve my skills, and I think it helps the team improve.
I have lots of other ways I’d like myself and my team to improve, watch this space. Meanwhile, I’m more interested in what other people are doing to improve how they work or behave. Please comment and share!
Agile testing practitioner and coach
You are currently browsing the archives for the agile testing category.
