QA/Execution/Web Testing/Continuous Deployment: Difference between revisions

no edit summary
No edit summary
 
Line 1: Line 1:
= Continuous Deployment/Delivery Process=
Questions and processes to be determined for each project moving on to CD.
== How can we manually test new features?==
* Waffle testing behind flags
**Each new feature should include a waffle flag
* Example from the past: SUMO. After CD there was intermittent manual testing with waffle, now none at all.
==Where do we test?==
*AWS - creating local test instances
*Test in production
== Mitigating Risk
* We can highlight the risk of not doing manual testing; team must have an understanding of their level of acceptable risk.
* We could provide examples of ways to mitigate the risks
* There needs to be buy-in from the CD team, they must want manual testing
* Sometimes, I think they might not be fully aware of risks, so we can help them realize those, and perhaps that will cause them to ask for more help (just a thought) - [stephend]
==What's the minimum automation we should recommend?==
A test plan will highlight the level of risk that is appropriate, can determine minimum automation level from that- need to cover high risk areas, or if we can accept failures
Make sure what we have in place has a part of their build release process, otherwise failures are not highlighted
==What constitutes a failure that would block deployment?==
Depends on test plan and risk assessment
=SUMO Continuous Deployment=
=SUMO Continuous Deployment=


SUMO is swiftly moving towards continuous deployment. There will be a lot of changes in both the release process as well as QA for SUMO.  The definition of continuous deployment is the ability to release as often as desired, without requiring the immediate participation of QA or IT during each release.  
SUMO is has moved onto continuous deployment. There will be a lot of changes in both the release process as well as QA for SUMO.  The definition of continuous deployment is the ability to release as often as desired, without requiring the immediate participation of QA or IT during each release.  


JSocol will be writing and sharing a flowchart as well as a projected timeline for the gradual change towards continuous deployment. The intention of this document will be to map out changes from the QA perspective.
JSocol will be writing and sharing a flowchart as well as a projected timeline for the gradual change towards continuous deployment. The intention of this document will be to map out changes from the QA perspective.
Confirmed users
1,504

edits