Changes between Version 1 and Version 2 of OpenVPN_QA


Ignore:
Timestamp:
06/29/11 11:52:42 (11 years ago)
Author:
Samuli Seppänen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • OpenVPN_QA

    v1 v2  
    33This page outlines the efforts taken to maintain OpenVPN's quality without excessive compromises on development speed.
    44
    5 = Static code analysis =
     5= Static whitebox testing =
    66
    7 [http://en.wikipedia.org/wiki/Static_code_analysis Static code analysis] is baked in into our [DeveloperDocumentation development process] in the form of mandatory ACK process every patch has to go through. In addition, OpenVPN codebase is scanned using [http://scan.coverity.com/ Coverity Scan] which can detect many potential security vulnerabilities.
     7Static whitebox testing usually refers to [http://en.wikipedia.org/wiki/Static_code_analysis Static code analysis], which is baked in into our [DeveloperDocumentation development process] in the form of mandatory ACK process every patch has to go through. In addition, OpenVPN codebase is scanned using [http://scan.coverity.com/ Coverity Scan] which can detect many potential security vulnerabilities.
    88
    99= Dynamic black-box testing =
     
    1111Dynamic black box testing means trying out an application and verifying if it works as intended. In closed-source software development which is organized around the [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] there are usually dedicated testers who do various scripted or intuitive tests to verify an application works as intended, usually just before launch. In complex applications such as OpenVPN testing even a small fraction of functionality would be impractical and very costly. However, in [http://en.wikipedia.org/wiki/Lean_software_development Lean software development] methodologies such as [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] and community-driven OSS development this kind of dedicated testing effort is unnecessary.
    1212
    13 In OpenVPN (and most other open source projects), the stability of stable releases (e.g. 2.1, 2.2) is ensured with ''real-life testing'' by it's users during development, alpha, beta and rc phases. Even though only a small subset of users will be running the development code or "unstable" releases, they will be able to catch the most obvious issues. As using compiling OpenVPN from development code (in Git) is difficult especially for Windows users, "unstable" releases are pushed out as fast as possible.
    14 
    15 The key to maintaining quality is pushing out "unstable" releases as often as possible 
     13In OpenVPN (and most other open source projects), the stability of stable releases (e.g. 2.1, 2.2) is ensured with ''real-life testing'' by it's users during development, alpha, beta and rc phases. Even though only a small subset of users will be running the development code or "unstable" releases, they will be able to catch the most obvious issues. As compiling OpenVPN from development code (in Git) is somewhat difficult - especially for Windows users - "unstable" releases are pushed out as fast as possible; this allows more people to test the releases, report bugs and fix issues, so that new releases can be made quickly.
    1614
    1715The project also has a [http://trac.buildbot.net/ Buildbot] buildmaster, which drives several buildslaves. Each of these buildslaves is running a different operating system, and every commit to the OpenVPN Git repository triggers a build on them. After the build, each buildslave's openvpn tries to connect to a test server using several different configurations, thus ensuring that basic functionality is unaffected by the commit.