How We Really Need to Stop ISO 29119

After some real consideration, I have decided to sign the Stop 29119 petition, and along the way also signed the Professional Tester’s Manifesto.stop-29119

The main reason that really resonates with me is that companies, who would normally not use the standard, would be compelled to comply with it just to win business. If there are even a few companies that conform to the standard which are successful, and it doesn’t have to be because they comply with the standard, others will try to follow their path.

At some point, almost every company complies with the standard, and no one knows the reason, only just that the paperwork is unbearable, there isn’t any room for actual testing, and they are afraid to step out of this vicious circle. I do not wish for the testing field to go through this, and that is why I have signed the petition.

But here is where it gets tricky: I think the people who started this opposition to stop the ISO should have thought more about their actions before jumping the gun. One of the few problems I have with this course of opposition is that it gives too much power to the body behind the standard. After some time, all this opposition will turn into just information. People searching for testing-related information may come across all these countless blogs against 29119, and the only thing they will do is research the standard and tell themselves that so many people wrote about it, they should try it, and maybe convince their companies to comply with it.

Even negative advertising is still advertising — it is always of some value to the product being advertised — and gives it some kind of power in the form of public awareness. The proof can be, for example, the ISTQB. As a new tester few years ago, I wanted to get certified (I didn’t) because everybody was talking about it. It was not in a good light, but I still thought it would help me land a good job. There weren’t any other options, so what should a new tester do in this case?

Continue Reading

Incorporating User Feedback in Development Leads to Better Software Releases

Note: The following is a guest submission to the uTest Blog from Sanjay Zalavadia.voice_of_user2

By considering the performance of in-development software from the perspective of the end user, QA teams can better address disruptive issues.

Software testing can often be an arduous and stressful process. Even in traditional waterfall production methods, quality assurance teams are typically faced with a months-long period colloquially known as the “death march” as developments near release. During these moments, QA management and teams hunker down and toil away, attempting to address as many remaining coding flaws as possible before the software goes into production. The proliferation of agile development principles has only escalated this trend as QA members are constantly working to identify areas of improvement during the entire course of development.

It’s understandable if QA objectives become a little shortsighted under these conditions and testers place all of their focus on finding bugs and coding errors. However, testing managers need to remain cognizant of the ultimate goal of any successful development process: optimizing the end user experience.

QA performance cannot be measured by the number of bug reports generated, but by the satisfaction of software users following a product’s release. To that end, it is advantageous to consider the viewpoint of the consumer and incorporate user feedback into the development process.

Usability critical to software performance

In a truly agile software development project, user feedback is a critical component of the production cycle, helping to guide tester and developer efforts to improve the performance of the application.

By considering how individuals engage with a piece of software and what problems may commonly occur or will be most disruptive to the user experience, developers and QA teams can better focus on addressing those issues. That fact is that despite the best efforts of software testers, coding flaws are essentially an inevitability. No software is 100 percent perfectly written, but the most successful programs are often those that perform at an optimal level with a bare minimum of usability issues.

In a Software Testing Help post, quality assurance expert Santhosh Kumar Ponnusamy outlined several of the traits characterizing a successful tester. In particular, he highlighted the openness to consider the end user viewpoint and the staunch commitment to improving consumer satisfaction.

Continue Reading

ISO 29119: Why it is Dangerous to the Software Testing Community

stop-29119Two weeks ago, I gave a talk at CAST 2014 (the conference of the Association for Software Testing) in New York, titled “Standards: Promoting quality or restricting competition?”

It was mainly about the new ISO 29119 software testing standard (according to ISO, “an internationally agreed set of standards for software testing that can be used within any software development life cycle or organization”), though I also wove in arguments about ISTQB certification.

My argument was based on an economic analysis of how ISO (the International Organization for Standardization) has gone about developing and promoting the standard. ISO’s behavior is consistent with the economic concept of rent seeking. This is where factions use power and influence to acquire wealth by taking it from others — rigging the market — rather than by creating new wealth.

