The industry standard would be something similar to the Secure Software Development Framework (NIST SP 800-218) . You will see four groups (Prepare the Organization, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities) and for each one of these groups you will have best-practices and associated tasks. You will also find multiple references related to each one of the practices. More on reddit.com

Get a linter for your language of choice and run it, the default settings should be okay. Then configure pre-commit and a co/cd pipeline to run the linter so everything is automated and people won't "forget" about it. More on reddit.com

My question is, what exactly do you NEED have by ISO 9001? to be honest, 9001 is pretty useless for quality to anyone with common sense, unfortunately many people don't have common sense so they ask questions as such, and often don't have a good sense of quality as a value (in the mathematical sense of the word) At its core, ISO9001 means you need to have consistency and documented thoughts on specific quality concerns. ISO is a standard's body, as a result it values adherence to standards. Values for quality are based on adherence to standards, these standards require you to make clear statements in stated artifacts if you are deviating so that what you do is in the framework of what is expected, even if you actually do it differently. After all, what are standards for if not to be broken. A good laugh for all the people that like to "feel" (deliberately used throughout rest of my reply) about what is necessary and what isn't. Suffice to say the people contributing to ISO are not stupid. This is about testing software which is in most cases very similar There is some severe misunderstanding if your organization is using ISO9001 as the model for SW quality. ISO9001 is about the quality of a business and just asks that you have a test plan, etc.... For software you want ISO 25000 witch tells you what is a standard criteria for evaluating SW (exhibit A hours of meetings where people argue about the latest "stability" or "robustness" or "stress" results and if you can ship). Specifically for general testing you look into ISO 29119 that have very SW specific contexts for the documents that you don't want to write. These two ISO standards significantly more value towards evaluating product quality instead of business processes for generating artifacts. but releases happen every X days and writing all of these documents is a pain in the ass.. If you follow standards it shouldn't be a pain in the ass, what is a pain is dealing with all the "special" people who think they have a reason to do things weird and cut corners so you need to summon them in meetings and do post postmortems and train best practices, etc... instead of having someone just go through a 20 item checklist, or even better automate the damn thing, especially if there is little change. Simply require the change data to be provided in the workflow/engineering product (source code comment, a pull request check and auto update by your CI system, etc...) If you are writing up ISO mandated documents by hand, I am amazed the company is ISO9001 certified and still in business. not to mention if something changes after you've already wrote them etc. Maintaining your work product is part of the quality, this includes regulatory or contractual audit trails, and your test plans when they are part of the product as a deliverable to the customers. Your argument allows permits the development team to feels the same way about bugs, "what's the point in fixing it when the change will just break something else, our test team didn't even bother to update the test plan" As someone who cares about quality in the things I buy, I am incredibly annoyed at where the world is going. Lack of pride in ones work is disappointing, especially when these same people feel they deserve more money than ever for some abstract intangible value that they feel they deliver with all the weirdness and useless slide decks they peddle More on reddit.com

One of the biggest issues with setting standards is getting buy in. You can’t actually force people to adopt, or if you do against their will they will half ass it or drop it the minute you stop applying pressure. The issue I see with your list is that it’s missing any sort of reason why that item is worth doing. Which is the most important part to getting engineers to buy into the standard. From a pragmatic perspective, you need to make incremental steps here. Start with the biggest pain points and standardize around those first. The stuff that literally everybody sees as a problem (hint: it’s probably not busywork like branch naming schemes). Once you get some traction and things are genuinely improving, you will gain trust to keep pushing further. More on reddit.com