Note: For technical task following labels must be set before starting of execution:
Technical Task
and
Priority: High or Priority: Medium or Priority: Low (by CCB; ersatz for story points)
and
Efforts: High or Efforts: Medium or Efforts: Low (by Contributor, after estimations; ersatz for story points)

Description

user story or the high-level idea of changes

Related Diagrams

Diagrams (for example sequence diagram) describing these changes must be attached

Links

Requirement: GitHub issue Number + summary (Example: #1 Requirement (for ex. AddCommand))
Parent task: Link to parent task issue + summary or empty

Expected delivery (Definition of Done)

Note: If particular part of delivery is not required, it must be marked (not required) as shown below

• Requirements updates
• Source code updates
• Code comments
• UTs add/update
• Integration tests add/update
• Manual tests (not required)
• Add/update CI plans/jobs
• SDD updates
• SAD updates
• Guidelines update (sdl_core_guides)
• Guidelines update (sdl_hmi_integration_guidelines)

Note: For technical task following labels must be set before starting of execution:
Technical Task
and
Priority: High or Priority: Medium or Priority: Low (by CCB; ersatz for story points)
and
Efforts: High or Efforts: Medium or Efforts: Low (by Contributor, after estimations; ersatz for story points)
and
Occurrence: Always or Occurrence: Often or Occurrence: Sometimes or Occurrence: Rare (by Reporter, during creation)
and
Severity: High or Severity: Medium or Severity: Low (by Reporter, during creation)

Description

Detailed description of problem if necessary

Preconditions

State of the system which has to be reached before starting test
Example:

• Core, HMI started.
• App is registered on HMI.
• Send ResetGlobalProperties from mobile.
• SDL sends to HMI UI.SetGlobalProperties request - OK
• SDL sends to HMI TTS.SetGlobalProperties request - OK

Steps to reproduce

Required steps for testing
Example:

1. Send HMI response TTS.SetGlobalProperties: SUCCESS without info parameter.
2. Send HMI response UI.SetGlobalProperties: SUCCESS with "info":"a"

Actual result

Observed behavior of the system
Example:
SDL transfer response of ResetGlobalProperties without info parameter.

Expected result

Expected behavior, must correspond linked requirement
Example:
SDL shall transfer response to mobile of ResetGlobalProperties with parameter "info":"a" from UI.SetGlobalProperties.

Environment

SDL commit:
OS with SDL:
VM used for OS with SDL (yes/no): (no by default)
ATF version:
Transport:

In case of manual testing
HTML5 HMI version:
Mobile device:
Mobile OS:
Mobile App:

Attachments

Logs of the system, configuration and everything else that might help to identify and solve problem.

Links

Requirement: GitHub Issue number + summary (Example: #1 Requirement (For ex. AddCommand))
Test script: link to GitHub repository or empty if absent

Expected delivery

Note: If particular part of delivery is not required, it must be marked (not required) as shown below

• Source code updates
• Code comments
• UTs add/update
• ATF tests add/update
• Manual tests (not required)
• Add/update CI plans/jobs
• SDD updates
• Guidelines update (sdl_core_guides)
• Guidelines update (sdl_hmi_integration_guidelines)

Note: For requirement following labels must be set before starting of execution:
Requirement
and
Priority: High or Priority: Medium or Priority: Low (by CCB)

Description

User story or the high-level idea of described feature
Detailed description: Link to GitHub with detailed document in MD format
Note: Following quote is the template for MD document with details

Use Case 1: The name of Use Case

Example: AddCommand processing

Main Flow

Pre-conditions

1. The text of related pre-condition
Note: there could be more than one pre-condition
Example: mobile app successfully registers on SDL

Steps

2. Description of step for user OR sequence
Note: there could be more than one Step
Example: app -> SDL: AddCommand (<param_1>, <param_2>)

Expected

3. Description of expected SDL behavior after Steps above
Example:
SDL invalidates request and send INVALID_DATA, success:false to mobile app
OR
SDL -> app: RPC (INVALID_DATA, success:false)

Alternative flow 1

2.1. Alternative flow for one of the steps above + expected SDL behavior in this flow
Describes alternative flow to Main flow described above.
Example: Main flow describes valid and allowed AddCommand
Alternative flow_1 -> app sends invalid request, for example

Alternative flow 2

Step N.N. Alternative flow for one of the steps above + expected SDL behavior in this flow

Related Diagrams

Diagrams (for example activity diagram) describing this feature must be attached

Links

Proposal: GitHub issue Number + summary
Parent requirement: Link to parent requirement issue + summary or empty

Description:
SDL doesn't check result codes of HMI IsReady response

Preconditions

1. SDL and HMI are started.

Steps to reproduce

1. At InitHMI_OnReady send IsReady response with (<<error_result_code>>, available = true)

Actual result
SDL accepts only available = true and interface is avalable, SDL doesn't check error_result_code

Expected result
SDL should accept interface if is NOT available

Environment
SDL repo: https://github.com/smartdevicelink/sdl_core/tree/feature/extended_policy_functionality
SDL commit: 7bd5326e8a6f5127220bf938a5be3063bdbb4ab4
OS with SDL: Ubuntu 14.04
VM used for OS with SDL (yes/no): no
ATF version: aa5beae6ab1726a9b43ed2fa15f66c20d7f7883f
Transport: WiFi

Links
Requirements:
[UI Interface] SDL behavior in case HMI does not respond to UI.IsReady_request
[RegisterAppInterface] SDL behavior in case HMI does NOT respond to IsReady request
[UI Interface] HMI does NOT respond to IsReady and mobile app sends RPC that must be splitted

Clarification: Does SDL consider case VR.IsReady response with errorCode is the same as case VR.IsReady is not responded