3. My assumptions about you
• Incented to get software into production
• Progress Software through environments
based upon validation
4. My assumptions about you
• Incented to get software into production
• Progress Software through environments
based upon validation
• Have a mental model of what might be
acceptable and what might be a bad sign
30. Closing it out
• Put Production facsimiles into the hands of
your developers
31. Closing it out
• Put Production facsimiles into the hands of
your developers
• Add the maintenance of these interfaces to
your deployment process
32. Closing it out
• Put Production facsimiles into the hands of
your developers
• Add the maintenance of these interfaces to
your deployment process
• Understand your Θ
33. Closing it out
• Put Production facsimiles into the hands of
your developers
• Add the maintenance of these interfaces to
your deployment process
• Understand your Θ
• Incentivize boundary and extents testing
34. Closing it out
• Put Production facsimiles into the hands of
your developers
• Add the maintenance of these interfaces to
your deployment process
• Understand your Θ
• Incentivize boundary and extents testing
• Deliver business value for your function
You have the goal or desire to deliver running software – that thing called business value. This may be a no brainer for you but seriously this may not be your role at your organization – some of you are human roadblocks, hired to mire, slow, and generally disrupt (also called control) releases.
You have lower environments and originally the goal was to make them as close to reality as possible. This was never the goal of the folks who mandated this practice and they never really gave you the tools but, there you are…
So if you have been somewhere long enough you learn these things – Oh that is always red, that never works because of XYZ in this environment
If you do what you have always done, why do you complain when you get what you have always got…
I am challenging you to make some new ventures into learning and exploring
We test the functionality as the requirements state – we follow the flows to the letter, and we do it in environments that are so unique they may be termed antiseptic
We treat QA or Maybe UAT environments like this clean room – nothing is added that is not first sanitized. So what does that mean? Our environments are sparse! Very Sparse!
Bend them to your will
Make them respond faster, slower, with the wrong data, with the right errors, with dirty state, with partial replied, with corrupt replies – With a 200 and no content, with a 404 and the right resource
Interesting things occur when you can validate in these virtualized systems