...

Test automation in Cypress should be always on top of regular QA work on the project. There are 2 ways how to implement test automation:

During Feature Sprints

• when allocation for QA Analyst is big enough - definitely more than 6 hours a day

  • the main goal here is to support development phase

  • to automate test cases selected mostly by our project team (SA, CE)

  • in this case we are not delivering test automation scripts to customer

  • we don’t expect we will do official maintenance after Go-Live

  • Created test automation can be shared with Engineering team to test next releases in advanced

  • Customer is paying for QA allocation, not for test automation, therefore test automation is not an official deliverable

Test automation packages

• Offer of test automation for customers

  • Customer can choose one of three packages (small, medium, large)

  • Price is based on selected package

  • Will be implemented after Go-Live and we will cover maintenance so customer can see benefits after upgrades

  • Scope is agreed with customer based on critical business cases

  • Especially useful for long term cooperation

    • several phases of implementation

    • regular checking of critical functionality after upgrades

Main benefits

• scope based on real project business cases, covering functional verifications based on customer needs

  • testing automatically every night

  • can be used for most of Pfx modules (Rebates, Quotes, PA, PB, Dashboards, …)

  • checking key functionalities after upgrades or changes in the code (bug fixes or change requests)

  • recording from every test so it is clear what was tested and where the issue was found. Recording can be also used for showing to new guys how to work with Pfx sw

  • quick bug detection (typically because of data or code changes or because of incorrect changes on qa partition)

Limitations

• Cypress (if customer is expecting other tool, we usually can’t help him)

  • We are staying within Pfx sw with test automation - no testing within Salesforce, SAP or other sw

  • For functional testing only, we don’t expect it will be used for data or integration testing

  • Not very useful for Price Optimizer

  • not covering all scenarios from the project, just what is in scope

  • not replacing all testing during project

  • scope will be finalized when the solution is stable and when it is clear there will be no major changes, so test automation packages are not very useful during development

...