Document version 0.0
Status: Test development in progress
Document Version | Description | Date |
---|---|---|
0.0 | Initial version | 05/14 |
0.1 | Test |
References
Related Tests:
Summary
This document details the tests for Incident Response plugin v0.5.0. The tests are derived from the user stories in Incident Response overview. The MVP of the Incident Response plugin will be tested against all tests included in this test plan.
Scope
This document covers the cases for the user stories as outlined in the Incident Response MVP Overview for v.0.5.0 of the plugin only.
Glossary
Admin - A user with system administrator privileges.
Normal user - A user with non-system administrator privileges.
Test Server - A list of test server versions used in testing including Mattermost server and Marketplace Server
Main menu - Hamburger menu on the LHS.
Incident Response icon - The Incident Response plugin icon that appears on the channel header
Commander - The user who owns an incident. The user who starts the incident is designated the commander by default.
Incident member/incident channel member - A user who has been added to the incident channel.
Non-incident user - A user who has not been added to the incident channel.
Active incident - An incident that has not been ended.
Ongoing incident - Same as Active Incident.
Inactive incident - An incident that has been ended.
Incident RHS - The RHS sidebar that opens upon clicking the incident response icon and displays incidents.
Incident Backstage - The backstage view that shows the incident list.
Playbook Backstage - The backstage view that shows the playbook list.
Assumptions
The tests in this test plans are written with the assumption that:
The tests outlined in this document is to be executed against the Incident Response plugin v0.4.0.
This version of the plugin can be installed and used in Mattermost instances that aren’t equipped with any enterprise license.
The Incident Response plugin can function as a standalone plugin that does not require to talk to any other plugin.
This version of the Incident Response plugin will function properly only in the latest version of Mattermost.
The tests will be executed in the latest version of Mattermost.
Testing is primarily done on the webapp, with spot checks on the desktop app, RN mobile app and mobile web browser app.
The tests in this document are executed as a normal user (see glossary above) unless otherwise specified.
The test cases that pass for a normal user will also pass for a system administrator.
Plugin uploads is enabled in server instance
“EnableUploads” option under “PluginSettings” in mattermost-server’s config.json is set to 'true'.
The channel export feature defined in the user story is dependent on the existence of the Channel Export plugin being installed and enabled in the test server.
Private channels cannot be converted into public channel, hence private incidents cannot be converted to public incidents.
Setup
Document Setup
For the practicality of running tests easily, test cases are arranged in sequential order when necessary, following the preceding test case.
Test Setup
The following setup will be necessary in order to begin testing:
A Mattermost v5.23 test server.
The test server is equipped with an E10 license for the plugin to be installed.
Incident Plugin v0.5.0.
Channel Export Plugin v0.2
Test Server:
Test Server (upgrade tests):
Build Hash:
Test Date:
Tests
Test Area - Plugin Setup | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |
1 | Admin can install plugin in a non-EE instance |
|
|
|
2 | Admin can install plugin in an E10 instance |
|
|
|
3 | Admin can install plugin in an E20 instance |
|
|
|
4 | Admin can enable plugin |
|
|
|
5 | Plugin functionality is available to admin |
|
|
|
6 | Plugin functionality is available to normal user |
|
|
|
7 | Admin can disable plugin |
|
|
|
8 | Admin can remove plugin |
|
|
|
9 | Plugin upgrades normally from v0.3 to v0.5 |
| ||
10 | Plugin upgrades normally from v0.4 to v0.5 |
|
|
|
11 | Incidents started with the prior plugin versions are still active and available in v0.5 |
|
|
|
12 | Incidents ended with prior plugin versions are not available in v0.5 |
|
|
|
13 | Playbook started with the older plugin version is still available upon plugin upgrade |
|
Test Area - Limit incident access to only participants As an incident participant, I can make an incident and its channel private so that non-participants don’t know it exists let alone access its content. | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |
14 | Incident created without selecting a playbook is public by default |
| ||
15 | User can make a public incident |
| ||
16 | User can make a private incident |
| ||
17 | Converting a public incident channel into private, makes the incident private |
| ||
18 | Non participant cannot access a previously public incident converted to a private incident | Continue the test from above.
| ||
19 | Non participant cannot access a new private incident |
| ||
20 | Private incidents cannot be searched in backstage by non-participants. | Continue from the above test.
| ||
21 | Public incidents are visible only within the incident’s team |
| ||
22 | Private incidents are visible only within the incident’s team |
| ||
23 | Public incidents cannot be searched in a different team’s incident backstage |
| ||
24 | Non participants can view public incident details in RHS | Continue from the above test.
| ||
25 | Non participants cannot edit incident details in RHS of a public incident unless added as the incident channel’s member | Continue from the above test.
| Need to find out more about the mechanism to view the incident details on RHS if the details view is going to be tightly coupled with the channel view. | |
26 | Non participant cannot access view private incident details in RHS | |||
27 | System administrator can see a private incident |
| ||
28 | System administrator can join a private incident | Continue from the above test.
| ||
29 | System administrator can view a private incident details | Continue from the above test.
| ||
30 | System administrator can check and uncheck items in private incidents | Continue from the above test.
| ||
31 | System administrator can add and remove checklist items in a private incident | Continue from the above test.
| ||
32 | System administrator can end a private incident | Continue from the above test.
| ||
33 | Team administrator can see a private incident |
| ||
34 | Team administrator can join a private incident | Continue from the above test.
| ||
35 | Team administrator can view a private incident details | Continue from the above test.
| ||
36 | Team administrator can check and uncheck items in private incidents | Continue from the above test.
| ||
37 | Team administrator can add and remove checklist items in a private incident | Continue from the above test.
| ||
38 | Team administrator can end a private incident | Continue from the above test.
|
Test Area - Configure playbooks to create public/private incidents As an incident manager, I can configure playbooks to create either public or private incidents so that it defaults to the correct permission when executed. | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |
39 | System administrator can create a public playbook |
| Is step #4 correct? | |
40 | System administrator can create a private playbook |
| #4 correct? | |
41 | Team admin can create a public playbook |
| #4 correct? | |
42 | Team admin can create a private playbook |
| #4 correct? | |
43 | A non-admin user cannot create a playbook |
| Is #3 correct? | |
44 |
| N/A due to the test above this one. Is this correct? | ||
45 | Private playbook is initially only visible to playbook creator |
| Are steps 13-18 correct? Are private playbooks visible to/accessible by system admins? Or do they need to be invited to the playbook to access them as well? | |
46 | Private playbook is only available within the team it was created in |
| ||
47 | Public playbook is visible to all the members of a team |
| ||
48 | Public playbook can be edited by member user of the team | Continue from the above tests.
| ||
49 | Team member can “invite” other team members to manage public playbook | Not sure about steps to invite other members to manage playbook. | ||
50 | Team member can create an incident using public playbook | Continue from the above test.
| ||
51 | Public playbook can be deleted by team member |
| ||
Private playbook cannot be edited by a non-admin team member |
| Using a direct PUT to test here because the user will not be able to find the private playbook in the UI. | ||
Private playbook cannot be deleted by member user of the team | Continue from the above test.
| |||
Team member cannot “invite” other team members to manage private playbook | ||||
Team member cannot create an incident using private playbook | ||||
Test Area - Prioritize incidents that the user is a participant of As an incident participant, I can easily tell apart the incidents that are relevant to me so that it’s I can get there more quickly. | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |
Test Area - Limit the ability to create playbooks to Team Administrators As a system administrator, I can restrict who can create playbooks so that the incident response process can be better standardized. | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |
Test Area - Limit playbook access to specific users As a playbook creator, I can specify who else can see and edit the playbook so that sensitive content wouldn’t be unintentionally revealed. | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |
Test Area - UI | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |
Test UI in light theme | ||||
Test UI in dark theme | ||||
Test UI in Monokai theme |
|
Test Area - Tests/bugs outside of user stories | ||||
---|---|---|---|---|
Test ID | Test Case | Test Procedure | Result | Notes |