I argued that ISO has not achieved consensus, or has even attempted to gain consensus, from the whole testing profession. Those who disagree with the need for ISO 29119 and its underlying approach have been ignored. The opponents have been defined as irrelevant.

If ISO 29119 were expanding the market, and if it merely provided another alternative — a fresh option for testers, their employers and the buyers of testing services — then there could be little objection to it. However, it is being pushed as the responsible, professional way to test — it is an ISO standard, and therefore, by implication, the only responsible and professional way.

What is Wrong With ISO 29119?

Well, it embodies a dated, flawed and discredited approach to testing. It requires a commitment to heavy, advanced documentation. In practice, this documentation effort is largely wasted and serves as a distraction from useful preparation for testing.

Such an approach blithely ignores developments in both testing and management thinking over the last couple of decades. ISO 29119 attempts to update a mid-20th century worldview by smothering it in a veneer of 21st century terminology. It pays lip service to iteration, context and Agile, but the beast beneath is unchanged.

The danger is that buyers and lawyers will insist on compliance as a contractual requirement. Companies that would otherwise have ignored the standard will feel compelled to comply in order to win business. If the contract requires compliance, then the whole development process could be shaped by a damaging testing standard. ISO 29119 could affect anyone involved in software development, and not just testers.

Continue Reading

Testers Aren’t Psychic: Six Ways Developers Can Be More Transparent With Testers

Dear Developers:resized_business-cat-meme-generator-i-m-good-but-i-m-not-psychic-d50a02

Testers aren’t mind readers.  We’re not psychic or telepathic, either.  Please write your test cases and review our bug reports accordingly.

With Love,
Your QA Testers

Many testers dislike seeing the dreaded “Working as Designed” rejection reason on our bug reports because, in many cases, we had no idea it was designed to work that way.  To us, it just seemed like something wasn’t quite right, and it’s our job to tell you these things.

In fact, if a tester who has the perspective of a new user (someone who has no prior experience with what they’re testing and sees the environment in a way a brand-new user would) writes up a bug report on a feature that seems to be broken or working poorly, there’s a good chance new users will also think the same thing. Perhaps you should review the design and user experience to see if there’s a flaw there.

After all, quality assurance is not just about telling developers when a page errors or when a link is broken. It’s also about telling you when your software does not work in such a way that a user will find it to be a useful, quality, worthwhile experience.

It might seem like a pain in the butt, but we’re really just trying to do our jobs and help make your project a complete success.  Really! We’re on the same team, I promise.

When you ask us to test something for you, try and do the following things. They will help us help you and, in turn, your projects:

Continue Reading

Using Software Testing Metrics in an Agile Environment

Note: The following is a guest submission to the uTest Blog from Sanjay Zalavadia.software-testing-company-1234

Agile QA teams should use specialized software testing metrics to make sure they’re on the right track.

Software testing metrics are a vital component of the quality assurance process, providing team leaders with the data needed to make informed decisions. Agile teams require their own set of specialized metrics to better track progress and ensure that they are getting the most value out of the testing methodology. One of the largest issues that organizations run into when leveraging agile is botching the implementation, typically by misusing a tactic or strategy. With the right testing metrics, QA teams making their first foray into agile can gain the oversight needed to deploy the practice in an effective manner.

Writing for Agile Atlas, veteran software engineer and lean development expert David Koontz offered several metrics that could benefit agile teams. Many of these measurements centered around sprints, giving QA leaders insight into the effectiveness of these testing processes.

For instance, test teams can use software testing metrics to track both the projected capacity and capability of upcoming sprints. Such insight will help businesses address one of the most common problems associated with agile methods: sprint mismanagement. Teams that are still getting acquainted with agile may wind up underestimating how long forthcoming sprints will last, resulting in longer-than-anticipated production schedules. By gathering data and laying out an accurate timeframe for test sprints, QA leaders can avoid running into costly release delays.

Continue Reading

Testers Are Spending a Whole Lot of Time…Not Testing

Before you get completely riled up by that statement and wasting_time_by_lawlieta-d3dc84ythink we’re calling testers slackers…we’re not! In fact, testers are quite up in arms about this un-productivity.

