Meego Wiki
Views

Quality/Test case template

From MeeGo wiki
< Quality(Difference between revisions)
Jump to: navigation, search
m (moved TestCaseTemplate to Quality/Test case template: page moved to correct place.)
m (→Fields in Test Case Template: Wiki link fix)
 
(4 intermediate revisions not shown)
Line 2: Line 2:
Purpose of test case template is to provide sufficient amount of information about test cases for the users. Intention is to keep test case template as simple as possible. Test case template does not contain any information about test execution schedule, intervals how often it will be executed or so. This is defined in test execution management tool(s) what ever they might be. The same template should be used despite the test case concerning UX or Core.  
Purpose of test case template is to provide sufficient amount of information about test cases for the users. Intention is to keep test case template as simple as possible. Test case template does not contain any information about test execution schedule, intervals how often it will be executed or so. This is defined in test execution management tool(s) what ever they might be. The same template should be used despite the test case concerning UX or Core.  
-
[[File:TCTemplate.JPG]]
+
[[File:TCTemplate.PNG]]
== Fields in Test Case Template ==
== Fields in Test Case Template ==
Line 8: Line 8:
Template contains following fields:  
Template contains following fields:  
-
* '''TC Title:''' (Mandatory) ''<Descriptive title for test case>''  
+
* '''TC Title:''' (Mandatory) ''<Descriptive title for test case>'' '''Shall be used by QA team'''
-
* '''TC ID:''' (Optional) '' <Test case unique identifier>''
+
* '''TC ID:''' (Optional) '' <Test case unique identifier>'' '''Could be used by QA team'''
** Can consist of characters, numbers or if test case name is unique this can be used as well  
** Can consist of characters, numbers or if test case name is unique this can be used as well  
-
* '''Requirement:''' (Optional) ''<Requirement reference>''
+
* '''Requirement:''' (Optional) ''<Requirement reference>'' '''Should be used by QA team'''  
-
* '''Type:''' (Mandatory) ''<Type of test case>''
+
** Field to have feature or bug ID's as comma separated list. This enables the linkage between tests and bugs.meego.com or any other requirement system items.
-
** Values: Certification, Internationalisation, Localisation, System Integration, Variant Testing, 3PO Testing, Services Testing, Functional, Latency, Response time, Frame rate measurement, Technical Benchmark, Benchmark, Memory consumption measurement, Throughput measurement, Load measurement, Power management, Low resource, Recovery, Iterative, Long-lasting, FIT (Feature Interaction Testing),User eXperience testing, Mobility testing, Long Period testing (LPT)
+
* '''Type:''' (Optional) ''<Type of test case>'' '''Shall be used by QA team''' ''update description''  
-
* '''Domain:''' (Mandatory) <Vertical>'''  
+
** Values: please refer to [[Quality/Test_areas_and_types]]
-
** Values: Common, Handset, Netbook, In-Vehicle, Connected TV, Media Phone
+
* '''Domain:''' (Optional) <Vertical> '''Shall be used by QA team'''
-
* '''Feature:''' (Mandatory) ''<Bugzilla Feature>''
+
** Domains are defined in http://meego.com/developers/meego-architecture/meego-architecture-domain-view
-
* '''Subfeature:''' (Optional)
+
* '''Feature:''' (Optional) '''Shall be used by QA team if Requirement is empty - otherwise Could be used'''
 +
** Free text describing the functionality tested.
 +
* '''Subfeature:''' (Optional) '''Could be used by QA team'''
** Can be used when test case designer wants to identify more detailed level what is tested.  
** Can be used when test case designer wants to identify more detailed level what is tested.  
-
* '''Component:''' (Optional) ''<Bugzilla Component>''
+
* '''Component:''' (Optional) ''<Bugzilla Component>'' '''Shall be used by QA team'''  
-
* '''Execution Type:''' (Mandatory) ''<Manual, Auto>''
+
* '''Execution Type:''' (Optional) ''<Manual, Auto>'' '''Should be used by QA team'''  
-
* '''Test Case State:''' (Mandatory) ''<Design/Ready/Approved>''
+
* '''Test Case State:''' (Optional) ''<Design/Ready/Approved>'' '''Could be used by QA team'''
-
* '''Description:''' (Mandatory)
+
* '''Description:'''  
-
** Purpose (Optional): <Test case purpose here. What is tried to achieve with this specific TC>
+
** Purpose (Optional): <Test case purpose here. What is tried to achieve with this specific TC> '''Shall be used by QA team'''
-
** Method (Optional): <Short description of TC method here, e.g., how measurement is done and what the result describes. Could be a link to another document. This field is optional>
+
** Method (Optional): <Short description of TC method here, e.g., how measurement is done and what the result describes. Could be a link to another document. This field is optional> '''Could be used by QA team'''
-
** References (Optional) :<Link to web, wiki or similar place where more detailed information is available (if any) for this TC>
+
** References (Optional) :<Link to web, wiki or similar place where more detailed information is available (if any) for this TC> '''Could be used by QA team'''
-
** Pre/Post-conditions (Optional): <Specific description of things or settings needed prior to this TC run. E.g. memory card in device and audio clip at path /home/user/audioclips>
+
** Pre/Post-conditions (Optional): <Specific description of things or settings needed prior to this TC run. E.g. memory card in device and audio clip at path /home/user/audioclips> '''Could be used by QA team'''
-
** Run instructions (Optional): <Run instructions specific for this TC. Describe instructions by steps (n) – refer to PASS / FAIL criteria for this step.>
+
** Run instructions (Optional): <Run instructions specific for this TC. Describe instructions by steps (n) – refer to PASS / FAIL criteria for this step.> '''Shall be used by QA team'''
-
** Pass/Fail criteria (Optional): <What are the criterion that TC shall fulfil in order to consider TC as passed. For instance, test case returns pass and audio is audible from wired headset. Describe PASS / FAIL criteria for each run step.>
+
** Pass/Fail criteria (Optional): <What are the criterion that TC shall fulfil in order to consider TC as passed. Describe PASS / FAIL criteria for each run step.> '''Shall be used by QA team'''
-
** Test Environment (Optional): <Link to a document describing manual or automatic test environment. No test cases having dependencies to corporate network or other proprietary SW / HW>
+
** Test Environment (Optional): <Link to a document describing manual or automatic test environment. No test cases having dependencies to corporate network or other proprietary SW / HW> '''Could be used by QA team'''
-
** Required test data (Optional): <Description of specific test data / parameters for this TC with unambiguous file references>
+
** Required test data (Optional): <Description of specific test data / parameters for this TC with unambiguous file references> '''Could be used by QA team'''
-
** Change history (Optional): <Description of modifications done to this TC, with name of author. Change history of last 5 changes at least>
+
** Change history (Optional): <Description of modifications done to this TC, with name of author. Change history of last 5 changes at least> '''Could be used by QA team'''

Latest revision as of 07:13, 18 February 2011

Contents

Test Case Template

Purpose of test case template is to provide sufficient amount of information about test cases for the users. Intention is to keep test case template as simple as possible. Test case template does not contain any information about test execution schedule, intervals how often it will be executed or so. This is defined in test execution management tool(s) what ever they might be. The same template should be used despite the test case concerning UX or Core.

TCTemplate.PNG

Fields in Test Case Template

Template contains following fields:

  • TC Title: (Mandatory) <Descriptive title for test case> Shall be used by QA team
  • TC ID: (Optional) <Test case unique identifier> Could be used by QA team
    • Can consist of characters, numbers or if test case name is unique this can be used as well
  • Requirement: (Optional) <Requirement reference> Should be used by QA team
    • Field to have feature or bug ID's as comma separated list. This enables the linkage between tests and bugs.meego.com or any other requirement system items.
  • Type: (Optional) <Type of test case> Shall be used by QA team update description
  • Domain: (Optional) <Vertical> Shall be used by QA team
  • Feature: (Optional) Shall be used by QA team if Requirement is empty - otherwise Could be used
    • Free text describing the functionality tested.
  • Subfeature: (Optional) Could be used by QA team
    • Can be used when test case designer wants to identify more detailed level what is tested.
  • Component: (Optional) <Bugzilla Component> Shall be used by QA team
  • Execution Type: (Optional) <Manual, Auto> Should be used by QA team
  • Test Case State: (Optional) <Design/Ready/Approved> Could be used by QA team
  • Description:
    • Purpose (Optional): <Test case purpose here. What is tried to achieve with this specific TC> Shall be used by QA team
    • Method (Optional): <Short description of TC method here, e.g., how measurement is done and what the result describes. Could be a link to another document. This field is optional> Could be used by QA team
    • References (Optional) :<Link to web, wiki or similar place where more detailed information is available (if any) for this TC> Could be used by QA team
    • Pre/Post-conditions (Optional): <Specific description of things or settings needed prior to this TC run. E.g. memory card in device and audio clip at path /home/user/audioclips> Could be used by QA team
    • Run instructions (Optional): <Run instructions specific for this TC. Describe instructions by steps (n) – refer to PASS / FAIL criteria for this step.> Shall be used by QA team
    • Pass/Fail criteria (Optional): <What are the criterion that TC shall fulfil in order to consider TC as passed. Describe PASS / FAIL criteria for each run step.> Shall be used by QA team
    • Test Environment (Optional): <Link to a document describing manual or automatic test environment. No test cases having dependencies to corporate network or other proprietary SW / HW> Could be used by QA team
    • Required test data (Optional): <Description of specific test data / parameters for this TC with unambiguous file references> Could be used by QA team
    • Change history (Optional): <Description of modifications done to this TC, with name of author. Change history of last 5 changes at least> Could be used by QA team


Example 1, Core Test Case for eMMC

  • TC Title: DATAFLOW-FS-Copy-File-eMMC-to-MMC
  • TC ID: DATAFLOW-FS-Copy-File-eMMC-to-MMC
  • Requirement
  • Type: Functional
  • Domain: Handset
  • Feature:
  • Subfeature: copy
  • Component: Kernel
  • Execution Type: Auto
  • Test Case State: Approved
  • Description:
    • Purpose: This case tests file can be copied from eMMC to eMMC
    • Method: Test case copies file from eMMC to eMMC, file block size 1kB, block count 1000
    • References: None
    • Pre/Post-conditions: Test asset and MIN test frame Work is installed to the device. Memory card must be mounted in device. Test must be executed as root.
    • Run instructions: Start 'min' in the shell of the device. Select a case, observe device, and check the test result from min and the log files. Or use command line format 'min -c -t <test case name>'.
    • Pass/Fail criteria: Test case returns passed if operation was succesfull. Result is logged into /var/log/tests/."
    • Test Environment: Handset device
    • Required test data: None
    • Change history:
      • 11 May 2010. (v.0.1.8) Added steps to test.xml. Tommi Toropainen
      • 21 Apr 2010. (v.0.1.7) Added new steps to OTS execution to get results on Test reporting tools, Removed tmp filesystem tests from OTS. Tommi Toropainen
      • 20 Apr 2010. (v.0.1.6) Changed filesystem partitions in configure file, Added Security file system test case. Tommi Toropainen
      • 15 Mar 2010. (v.0.1.5) Changed mass storage cases to use 1,6GB files. Tommi Toropainen
      • 1 Mar 2010. (0.1.4) added unmounting before formatting (do not format target or source by default) Tommi Toropainen

Example 2, UX Test Case for Browser

  • TC Title: Watching flash video via browser by using WLAN
  • TC ID: PJ114257
  • Requirement
  • Type: Functional
  • Domain: Handset
  • Feature: Mozilla Fennec Browser
  • Subfeature: copy
  • Component:
  • Execution Type: Manual
  • Test Case State: Design
  • Description:
    • Purpose: Purpose of this test case is to verify that it is possible to watch flash video via browser by using WLAN.
    • Method: Test case is run manually
    • References: www.youtube.com
    • Pre/Post-conditions: WLAN Access Point is available. Browser application is opened
    • Run instructions:
1) Open webpage where flash videos can be watched (youtube.com)

Expected: Web page is displayed with flash videos

2) Start watching some flash video on the web page.

Expected: Flash video can be watched with proper audio and video.

3) Stop watching flash video.

Expected: Flash video playback should be stopped and web page with videos should be displayed.

4) Close the browser application.

Expected: Browser application should be closed successfully and home page is displayed.

    • Pass/Fail criteria: It is possible to watch flash videos via browser by using WLAN
    • Test Environment: Open WLAN network
    • Required test data: None
    • Change history:
      • 9 Jun 2010. (v.0.1) Test case skeleton created, basic information included. Petri Jylhä
      • 6 Sep 2010. Test Case should contain simple and meaningful steps and coverage should be good enough. Added expected result for each step. Reena
Retrieved from "http://wiki.meego.com/Quality/Test_case_template"
Personal tools