Software Verification is another of those regulatory buzzwords. Unless you’ve worked at an enterprise company before, chances are that you have no idea what it means.

Surprisingly, Wikipedia has an entry on it so I’ll just cite it:

Software verification is a discipline of software engineering whose goal is to assure that software fully satisfies all the expected requirements.

Totally clear, right? Not quite.

Let’s look at an example. You’re building a Covid-19 tracking app. You’ve written some [software requirements]. Those software requirements specify behavior of your software.

Now one of your developers starts working on it, writes some code and opens a pull request on GitHub. The stage for software verification is set. Exciting!

The goal now is to ensure that the specifications have been met. In human language: Have you written the correct code which works as intended?

How could you prove that? Here are some ideas.

Examples for Software Verification Methods

• Code review: Another developer reviews the code based on criteria which you’ve defined beforehand (best case: In your software development plan). Successful review (= approval) means that verification was successful. In other words: The reviewer says “yeah this code looks like it’s up to specifications”.
• “Static analysis”: You run a linter / code style tool, like RuboCop or ESLint. Note that this isn’t “static analysis” in the strict sense; real static analysis tools are usually geared towards old-school languages like C++ and have way more capabilities, like proving that your program is actually correct. In many “modern” and dynamically-typed languages like Python, Ruby and JavaScript, such tools are often not available. But using a linter / formatter often makes sense and could help you catch bugs.
• Unit / Integration Tests: You write some tests and execute them on the code base which includes the new change proposed in the pull request. This can be easily set up in GitHub (or GitLab) by choosing a Continuous Integration services like Travis CI or CircleCI.

So what should you choose in practice? Here’s what I would propose:

If you team has more than one developer, always do code review. It’s an easy win regulatory-wise, improves your code quality and gives developers opportunities for peer learning.

If your programming language has a well-accepted linter / code formatter, consider using that. There’s no golden rule here. For very dynamic, meta-programming-heavy languages like Ruby, developers may be annoyed by it and it might not provide a lot of value. For languages which make it easy to write broken code (JavaScript), those may be a good choice.

Write unit and integration tests. If you’re using a framework like Django or Rails which is batteries-included, the barrier of entry is incredibly low. Such frameworks often already have an integrated test suite with ready-to-use integration test setups (e.g. Rails + Capybara). If you have to roll your own, it’s more painful, but that’s what professional software development is about :)

Software Verification vs. Software System Testing

Ready for some confusion? The 62304 also requires Software System Testing. How is this different from software verification if that already covers unit and integration tests?

Tricky. I don’t know. Here’s what I’ve seen in practice: Software verification is done on each code change, e.g. each time a pull request is opened on GitHub. It’s code review and “the stuff which runs automatically”, like CI tests. Software system tests on the other hand are only done before you release a new version to the public. Those tests must cover all of your software requirements. And not all of your software requirements are covered by pull request and your CI pipeline. For example setting up a firewall may be a software requirement, but there may be no code for it. You still have to “test” (or at least prove) it. That would be the software system test. In this case, a screenshot of the correctly configured firewall may suffice.

Software Verification vs. Software Validation

Software Validation is another buzzword. Luckily, the 62304 doesn’t mention it, but it is often mentioned in the context of medical device software.

Wikipedia to the rescue, again:

Software verification asks the question, “Are we building the product right?”; that is, does the software conform to its specifications? (As a house conforms to its blueprints.)

Software validation asks the question, “Are we building the right product?”; that is, does the software do what the user really requires? (As a house conforms to what the owner needs and wants.)

And the good news is that you cover validation during your usability tests which you need for 62366 compliance anyway.