Software Testing Blog

Quality (pun intended ) software testing events are hard to find, but we’ve not only attended and spoken at some fantastic conferences around the world, but we’ve also simply asked around and received some great feedback in order to compile the Top Ten Testing Events.

Much like our Top 20 Software Testing Tweeps post, we need your help in letting us know if we’ve accidentally missed any good ones. Here they are in order of occurrence:

1. QUEST-Quality Engineered Software & Testing Conference (Apr 19-23, 2010: Dallas, TX)
2. Rapid Software Testing-By DevelopSense (Jul 5-7, 2010: Amsterdam, NL)
3. STANZ-Software Testing Australia/New Zealand (Aug 23-34: NZ & Aug 26-27: AU)
   
4. CAST-Conference of the Association for Software Testing (Aug 2-4, 2010: Grand Rapids, MI)
5. STAREAST (passed) & STARWEST-Software Testing Analysis & Review (Sept 26-Oct 1, 2010: San Diego, CA)
6. iqnite events-Next one in UK-formerly Software & Systems Quality (Oct 4, 2010: London, UK)
7. STPCon-Software Test Professionals Conference (Oct 19-21, 2010: Las Vegas, NV)
8. GTAC-Google Test Automation Conference (Oct 28-29, 2010: Hyderabad, India)
9. Expo: QA (Nov 16-18, 2010: Madrid, Spain)
10. EuroSTAR (Nov 29-Dec 2, 2010: Copenhagen, Denmark)

Have we omitted any noteworthy testing conferences you’ve recently attended? Please add your recommendations in the comments and they’ll be placed in the running to join the top events list. Maybe we can make this list a Top 15!

UPDATE: So far, some really great recommendations from our community include O’Reilly Velocity, Bangalore Workshop on Software Testing and VISTACON 2010 (the first Vietnam International Software Testing & Automation Conference).

Retired NASA Astronaut Mike Mullane* (pictured left) said it best when he asked: “Why is there never time to do it right, but always time to do it over?” He could have easily been talking about the recent problems Toyota has been dealing with, but he wasn’t. He was talking about today’s software companies.

Conversely, this recent article from The Economist could just as well be about today’s software companies, but it isn’t. It is about Toyota’s recent problems.

Like everyone else, the author wants to know how the auto giant could so quickly lose its reputation for safety and quality (things that can happen to ANY company if they are not careful). The culprit? You guessed it: software bugs.

Instead (of trying to keep pace with competitors), two recent trends, both software related, hint at the reason behind Toyota’s unexpected decline. One is the shortening of product-development cycles generally in the car industry. These are down from a typical four or five years to little more than 15 months, thanks to computer-aided design and manufacturing, and the virtual simulation of the resulting products. To save money and time, Toyota has even dispensed on occasion with building test “mules” and other engineering prototypes.

Read more…

In the third and final part of the Michael Bolton trilogy, we cover advice for new testers, his hypothetical banishment from Software Land, the blogs he reads and more. Did you miss our earlier interviews? Here’s Part I and Part II.

uTest: Hypothetical: You’ve been banished from testing – nay, ALL software-related activities – for the rest of your days. What will you to earn a living?  What hobbies would you pick up to fill the intellectual void?

MB: Who knows?  For fun, I’d keep playing mandolin, probably. Teach, maybe. Write. I’ve worked in theatre stage management, been a book-keeper, tended bar, worked in a comedy club. In high school I worked in mail rooms during the summer. Whatever I’ve picked up in life, it was because something needed to be done and I was there to do it.  If it didn’t seem like much at first, I started to learn about it quickly. When you invest a little bit of effort to figure out your job, you learn how to makes it faster and better and more interesting. It turns into this great feedback loop. Any job can be more fun when you set out to master it.

uTest: Tell our testing community something about you that your most avid readers don’t know.

MB: While walking through the woods on an island near Vancouver recently, I found myself being quiet and brief, which I like from time to time. Practically nobody knows that.

Lots of people probably don’t know how much I’m eager to help people out. All of my work—courses, articles, conference presentations, this interview—comes with lifetime free technical support. Have a question? Just ask. I might not answer right away—supporting the family with paying work takes precedence over supporting the community—but I’ve never knowingly turned anybody down, so if I don’t answer right away, be persistent. James Bach makes the same offer, by the way. We’ve found that it’s a great way not only to help people, but also to explore problems and come up with solutions and learn things that can help our clients.

