I should follow ISO 12207 but how should I verify integration/code without testing?
I am forced to follow ISO 12207 for systematic approach. I have been reading a lot here and found similar questions, yet not the same one and definitely not any suitable answer. According to this norm, I should verify that: code is testable, correct, follows standards implements correct data and control flow, timing... The first is clear but for the second point, how can I verify the correct control flow without testing? Because testing is by this standard defined as a validation activity in the different section. The only thing I can think of would be static analysis. And the same for integration, I should check that "components are fully and correctly integrated into the system..". How to do that without performing any testing? If I get this standard right, then all including unit testing is validation (verifying the logic is correct regarding the intended use of the product).
The short answer You've been tricked into asking the wrong question by a process that is not designed to actually provide you any guidance your day-to-day tasks. See the pithy Q&A on the Programmers site for a pragmatic take on this: https://softwareengineering.stackexchange.com/questions/175393/iso-12207-verification-of-integration-and-unit-test-validation The "correct" (but probably useless) answer You "follow" ISO 12207 by using the vocabulary it defines, and identifying which parts of your process map to that vocabulary. That is all. From the ISO/IEC 12207 article on Wikipedia: The standard has the main objective of supplying a common structure so that the buyers, suppliers, developers, maintainers, operators, managers and technicians involved with the software development use a common language. This common language is established in the form of well defined processes. (emphasis added) To be clear, ISO 12207 never tells you how to do anything; it is completely silent on implementation details. It's just a big glossary, combined with an ideal process map. Here's a quote from a short 2002 paper on integrating ISO 12207 with the Rational Unified Process (RUP), titled "How the Rational Unified Process Supports ISO 12207": These classes [of processes] can be organized in views, and decomposed into activities, themselves decomposed in[to] tasks. ISO 12207 stops, however, at the level of activities and it only occasionally mentions specific tasks, although never in a mandatory fashion. So, if you're performing "Module Testing" during the "Software Development" phase, congratulations: you're following ISO 12207! That's true even if you define "Module Testing" to mean flicking jelly beans at your keyboard, and "Software Development" to mean coming into the office and browsing Pinterest all day. A slightly more useful answer There are practical ways to approach this, if its really necessary. Here's a few I can think of. All of these have had some non-zero value for me on one or projects: Static analysis (as you already mentioned) Code inspections (peer reviews) Architecture reviews: comparing modules to block/UML diagrams, for example Inspection of the dependency injections or plugins, like Spring framework artifacts, for example Bill of Materials (BoM) verification: checksums, file manifests, third-party libraries, etc. Worse than useless if not automated. And a couple that I've had to do, but never really seen any value from: Requirements mapping: tracking which functions or tests cover which written requirement(s) Functional hand-offs: formal release of build/package artifacts to QA, a.k.a. "throw it over the wall and run"