Testing

Copy link“Test as you build” philosophy

As mentioned in the introduction, we recommend starting with an MVP and improving your product step-by-step by adding additional functionality and features to your product. An integral part of this development process is to be able to test your product with either real or mocked devices to see that everything is working as expected, and fix some inevitable and unavoidable bugs. Our recommendation during this process is to launch and test your application with real end users as soon as possible, and avoid having long-running test pilots before the product is launched. Our experience shows that organizations which dare to launch their product in the market earlier end up with shorter development times and a better overall product. This also allows for your product to be quickly and incrementally improved based on user feedback

A great way to launch early versions of your product, or a new feature of your product, is through a soft launch. A soft launch means giving a select group of end users access to the new product or feature, before launching to the general public. In this way, bugs and errors are only exposed to a select group of users and can be fixed quickly before launching to a wider audience.

Copy linkTesting in Enode environments

As mentioned in Planning your integration Enode offer two environments, Sandbox and Production. Sandbox allows for testing with mocked devices and data, and production environments allow linking of real devices. These environments offer different testing opportunities and benefits.

Copy linkTesting in Sandbox

We recommend using sandbox to test that there are no blatant issues in your communication and interaction with the Enode API. This can include checking that API responses are read and handled correctly, and that communication with relevant API endpoints work as expected.

In its current capacity we do not recommend using a sandbox environment to test that your application can handle all states of objects in the Enode API, as the mocking in our sandbox environment does not reflect all states and edge cases of real devices.

Copy linkTesting with real devices

Testing with real devices is the the natural next step after sandbox testing has been concluded. When testing with real devices we recommend having two separate Enode production clients. One staging environment to test your functionality with a real device prior to launching, and one live environment which is tied to your live app.

Copy linkStaging environment

The staging environment is where we recommend initial testing with real devices before launching the product or feature in your live app. We recommend performing these tests with devices you have access to yourself. The purpose of these tests should be to validate that the experience and functionality of the new product or feature is sufficient to proceed with a soft launch in your live environment.

Copy linkGetting access to real devices

It can be challenging gaining access to real devices which you can use to test your new features and products in a staging environment. Our primary recommendation is to use devices owned by your organization, or employees in your organization, to conduct this initial testing. This gives you full control of the device and the actions taken without potentially negatively impacting the experience of one of your users.

If you do not have access to any devices through your organization or one of its employees, several other options are available to get access to real devices.

• Device rental
• Borrowing a device from friends or family
• Using and end users device, where you have a close relationship

Copy linkLive environment

The live environment is the Enode client which is directly linked to your live application. Once testing in your staging environment is complete it’s time to launch your changes to your end users! As mentioned previously in this section, we recommend launching to real end users quickly, and prefer this over long-running internal test pilots.

When launching to real end users you may choose to initially go for a soft launch targeted at a select group of users. These can for example be users who have opted to be a part of an early release program.

Another option instead of a soft launch is to run a quiet launch, where you make the change available to all users, but with no marketing or push towards end users to activate the functionality. The functionality may also in these situations be somewhat hidden in your app.

With this approach you can launch a feature early with limited exposure to the general public, and increase the visibility and marketing once the feature has been tested by some of your end users. This approach of course only works if the added feature needs to be enabled by the end user itself.