uTest: If you were talking to a newbie tester, what advice would you give him or her to set their professional journey off on the right foot?  How about for a 10-year veteran tester?

Read more…

In the first part of our interview with Michael Bolton, we grilled him on the emergence of the Weekend Testers, sensible metrics, Michael Bolton the pop star and a bunch of other topics. In part “deux” of our interview, we tackle the necessity of tester passion, how emotions affect testing, and the greatest threats to the profession. Check back tomorrow for the final segment.

uTest: There’s a lot of passion amongst testing thought leaders about the best way to test, or the best way to manage or train testers.  Often that passion overflows into heated debates.  How can this passion best be channeled to improve the state of testing?

MB: First of all, we should welcome debate, and we should welcome skilled argumentation as part of the art of construction and practice of persuasion. I’ve found, though, that it helps to remember that we’re exploring and challenging ideas. That means it’s good not to get too personally invested in certain ideas, because we’re always learning more, and because changes in context can mean big changes in what needs to be done.

That said, there are some ideas that seem robust for me. I believe that it’s unethical to dumb down people or the work that they do. I believe that we should focus our craft on learning, and learning how to learn rapidly. How can we improve the state of testing? By recognizing that software development is a web of people who are related in service to each other. That means putting people and social issues first. Get that right, and everything else will follow.

Suggestions are cool.  Standards are something else.  No group should be dictating to other people how they must test unless there are compelling human health and safety reasons for it. Do you really believe that the standards people know anything useful about your business? That the force of government-supported regulation, created by busybodies, should weigh on how you do your daily work? And if your answer is No, what are you going to do to get it stopped?

Read more…

Yesterday we posted Part 1 of our interview with James Bach, where he discussed tester certifications, faking test projects, his latest book and wide range of other topics (including life as a freelance sentry in a parallel universe). Today, for Part 2, we discuss tips for automated checking, what makes a good tester a great tester, his flying lessons and much more. Enjoy!

uTest:  Do you see the quality of resources in the testing field increasing or decreasing (tools, training, certs, et al)?  What do you think are some of the drivers of that change?

JB: There are many good resources out there, and yes there are resources getting better. There’s testingeducation.org and the Weekend Testers project, to name two. At the same time there are terrible things out there (such as certification and all the stupidity that goes with that). You have to be a smart consumer, because it seems to me that the bad stuff has always outweighed the good stuff by an order of magnitude or so. Maybe by two orders of magnitude.

uTest: When it comes to automated checking, what are some of the key opportunities to employ it that generally generate a positive ROI? Are there any good rules of thumb that can be used, i.e. if you plan on executing the same test 7 times, then it is a candidate (understanding of course that some assumptions need to be made to answer this)?

JB: Here’s how I think of it:

- Is the product highly controllable and observable? A command line tool that provides its output solely to the console window is inexpensive to automate, compared to an iPod touchscreen app. I want to get under the GUI.

- How expensive is the tool I’m using? I urge you not to use expensive tools, even if they work. Never let your manager buy them. Because expensive tools become something you MUST use, even if they don’t work. A free tool may be freely abandoned. This gives you flexibility.

- How well can I automate the oracle? Will the bugs be able to elude my automation because it can’t tell if a complex graphic is rendered correctly?

- What is the learning and testing value I’m giving up by using automated checks? I find that doing a test multiple times also causes me to learn and see new things in the product. Furthermore, when I re-run tests, I often run them in a different way, and that allows me to find new bugs.

- Can the automated check be parameterized and randomized, so that I get lots of similar checks for very little additional investment? I like automation more for data intensive testing, because I get new tests just by changing the database.

- Is the technology “Pyramid shaped?” In some products lot of underlying code boils up to one simple output, by placing checks on that output, we may be able to find lots of bugs. In other products, there are many different pathways, and you need a lot more checks to get decent coverage.

- How critical are the checks to the business? Is this critical functionality? Is it a common usage scenario? There are candidates for smoke testing.

- Is this part of the product especially prone to breaking? If so, that may be good for automation, UNLESS, it breaks in a way that breaks the automation.

- When I automate, I do it incrementally, in small bits.

I want automated checks for high value, highly testable parts of the product, and I want to do them in such a way as they aren’t constantly breaking or giving me false readings. I want to augment those checks periodic sapient testing as a cross-check.

uTest:  What characteristics and practices make for a good tester?  How about a great tester?

Read more…

In the December episode of our Testing the Limits series, we rapid fire some questions back and forth with James Bach (@jamesmarcusbach).  James is one of the most thought-provoking, outspoken, earnest thought leaders in the testing space.  Check out his blog if you don’t believe us.

