Changes to the Process and Workflows of openPETRA Development

From OpenPetra Wiki
Revision as of 14:43, 25 January 2011 by Thiasg (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Interesting links

Motivation

  • We want to avoid bugs in the code base.
    ⇒ Less unplanned support in the long run
  • We want to avoid that fixed bugs re-occur
    ⇒ Better user experience
    ⇒ Finshed features stay finshed
  • We want to avoid making the same mistakes
    ⇒ Each developer/tester learns
  • Fixing bugs in a early stage of the development is cheaper then fixing it later on
    ⇒ Test early and often

Conclusion

  • Tests should to be done in an environment, which is the as similar as possible to the environment of the end user.
    ⇒ Definition of primary platform (OS, .net release, database incl. version and OS)
    ⇒ Test on this platform with the code to merge before merging to master and after rebasing
    ⇒ Test on this platform with the same code after merging to master, preferable on a build server (classified environment).
  • It should be easy to test and to find regressions early
    ⇒ Introduce automatic unit tests, which could be run on the build server.
    ⇒ Each new feature should be tested by an automatic unit test. In the short run, it seems to be costly, but it pays off very fast:
    • You will test more deeply and find more bugs before committing them into your code managing system (git).
    • You will find regressions when you introduce them helping to avoid them.
  • For every commit, the test done needs to be documented e.g. by screen shoots (manual test) or by adding the log files of the automatic tests.
    • If a bug occurs and normally this should have been tested, then you are able to find the reason, why it did not occur in the original tests. This helps in improving the test strategy and the process.
  • Everybody, who is finding a bug, should be able to add it to the bug tracker. The bug needs to be evaluated by a triage team (normally three person representing the product manager (requirements), development and testing team), if it is a bug, if it needs to be fixed or if it is postponed. If the bug needs to be fixed, it should be assigned to the development team and should be fixed before further feature development.