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.