Today we’ll be discussing James’ disdain for tester certifications, faking test projects, werewolf hunting in parallel universes and what he would do if he were king (or an angel) for a year. Don’t worry, it’ll all make sense soon. Update: Here’s Part 2 of the interview.

uTest: You’ve been an outspoken critic of traditional certs and classroom education. If you were king for a year, how would you fix testing certifications?  And how would you change a college’s curriculum?

JB: Kings are not powerful enough. I want to be an angel for a year.

You see, certification is promoted by frightened people who feel they need elaborate content-free ceremonies in order to feel competent. But in their hearts they know they are faking it. The fear of being exposed as imposters keeps them from doing much about it. So, in that year I would travel at relativistic speed around the industry. I would visit, by night, the hearts of testers everywhere, giving them inspiration to become excellent at their craft. The ones already certified would wake up and take a long cleansing shower, then write blog posts– by the thousands!– repudiating ISEB, ISTQB, CSQE, and all such blight. They would declare themselves reborn as students of the craft. (The ones not certified will just feel strangely cheerful, at least for testers.)

A spirit of exploration, experimentation, and debate would spread around the industry. It will seem to come from everywhere at once.

Weekend Testers would become Weekday Testers. TMap textbooks would be beaten into plowshares… and then recycled. Test plan templates and TPS reports would blow forgotten through streets lined with cheering crowds playing tester games designed to hone practical reasoning skill. By the thousands! FOR THE WIN!!

As far as university goes, I’ve already been doing my part. I helped found and run the Workshops on Training Software Testers, which brings university professors together to examine how to teach testing better.

I served on an advisory board for the Rochester Institute of Technology when they were trying to set up their degree program in software engineering, too.

But if I were king (not the modern Swedish kind but the old-school Caesar kind) I would make school a lot harder (much easier to expel a bad student) and instead of paying tuition, students would be paid.

Also, there would be no classes, as such, just constant projects and training. In other words, it would be almost exactly like Silicon Valley in the eighties, except with better corporate libraries.

uTest: If a parallel universe where you weren’t involved in testing or software at all – what would you be?

JB: If the parallel universe is before the industrial revolution, then any TWO of the following:

• A freelance sentry.
• A small-time warlord.
• An itinerant geometer.
• Werewolf.
• Werewolf hunter.
• A member of the 1735 French Geodetic expedition, but not the one who got killed by the mob at the bullfight (he had it coming).
• Zorro.
• A gentleman naturalist.
• A buccaneer.
• Gandalf.

uTest: A full day at an ISTQB seminar, or a full day in a college-level computing class – you’re forced to choose one. What’s it gonna be?

Read more…

In this month’s installment of “Testing The Limits”, we sit down with Matt Heusser (@mheusser) — prolific blogger for STPCollaborative, thought leader and testing extraordinaire.  We’ll discuss the state of software testing, SpeedGeeking, the role of chaos in testing software, and the lack of fistfights at STPCon 2009

uTest:  We loved the SpeedGeeking session you led at STPCon, so we’re going to flip it on you – If you had just five minutes to teach, motivate or inspire the uTest audience about software testing, what would you say?
MH: Well, I’d start by asking the audience what they are doing today – what’s the greatest point or opportunity they feel – and asking what options they see to improve. Most of the time, I hear that testing is “too slow” or “the bottleneck” or something like that.

So I suggest taking two weeks and actually measuring how the team is spending its time. Oh, not for reporting – it is very important the team stop the time tracking after two weeks and not hand individual metrics into management for evaluation. Instead, we want to use the numbers for improvement. For example, many of the people I talk to can spend 80% of their time or more in meetings, working on documentation, working on compliance activities, doing email, and so on. That only leaves 20% of the time to test! Just pushing those numbers from 80/20 to 60/40 will double the amount of time the team spends actually doing testing.

Another thing to look at is the amount of time spent trying to reproduce defects, document defects, file bug reports, “verify” fixes, and so on. We think of these activities as testing, and they can take a substantial chunk of that 20% – but they are really accidental. That’s not a testing bottleneck – it is a development bottleneck. If test can work with development to improve the quality of the software prior to code complete, that will improve the speed of the whole system. Realizing this, and having a little bit of data to “prove” it, can help the entire system improve.

