Will the new ISO/IEC 29119 Software Testing standard work with agile methodologies like Scrum?

Question

I somehow stumbled across some references to the new ISO/IEC 29119 Software Testing standard that is currently draft stage (apparently).

I have not seen the details of this new standard, however I would expect that a truly modern testing standard should not just acknowledge, it should embrace agile development practices, so that it can be applied in such a way that you can be in compliance with the standard whilst using Agile methodologies like Scrum.

Has anyone "tested" the new standard and actually applied it to an Agile project? Will the new ISO/IEC 29119 Software Testing standard work with agile methodologies like Scrum?

Edit: Whilst James' point of view is interesting, it doesn't actually answer the question. I would like to hear from people who have actually used it.

Answer 1

This "standard" is being created in the face of direct and repeated pleas by citizens of the Context-Driven testing community to cease and desist.

Whatever this thing says or is based on, it will not be based on a truly representative community of testers, nor will it be based on research that passes muster among competent social scientists.

It's yet another tool that will be used by European testing consulting companies to blind their clients and promote outdated, ignorant, and abusive testing practices.

We don't need a standard of software testing. We need communities of testers who study the craft and push it forward. Please join me in boycotting stupid standards.

Answer 2

Why only then think about Agile being complaint with this piece of standard,why not context driven school of testing,why not TDD,why not scripted testing ?

I do not think a 'blanket' compliance is possible or even a good thing to do .

Reason being that each project,organization,business,technology has a different standard & nature of expectations from a testing exercise.

Having said that,there are also occasions when "standards" do get applied in some industries , but they are usually technology standards driven by business needs rather than process/activity standards.

example - I work in a company which manufactures HW and SW for public safety radios(police,fire safety,power,military) .Now,the technology is an open standard and the standards organization has mandated it that the technology should be an open standard to encourage interoperability between manufactures.Hence an important part of the testing activity is to execute a bunch of heavily controlled tests that pass a set of standard documents.However,this is done because all the manufactures have been consulted by the standards authority and taken on board before the standards are published.And the manufacturers accept it because they see this as a way to move their business forward and reduce monpoly.

However,seems like this particular set of test standard does not exactly represent the broad spectrum of testing experts or people from various 'schools' of testing. (Inferring from James Bach's comment)

Answer 3

I have excellent news for all of you - I do have access to the Jul 2011 draft and I can safely say that Agile testing is reflected in all of the case studies ("annexes") in 29119-3. Specifically, the contrast between two notional large organizations: "Agile Corp" and "Traditional Ltd" and their testing approaches. Here's something that should bring a smile to every Agile practitioner's face: an IEEE standard that features examples like the following:

Test report for: New subscription system (NSS)

Vers.: Sprint 3

Covers:

NSS final sprint result, including result of previous sprints, in preparation for a major customer delivery (for use).

Risks:

The live data risk was retired by creation of a simulated database using historic live data “cleaned” by the test team and customer.

Test Results:

Customer accepted this release of the product based on: 16 user stories with one added after last status report were successful. Technology facing testing with the one high risk story 100% statement coverage was achieved, and for the others 72% statement coverage was achieved on average. Team accepted the backlog on 4 defects of severity 3. Showcase was accepted by the customer with no added findings. Showcase demo sprint features interfaced with “live” data. Performance of the sprint features were found to be acceptable by team and customer.

New and changed risks:

Security of the system may become an issue on future sprints, assuming a follow work task is received from customer

Notes for future work from retrospective:

Sprint team feels a new member may be needed given possible new risk since no one has knowledge in this area. Severity 3 defects that move on to backlog should be addressed in next sprint to reduce technical debt The modified live data worked well and should be maintained. Test automation and exploratory testing is working, but added techniques should be considered, e.g. security and combinatorial testing.

Enjoy!

Answer 4

As a former tester and now a QA Manager I have worked for over 15 years testing and managing the testing of very complex Geology and Geophysics interpretation software. My test team are all geoscientists first and testers second since you have to have an advanced degree to understand what the software is doing. I worked on a team using RUP, and we were ISO 2000 certified. Talk about the tail wagging the dog. As a team lead, at a major oil services company who produced GeoFrame and now Petrel, I can say the standard, the ISO2000 standards that is, drove everything. The organization was so focused and preoccupied with complying with the standard that more time was spend in worthless meetings, creating artifacts and jumping through the hoops dictated by the standard than doing constructive testing.

Now using Scrum Agile in a different company, the testing is much more streamlined and effective. We are putting together a testing standard for Agile, as part of our Definition of Done for user stories and iterations. We found that the QA team was geing forced to carry forward a lot of technical debt in the form of uncompleted workflow test cases, that could not be completed until all the functionality was in place from the last iteration. It is kind of Catch-22. Can't complete the test cases until all the coding is completed and can't close all the user stories until all the test cases are completed.

I am taking great pains that we do not create a testing standard that puts us in a straight jacket or becomes the tail that wags the dog.

Answer 5

I'm a newbie in software testing and would like to express my view on this.

Some developers/programmers/business people believe that software testing is a "low-end" IT job because they "think" everybody can do testing! They consider it as a "no-brainer" job.
Of course, we know it's wrong. Good QA/Testing requires lot of advanced skills and professionalism.

With this ISO standard, we can finally show them(people who believe everybody can do testing) that QA/Testing is NOT a low-end no brainer job. WE HAVE A STANDARD. WE ARE PROFESSIONAL!(Your boss will treat you as a professional!)

All I can say is we are living in a "dark" world run by Business people. In order to push the QA industry forward, "unfortunately" we need to have a standard to convince them.