Wondering if anyone has had any direct experience, in implementing all/elements of ISO 29119; into Test Strategy, at either company or product level?
Currently building out Test Strategy, for customer product - where they are extremely detail oriented; so thinking a shared language based upon a standardised approach, would be beneficial.
Normal practice, in company is for singular page Test Plans etc - where readability is paramount.
So this would be a shift from usual approach - for isolated products (dependent on customer approach).
Hoping for some feedback, before putting in a request to purchase
Firstly I’m assuming it’s 29119, I don’t think there is a 92119 but please correct me if I’m wrong - it’s happened before.
I went back and forth a few times before I decided to post this. I don’t want to ignore your question, and I don’t want to answer a different question, but 29119 faced enormous opposition from software testers, including myself. It feels dismissive of your question, and the research and decision making that got you this far, to bring up the stop 29119 movement, but it also feels lacking to not mention it either for you or perhaps others that might be here researching it. So I’ve decided to just include a few resources about 29119 from well-known and respected software testers and testing groups on the problems with 29119, the petition to stop it, and the manifesto that was written because of it.
Sorry that I can’t be of further help, and I hope that if you go ahead with the implementation that you find the resources you need and I also hope I haven’t caused offense or assumed too much. From my perspective this is me trying to be helpful, and I wish you the very best of success in every possible case.
Video: Standards - promoting quality or restricting competition? - James Christie
Thanks @kinofrost
Certainly meant 29119 - appears “Friday brain” kicked in early this week!
Plenty of reading to be done there; really appreciate that considered response
Wasn’t aware of such widespread opposition, to that particular set of standards - mainly as we don’t advocate using such within our company.
Query was definitely centred around very specific customer deliveries, that appear to based on more monolithic, standards based documents.
Certainly some food for thought though, once I get my way through all the links you’ve provided.
Thanks!
I can’t do codes myself, I was as worried I’d made a mistake as assuming the correction. If they’d called it Operation Bobcat or something we’d not have this issue.
Do you know why they’re being difficult? Detail-oriented means a lot of different things to me. Sometimes they ask a lot of specific questions, or want detailed metrics you can’t provide. Some detail-oriented people are just being deliberately annoying to apply pressure, usually when they cannot provide the reason why they’re asking something. Sometimes they’re just thorough.
Often being hung up on terminology and specifics is a kind of paranoia that comes out of previous difficult relationships, and sometimes a discussion about trust and what you can do to make them comfortable can save the day. It’s probably worth examining if you’re going to be spending a lot of time with them, and if you’re going to have a lot of added cost with additional paperwork, training, and corseting your testers with stuff that isn’t testing on top of the initial outlay.
I think you can communicate a test strategy in an official-sounding way. A standard is just a way of putting things written by some other human somewhere, you can make up your own for free. Let me put it this way - there is a hobby lockpicking group in Germany that gives its members very official looking membership cards, not because it has any official recognition, but because police officers who find lockpicks on you are calmed and assuaged by the official-looking plastic. You can have the lockpicking ID of test strategies.
I’d start with a list of what you want to communicate to the customer, so that your document (communication device) covers your intent.
I did some digging and I found a publicly available copy of the RST appendices (on James Bach’s website) that includes example test plans, which in turn will include some elements of test strategy. I think they’re good examples of how to formalise tacit structures in a way that pleases the official-minded, and I offer it for what it’s worth: RSTE Appendices - Satisfice, Inc.
A bit of a tl;dr going off my memory of much of the 29119 stuff is that a big reason not to use it is that not only does it require a mountain of paperwork that isn’t actually useful in finding problems with product quality, but if you say you’re going to follow it, that means you’re now on the hook for whatever mistakes you make in attempting to generate said mountain of paperwork. And you’ll inevitably either end up making those mistakes because there’s more paperwork than you can keep up with, or you’ll spend all your time on the paperwork and have no time left to actually…do testing.
the short of it, if you don’t want to incur operational overheads when going ISO, just hire someone to do the paper work. Most people use external bodies where possible, because it slows devops teams down a lot, especially if you have staff turnover. It also assumes that you are wanting to find the same kinds of product risk that the CODE was designed to find. No 2 businesses ever have identical risks, so there is rarely 1 code for them all.
We are also going for a different ISO code ourselves, but so far the dedicated person doing the work has kept us out of it with exception of security requirements and a few other perfectly necessary odds.
Not familiar with 29119 but we have to do lots of paperwork for our stuff under 62304 as a medical device. If it has to be done no point railing against it: just make it as easy as possible for yourself to comply. Automate as much of the documentation as possible, regularly check your test management tool has the data you will need to do that. All of these things are easier to do “as you go” rather than in one big lump at the end. And in medical at least its fine to deviate from your plans/strategy as long as you record and justify those deviations.