Based on a recent joint study by uTest, IBM and TechWell, testers are certainly spending a whole lot of time on non-testing-related activities, and testing activities that they simply feel are just a big, plain ol’ waste of time.

The study, conducted in April 2014 by TechWell, was made up of 250 software testing pros from six continents, and found that:

  • 36% of testers surveyed spend over half of their week not testing
  • 58% cite ad hoc requests as the biggest disruptor of their work weeks
  • In regard to activities where testers spend more time than they’d like, almost 60% responded with waiting for test assets, while over 50% responded with ‘non-testing’ activities
  • Some of the top activities testers wished they’d spend more time in include: creating and executing automated tests, performing exploratory testing, and designing and planning tests
  • Testers want greater organizational improvements, including increasing automation, in order to free up their time to focus on testing and improving quality

Continue Reading

Focus on Automated Testing, Discount for uTesters at UCAAT

Automation is a sector of software testing that has experienced explosive growth and enterprise investment in recent years. The knowledge necessary to learn about and specialize in automated testing is found at industry events like the upcoming 2nd annual User Conference on Advanced Automated Testing (UCAAT) in Munich, Germany from September 16-18, 2014. ucaat

The European conference, jointly organized by the “Methods for Testing and Specification” (TC MTS) ETSI Technical Committee, QualityMinds, and German Testing Day, will focus exclusively on use cases and best practices for software and embedded testing automation.

The 2014 program will cover topics like agile test automation, model-based tests, test languages and methodologies, as well as web of service and use of test automation in various industries like automotive, medical technology, and security, to name a few. Noted participants in the opening session include Dr. Andrej Pietschker (Giesecke & Devrient), Professor Ina Schieferdecker (Free University of Berlin), Markus Becher (BMW), Dr. Heiko Englert (Siemens), and Dr. Alexander Pretschner (Technical University of Munich).

Continue Reading

Are There Enough ‘Intellectual’ Software Testers?

imagesJames Bach is no stranger to tackling heated topics, and in general, being one of the most influential disruptors in the in the testing industry.

So it comes as no surprise that in a recent blog, James provided some fodder for a great discussion in the uTest Forums, arguing that there aren’t enough intellectual testers in the field — that is, testers that are willing to challenge themselves or the status quo:

“The state of the practice in testing is for testers NOT to read about their craft, NOT to study social science or know anything about the proper use of statistics or the meaning of the word ‘heuristic,’ and NOT to challenge the now 40 year stale ideas about making testing into factory work that lead directly to mass outsourcing of testing to lowest bidder instead of the most able tester.”

While there was a fair amount of pushback to this, a surprising amount of uTesters tended to agree, including one tester that even went so far as to call it a “pet peeve” of his. However, while agreeing with Bach’s assessment, these same testers argued that it isn’t necessarily their fault — it’s a product of their environment:

“To conclude, I believe that the issue lies with how projects are managed. If no time is left for more robust testing, then it almost doesn’t matter how intellectual or technically savvy a tester is if all he/she is going to have time to do is create and execute tests against specifications. In other words, intellectual testers don’t have much opportunity for more intellectual testing. A strong tester would not be able to showcase those skills in this environment.

Continue Reading

Stay Flexible: Top 3 Agile Development Best Practices

Note: The following is a guest submission to the uTest Blog from Sanjay Zalavadia.agile

Despite the general consensus among software developers that agile methods offer the best approach to quality assurance, many organizations continue to struggle with their implementation. Because agile practices differ so much from traditional waterfall processes, it’s understandable that some teams may run into obstacles during the transition. By keeping these top agile best practices in mind, struggling QA teams can get on the right track and begin to appreciate the benefits of the methodology.

  1. Be agile – This sounds like a no-brainer, but many programmers and testers lose sight of what it means to be agile. With all the different processes and tasks that agile teams carry out, individuals and organizations as a whole can get bogged down in the details. As IT service provider A.J. Boggs explained, it’s important to stay true to the spirit of the approach and not the nuts and bolts of the methodology. For instance, if a team is finding that its daily Scrums are difficult to coordinate and are not providing much of any value, maybe QA leaders should consider dropping them. Be agile, but don’t be beholden to the process.