So if I had five minutes, I would say start with measuring how you track your time, and ask yourself if this is the best use of your time and what can change. Sometimes, the big boss will say “no, we absolutely need you to fill out all seven pages of documentation per test run”, and you can say “ok.”  Six months from now, when someone asks why the big project is late, you can point out that the business made an explicit decision to pay the full price of defined process. You presented options and those were not accepted.

That won’t save this project — but it might save the next.  It also turns out that actually testing tends to be much more fulfilling than documentation and compliance activities. Who could have guessed?

Lots of contrasting opinions at last month’s STP Conference. While there were no fist fights (that we heard about anyway), what did you see as the most contentious issue? And where do you fall on this issue?

Read more…

Earlier this week, several members of the uTest team took in the opening reception of Software Test & Performance’s STPCon event.  We overheard some great conversations, and even jumped into the fray a few times ourselves.  It was a lively crowd and a great venue (the Hyatt Regency) right along the Charles River.  The event continues today, but even if you’re not attending you can still follow along, check out the STPCon Twitter stream here.

This event gave us a chance to reconnect with our friends from STP Collaborative, as well as sit in on sessions from top-shelf testing thinkers like James Bach, Jon Bach, Michael Bolton and Matt Heusser.  We also got to connect with about a half dozen local uTesters who took us up on our invitation to attend the reception.

We had a few people from uTest in attendance on Thursday and they gave the presenters high marks overall.  The two that I heard the most comments on, however, were from James Bach and Michael Bolton.  Bach tackled the provocative subject of “How to Fake a Test Project.”  Bolton took on the topic of “Rapid Software Testing.”  We’ll see if we can get either of their presentations and share them here. Also of great interest was Friday morning’s SpeedGeeking session with Matt Heusser, which put the speakers on the spot, giving them only five minutes to get right to their point. Talk about fighting your natural instincts!

For anyone who attended, chime in and share your most or least favorite moments from STPCon?  What surprised you, frightened you, entertained you or just generally pissed you off? Sound off in the comments or drop us a line.

Meanwhile, the uTest paparazzi was present and ready to capture some of the scenes from the evening.

Matt Heusser and James Bach take a timeout from their testing debate for a quick photo

Matt Johnston and James Bach deep in discussion about the art & science of testing (and the difference between the two)

Jennifer Moebius and STP chief, Andy Muns take a break from the exhibits to pose for a pic

Calling all New England QA and software testing professionals!

We will be co-hosting a free tester meetup with STP (Software Test & Performance) as part of the kickoff reception for their big event, STPCon 2009 at the Hyatt Regency Cambridge.  This meetup will be Wednesday, October 21 at 5:30pm.

Join us for a great evening of networking that will be held in the STPCon exhibits area. There, you’ll have the opportunity to connect with your peers, connect with execs from uTest and STP, discover new products and features and talk to the experts who created them.

Another great perk for attendees is that you’ll have the opportunity to discuss the latest and greatest trends with industry leaders such as James Bach and Michael Bolton.

If you’re around, it would be great to meet you in person!  To register, please visit: http://utest2009stpcon.eventbrite.com/.

In the latest installment of our “Testing the Limits” series, we sat down with Andrew Muns (@amuns) the President of Software Test & Performance (of STP Magazine and STPCon fame), to discuss how testers are perceived by execs and developers, the future of media companies, and the changes that are underway at STP.  This is the first half of our chat; check back Thursday for part two.

uTest:  STPCon is being held this October in Cambridge, MA… what do you have in store for the attendees this year?

Andrew: This is the first conference that will have been planned start to finish by Redwood Collaborative Media and was designed according to our very simple philosophy: “ask your audience what they want and give it to them.”  The show’s program was designed largely  based on a survey in which we asked two things, what topics are most important to you and who do you want to hear from.

The most requested topics among our readers were Test Automation, Performance Testing, Test Management and Agile.  We’ve built a five track program with specialized training and workshops for each of these four areas, plus a track we call “FutureTest.”  The concept of FutureTest is to take a look ahead to emerging tools, technologies and practices – to help our members stay on the cutting edge of the testing industry.

We’ve got only all-stars here (check out the full roster) plus a keynote by a NASA astronaut, Mike Mullane, who will talk about leadership and the organizational culture that led to one of the most tragic QA mistakes in history: the O-ring of the space shuttle Challenger.  Michael Bolton, will then use this story as a launching point (pardon the pun) to talk about test leadership.  It’s going to be a phenomenal event.

uTest:  You recently launched STPCollaborative.com. Tell us the purpose of this site and what’s so different about it.

Read more…