The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)


Quality/Development

From Mer Wiki
< Quality(Difference between revisions)
Jump to: navigation, search
(Guidelines)
 
(8 intermediate revisions by one user not shown)
Line 1: Line 1:
= Development =
+
= Guidelines =
  
== Tools ==
+
Test package is a RPM package that includes scripts, binaries and/or libraries for testing a feature or function.
  
'''OBS'''
+
* Test package's name must use <packagename>-tests[-*] format
 
+
** eg. bluez-tests or bluez-tests-unittests
The Mer Tools are divided to two groups:
+
* '''Doesn't''' have to depend on testrunner
* Host (SDK) and device side tools ('''Mer:Tools''')
+
* Test-definition is not required, however recommended
* Server side tools ('''Project:MINT''')
+
** Test package can have not approved or failing test cases
 
+
** Test package's test-definition should be installed to '''/opt/tests/<packagename>/test-definition/'''
Host and device side tools are compiled '''only''' against the Mer repositories. By this we try to keep the tools version's stable and avoid conflicts with the host distribution's packages (eg. Ubuntu/OpenSuse/Fedora). In addition, the Mer SDK can be used for testing.
+
* Test package's files should be installed to '''/opt/tests/<packagename>/'''
 
+
* If test package provides some common test data (audio, video, image) those files should be installed to '''/opt/tests/<packagename>/{audio, video, image, text etc}/'''
The server side tools are provided for the most common Linux distributions. These are the tools that don't work in the Mer SDK, like OTS (Test automation system).
+
 
+
 
+
'''Development'''
+
 
+
* Unstable host (SDK) and device side tools are updated to '''Mer:Tools:Testing'''
+
* Unstable server side tools are updated to '''Project:MINT:Testing'''
+
* Packages that are shared between Mer:Tools and Project:MINT should be 'mastered' in Mer:Tools
+
 
+
As a developer:
+
# Search the tool's version control location [[:Category:About|About]]
+
# Pull the tool's source code and make changes
+
# Copy the original package to your home project in OBS
+
# Update your changes to the OBS
+
# Test your changes
+
# Push your changes to the version control
+
# Inform tools team about the changes with changes diff (URL to gitorious/gerrit/github diff)
+
# The tools team will review, retest and update the tool to OBS
+
 
+
== Tests ==
+
  
 
'''OBS'''
 
'''OBS'''
  
Tests are divided to 2 groups:
+
* Host (SDK) and device side tools to [http://build.merproject.org/project/show?project=mer-tools%3Adevel mer-tools:devel]. Once package is tested and you are happy with it create submit request to [http://build.merproject.org/project/show?project=mer-tools%3Atesting mer-tools:testing]. Please contact lbt from freenode IRC if you have questions.
* Architecture domains (Communications, Graphics, etc. )
+
* Normally tests are packaged in the same repository than actual test target, but if you have independent test software those should locate at [http://github.com/mer-qa mer-qa] GIT repository. Repositories are webhooked to [http://build.merproject.org/project/show?project=mer-qa%3Adevel mer-qa:devel] OBS project. Please contact mkosola or kontio from freenode IRC #nemomobile to create git repos and wehooks to OBS.
* UX (for GUI testing)
+
  
 
+
= Test development =
'''Development'''
+
  
 
As a developer:
 
As a developer:
# Search the test version control location (no info yet)
+
# Search (or ask) the test's version control location
 
# Pull the test's source code and make changes
 
# Pull the test's source code and make changes
 
# Copy the original package to your home project in OBS
 
# Copy the original package to your home project in OBS
 
# Update your changes to the OBS
 
# Update your changes to the OBS
# Test your changes, '''Note:''' Only passing test cases are accepted!
+
# Test your changes
 
# Push your changes to the version control
 
# Push your changes to the version control
 
# Inform QA team about the changes with changes diff (URL to gitorious/gerrit/github diff)
 
# Inform QA team about the changes with changes diff (URL to gitorious/gerrit/github diff)
 
# The QA team will review, retest and update the tool to OBS
 
# The QA team will review, retest and update the tool to OBS
 +
# The QA team will select and approve tests for package and release testing
 +
  
 +
As a QA team member:
 +
# Review and test submitted / changed test cases
 +
# Approve only passing and useful test cases. For failing test cases, inform the developer and/or file a bug/task
 +
# Update package's test-definition and add approved test cases to package/release test plan
  
 
[[Category:QA]]
 
[[Category:QA]]

Latest revision as of 12:18, 16 December 2013

[edit] Guidelines

Test package is a RPM package that includes scripts, binaries and/or libraries for testing a feature or function.

  • Test package's name must use <packagename>-tests[-*] format
    • eg. bluez-tests or bluez-tests-unittests
  • Doesn't have to depend on testrunner
  • Test-definition is not required, however recommended
    • Test package can have not approved or failing test cases
    • Test package's test-definition should be installed to /opt/tests/<packagename>/test-definition/
  • Test package's files should be installed to /opt/tests/<packagename>/
  • If test package provides some common test data (audio, video, image) those files should be installed to /opt/tests/<packagename>/{audio, video, image, text etc}/

OBS

  • Host (SDK) and device side tools to mer-tools:devel. Once package is tested and you are happy with it create submit request to mer-tools:testing. Please contact lbt from freenode IRC if you have questions.
  • Normally tests are packaged in the same repository than actual test target, but if you have independent test software those should locate at mer-qa GIT repository. Repositories are webhooked to mer-qa:devel OBS project. Please contact mkosola or kontio from freenode IRC #nemomobile to create git repos and wehooks to OBS.

[edit] Test development

As a developer:

  1. Search (or ask) the test's version control location
  2. Pull the test's source code and make changes
  3. Copy the original package to your home project in OBS
  4. Update your changes to the OBS
  5. Test your changes
  6. Push your changes to the version control
  7. Inform QA team about the changes with changes diff (URL to gitorious/gerrit/github diff)
  8. The QA team will review, retest and update the tool to OBS
  9. The QA team will select and approve tests for package and release testing


As a QA team member:

  1. Review and test submitted / changed test cases
  2. Approve only passing and useful test cases. For failing test cases, inform the developer and/or file a bug/task
  3. Update package's test-definition and add approved test cases to package/release test plan
Personal tools