Continue Reading

Q&A: Context-Driven Testing Champions Talk Trends, Preview Let’s Test Oz

Henrik Andersson and David Greenlees are two well-known contributors to the context-driven testing community and together co-founded the Let’s Test conferences, which celebrate the context-driven school of thought. Let’s Test Oz is slated for September 15-17 just outside Sydney, Australia, and uTest has secured an exclusive 10% discount off new registrations. Be sure to email testers@utest.com for this special discount code if you plan on attending.

In this interview, we talk with Henrik and David on trends in the context-driven community, and get a sense of what testers can expect at Let’s Test Oz.

19c4175HenrikAndersson

uTest: Like James Bach, you’re both members of the ‘context-driven’ testing community. What drove each of you to context-driven testing?

HA: Actually, James did. I had close to no awareness of the context-driven testing (CDT) community before I hosted James’ RST class in Sweden in spring of 2007. During my discussions with James, I found that we shared lots of fundamental views on testing, and he insisted that I should meet more people in the CDT community.

James told me about the CAST conference that took place in the States, and that just before this, there would be a small peer conference called WHET 4 that his brother Jon hosted. A few days later, I got an invitation from Jon Bach to attend. At this workshop, where we spent a weekend discussion on Boundary Testing, I met testers like Cem Kaner, Ross Collard, Scott Barber, Rob Sabourin, Michael Bolton, Dough Hoffman, Keith Stobie, Tim Coulter, Dawn Haynes, Paul Holland, Karen Johnson, Sam Kalman, David Gilbert, Mike Kelly, and, of course, Jon and James Bach. From then on I was hooked!

DG: Difficult question to answer without writing a novel! I wrote about my testing journey some time back, however, that doesn’t really touch on my drivers toward the CDT community. If I was to pinpoint one thing, it would be the book Lessons Learned in Software Testing (Bach, Kaner, Pettichord). This was my first introduction to the community and to what I believe is a better way to test…in fact…the only way to test.

What keeps me here is the fantastic people I come across each and every day. We challenge each other, we’re passionate, and we’re not afraid to put our opinions out there for the world to hear and critique. This all adds to the betterment of our craft, which is our ultimate goal. I’m a firm believer that there is no ‘one-size-fits-all’ approach to testing, and when you add that to my natural tendency to explore rather than confirm, I find that the CDT community is a great fit for me.

uTest: And speaking of James Bach, he’s one of the keynote speakers at Let’s Test Oz in the Fall. Can you tell us a little bit about the idea behind the show, and why you felt it was time for context-driven conferences in Europe and Australia?

HA: Let’s Test is all about building, growing and strengthening the CDT community. We have successfully arranged Let’s Test three years in a row in Europe, but the attendees are coming from all over the world. The idea behind Let’s Test is to create a meeting place for testers to learn, share experiences, grow, meet other testers, do some real testing, and, of course, to have a whole lot of fun.

When David Greenlees and Ann-Marie Charrett told me about what they were looking to achieve, I immediately felt that it was in line with Let’s Test, and believe Let’s Test can be a great vehicle to grow the CDT community in Australia.

Last year, we did a one-day tasting of Let’s Test in Sydney, and this year, we did one in the Netherlands. In November, we will be hosting one in Johannesburg, South Africa. The purpose of the small tastings of Let’s Test is for testers to get a glance at the Let’s Test experience, at a really low cost. If you cant come to the real Let’s Test, this is a great alternative to check out what it is all about.

DG: From the Australian point of view, it’s fair to say that the CDT community is very small. We refer to the area as ‘Downunder’ — this is our way of saying Australia and New Zealand. I felt it was time to change that, and one way to help the CDT community thrive is to hold a CDT conference.

For quite a few years now, I’ve felt that Downunder needed a different style of software testing conference, one where conferring is the ultimate goal, and so I emailed Henrik, and he was extremely positive and encouraging…so here we are.

Continue Reading