SA2.4 ETICS testing plan


  • Unit test: All new software has to have unit test attached. See below, in Unit Testing section, some useful links about unit testing. It is obvious the developer have to do also others tests before commit the new code.
  • Create a new entry in the Release notes: Each bug solved or new featured has to be added to the release notes section. See below the section How to add changes to the release contents for more information about how to add the changes and what information do you need to provide.
  • Final testing: At the end of the sprint, a person different from the developer has to test it. See the section Testing changes for more information.
  • Code reviews: I propose, at the end of each sprint, take one of the pieces of code created/modified and do all together a code review. In that daily meeting we decided which piece (it would be nice to rotate and take each time a piece from a different person, so all of us can receive some feedback), and 2-3 days later we do the review.
  • Regression test: at the end of the sprint, the complete set of regression tests done previously by Alberto Aimar should be executed and compared with previous results (to be defined who has to run those tests).

Unit Testing

How to add changes to the release contents

  • Each bug solved or new featured has to be added to the release notes section together with a short description and how it has to be tested. Examples (HTT means "How To Tested"):
    • Bug about permissions: an error was reported when project permissions are trying to be removed in the user permissions list in the administration tab. HTT: try to remove the project permission of a user using different permission combination.
    • Information edition before resubmit: a new feature was introduced in the submission tab. Now it is possible to edit some job information before resubmit. HTT: resubmit modifying different information fields.

Testing changes

  • One team member different from the one who developed the modification has to test it.
  • To know what and how to test it, he has to follow the information in the release contents page. If it is not clear enough, he has to contact the developer.
  • If all tests are ok, the tester has to prefix, in the Release contents page, the entry with "[TESTED by XXX]". XXX is the tester's name abbreviation.
  • At the end of the line, just after how to test it, the tester must describe which tests have been done. Example: "..... Tested using a user with system administrator and module administrator in the project, another one only module administrator in the project and a last one with no privileges on it. The removing of the configuration was correct in the 3 cases"

-- AndresAbadRodriguez - 08-Sep-2010

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2010-09-08 - AndresAbadRodriguez
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback