Determine Source Control and Testing Plan

Before you write any code for a custom app, determine your development processes, specifically source control. Source control refers to how you will track and manage versions of code. A method for source control will speed up deployment, minimize mistakes, and help you resolve conflicts in the code. Your company may already have defined DevOps tools and processes. If not, you’ll need to define your own. There are tools available to help.

For code management, you can use widely available tools like Git or Subversion (SVN). You can export and deploy code that you develop in ThingWorx Navigate using standard ThingWorx Export/Import functionality. For Windchill REST Services, manage the extensions similar to how you manage regular Windchill customizations. You can deploy them using build automation tools like Ant, Maven or Gradle.

We recommend that the developers only write code in the dev environments (not QA, test, staging, or prod) for ThingWorx Navigate and Windchill instances. For example, if you need to customize Windchill REST Services, only write code in the separate Windchill dev environment. This will prevent confusion and inaccurate test results later.

As you decide how to best track and manage code, consider the following:

• What development environments you need for each system (ThingWorx Navigate, Windchill, external system, etc.) and what you’ll do in each. We recommend at least 4 environments per system:
  • Dev: create new apps, features, or work on patches
  • Test/QA: validate and test new versions, patches, and configurations
  • Staging: a close replica to your prod environment to do integrated, end-to-end tests such as for scale and load
  • Prod: host the live, tested applications that users will interact with
• ThingWorx naming conventions
  • For Windchill REST Services, follow the same naming conventions as regular Windchill customization
• Security requirements including authentication and user groups for both ThingWorx Navigate and Windchill
• How systems will connect to retrieve data
• Acceptance criteria including testing plans
• End user hardware and devices (refer to the ThingWorx Navigate Product Compatibility Matrix)
• Roles and skills needed (who will do what work from development to prod)

Share key decisions with the project team, specifically with the developers, IT team, and admins.

You'll need a testing plan whether you implement out-of-the-box (OOTB) apps or create a custom app. The project manager, developers, admin, IT, and key power users who will be involved in user acceptance testing should work together on a testing plan. Decide what tests to run based on your requirements, app user interface (UI), and technical design document.

In general, we recommend the following:

• Unit testing: test each service (ThingWorx and Windchill REST Service) with different parameters to assess whether code behaves properly within, without, and at the defined limits
• Integration testing: after unit testing but before system testing, test that all components integrate well with one another
• System or functional testing: test the features and functionality of a collection of components defined by the use case
• Security and penetration testing: test for vulnerabilities, risks, and threats
• Stress or load testing: test the stability of the app and how it handles errors and load
• User acceptance testing (UAT): test with select end users to make sure the app meets their needs
• Deployment testing: test that the installation works as expected on a staging server that represents a production configuration

Document a testing plan including what tests you’ll do in each environment. Remember to consider security and compliance requirements at every stage.

Make one overall testing plan that includes:

• Summary of what the app does (refer back to your use case)
• Data sources and data flow
• Design specification/technical design
• Acceptance criteria
• Test procedure
• Test cases
• Environments and who has access to what
• Security requirements
• ThingWorx version or release numbers
• Results of quality assurance (QA) test
• Performance figures
• Revisions
• Software

You may not have some of this information until you start testing. Some items may not apply if you’re implementing OOTB apps.

If you’re creating a custom app, write test cases so that you can test the app once it’s developed. Your company may already have a process to write test cases. But if not, we recommend the project manager, project sponsor, and key stakeholders write these together.  

When you write test cases, make sure they align with your selected use case. The goals and metrics that you wrote might also provide requirements that your app needs to meet. Write to real-world scenarios that people in your company will experience within the use case.  

Consider test cases for different types of users as well as different types of data the app makes available. To be effective, tests should replicate what it’s like in the real world. Plan to complete these tests in a QA or staging environment that replicates your production environment as closely as possible. 

Document your test cases and include them as part of your overall testing plan.