Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
Check out test packages here.