Connect and Monitor Your Products with ThingWorx

Everything you need to implement IoT for remote monitoring

  Download Success Path IMPORTANT: When saving the file, in the Print window please do the following:
Destination or Printer: select Save as PDF
More Settings: In the Options, be sure the boxes Headers and footers and Background graphics are selected.
Recommended Steps
Overview: Connect and Monitor Your Products with ThingWorx

Determine DevOps and Testing Plan

Determine your DevOps processes for how you will build, test, and deploy your ThingWorx applications. Then document a testing plan.

01. Establish DevOps and source control

Establish DevOps (development operations) before you start development. DevOps will improve communication, speed up deployment, and help minimize mistakes.  

The developers working on your IoT initiative should establish the DevOps they will follow. ThingWorx development is best suited for an Agile process. Developers will be able to create and iterate quickly. If your developers already have DevOps and follow a different methodology, consider how your IoT initiative will fit in with your current processes. 

Include the following in your considerations for DevOps: 

  • Development environments (we recommend at least 4: dev, QA, test, prod Servers)  
  • Source control plan using standard Thingworx import/export, Git, or SVN tools
  • Naming standards
  • Acceptance criteria documents and testing plans
  • Connected products in the field
  • End user hardware and devices (including branding, look and feel)
  • Security requirements, organization structure, and user access
  • Personnel (developers, QA, etc.)

In terms of source control, decide how you will manage code and track work. Naming standards are crucial when developing with ThingWorx. It’s difficult to go back and change naming conventions once you deploy the solution. 

02. Create a testing plan

Decide how you’ll test the solution before you deploy. Refer to the designs for your applications, review your acceptance criteria, and confirm your development environments. Developers and device engineers work together to create a testing plan. 

In general, we recommend the following testing:

  • Unit testing: when developing, consider building in a unit testing concept to allow code to be tested separate from UI testing
  • System testing: test the features and functionality of a collection of components defined by an acceptance criteria document
  • Security and penetration testing: test for vulnerabilities, risks, and threats (always test with different uses that represent real uses)
  • Integration testing: test the edge, products, devices, and platform integrations
  • Stress or load testing: test the stability of the solution and how it handles errors and load
  • User acceptance testing (UAT): test with select end users to make sure the UI meets their needs
  • Deployment testing: verify the package works as expected on a staging server that represents a production configuration 

Identify what testing you need to do in each of your environments. There may be additional testing you need to do that was not mentioned but are based on your specific solution or industry. Remember to consider security and compliance requirements at every stage. 

Create a testing plan for each application. Align testing with your DevOps processes. Plan to test in a QA environment that replicates your production environment as closely as possible. Make sure that your tests replicate what it’s like in the real world otherwise the tests will not be valid. We also recommend that your developers agree ahead of time that they will only write code in your dev environment (not test, QA, staging, or prod). This will prevent confusion and inaccurate test results later. 

03. Document testing plan

Next, create and document the plan for how you will test the solution. Be as thorough as possible. In your plan, include the following: 

  • Value statement  
  • Summary of what the solution does (refer back to your use case) 
  • Data sources and data flow 
  • Design specification 
  • Acceptance criteria 
  • Test procedure 
  • Environments and who has access to what 
  • Security requirements 
  • Naming conventions 
  • 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. As you test, add in what new information you receive and document code as you write it. If you keep your documentation brief and tight, you will find a rhythm as you move forward. Your documentation will give you evidence to solve issues and make decisions faster. 

Did you find this helpful?


Previous Step

Finalize Application Design

Next Step

Plan for Adoption

ADDITIONAL RESOURCES
Product Documentation Find detailed technical documentation on Creo+ in our Help Center
Ask the Community Visit PTC's Creo Community to get support Peer-to-Peer, from our product management and assistance teams. Share ideas, give feedback and browse the wealth of information on using Creo+
Technical Support Need help from our support team? Log a case with eSupport using our Case Logger or find an answer using our new Creo Admin Troubleshooter tool. 

Contact Us

Have a question? Submit your contact information and we’ll reach out within 1 business day. You’re never obligated to purchase or commit.
Get in Touch