Test users

In order to test the platform's integration with your pharmacy management system, we’ll need you to provide us with test users for your UAT (User Acceptance Testing) and Production environments. We require validated test users from you in order to schedule the engineering team for your implementation.

We understand that there are many rules and regulations that make utilizing test data in production difficult. As a result, we try to keep our testing limited to what is absolutely essential for a high-quality release. We will need 9 test patients in your UAT environment and 7 test patients created in your production environment, so that we can cover a wide variety of registration scenarios and prescription states. If you have more than one banner, we will need these test users for each banner.

Note: If you would prefer that we set up test users on your behalf, you can provide us with VPN access to your test environment, and we will create the test users on your behalf. This will greatly speed future upgrades and relieve your team of the time needed to create these test users.

Please follow the steps outlined below to share the test user information with us:

Step 1

Download the template

Download the Test Users Excel template by clicking the button below.

Download template

Step 1

Fill in the details

Once you've downloaded the Test Users template, review and fill in the information. Please contact your implementation manager if you need assistance.

Step 3

Send the template

Once you have added the information requested in the template, please attach it to JIRA or send it to us for test user creation.

Send template
 

We perform end-to-end testing in your UAT environment to be sure that the system is set up properly. We’ll schedule joint testing with you shortly after we provide you with the applications.

Learn more about test cases.

Please plan to review the platform and get us any feedback within 3 business days.

Known issues

We hate them, but sometimes they do show up!

If we identify bugs during the testing, we will classify them using our prioritization matrix. Issues which are deemed to be critical will be addressed prior to go live. Issues of lower priority will be placed into the product backlog and addressed during our regular release schedule.

Please note that we cannot schedule the engineering team until we’ve received the test users. 

These are the processes we test in production, prior to any major release.

  1. The entire prescription refill process. At every step of the workflow, mscripts will confirm all notifications and user interfaces are displaying properly.
  2. Signing up a test patient in-store for text messages.
  3. Signing up a test patient for the mobile application.

We will need your help to run the following Production Test Cases. We’ll schedule some time to test with you when we start the implementaton process. This typically takes several hours to complete.

SNo.

Production test cases

Requires Customer Assistance

1

Add a new prescription to a profile , verify appears in app/web.

Yes
2

Request a refill from the prescription list and confirm it moves into the fill queue

Yes
3

Fill the prescription (more detail)

Yes
4

Mark Prescription as sold

Yes
5

Cancel a prescription already being filled.

Yes
6

Sign up a patient for texts in-store

Yes
7

Refill a prescription with 0 refills and ensure the proper ‘call doctor’ flags are set.

Yes
8

Ensure the store locator is properly displaying nearby stores.

Yes, due to the location-specific nature of this feature.

In addition to the above test cases, we’ll run the following cases on your behalf.

SNo.

Production test cases

Requires Customer Assistance

1

Create a new account in the mobile application with a PROD user

No
2

Request a refill for a schedule 2 drug

No
3

Request a refill using refill by scan

No
4

Confirm that minors cannot create accounts and confirm family accounts are working.

No

Issues are classified by the following:

  1. Is the feature in the product today? If not, this is an enhancement. You can work with your account manager following go-live to create an enhancement request for review by our product team.
  2. Is the issue a configurable option change (timing of messages, wording of text, etc.)? This is a configuration, and should be identified and set early in the implementation.
  3. Is the issue a feature which not functioning? We classify this as a bug.

We prioritize bugs according to the following 3-step process.

 

 Issue severity

When a new issue is reported, the mscripts team will first determine the severity of the issue according to the guidelines noted below. During implementation you will work with your implementation manager to triage and prioritize issues.

Severity rank Description

Severity 1 - Blocker

The Platform cannot be used and is affecting many Client systems; Client’s use of the Platform is crippled or unusable or in danger of becoming so; Client’s hosted data is corrupted or lost; no known or acceptable bypass or circumvention is available. Issue affects most or all users.

Severity 2 - Critical

The Platform can be used with major restrictions; few Client systems affected; Client Platform speed is diminished to the point where User experience is materially impacted. Issue affects a large population of users.

Severity 3 - Major

The Platform can be used with minor restrictions not critical to its use; speed of Client Platform is reduced to the point where it may be noticeable, or intermittent errors are detected. Issue which affects a small population of users.

Severity 4 - Minor

Standard issue resolution question. The problem with the Platform can be bypassed easily by a User work-around or minor correction to code; Platform ability to perform is not affected; cosmetic error. Issue which affects few users.