FURPS+: Post Deployment Verification tests domain
// For all categories see FURPS+: Table of Contents
Post-Deployment-Verification (PDV) or Self-Health-Check — is a category, that covers test cases which verify, that your system is running properly: either after installation or upgrade or after any emergency like a power outage in data center. They are used for automated monitoring purposes of service operability and health-check as well.
Common scenario for such tests: to make sure, that main feature works.
These tests, if automated, extremely fit and support Continuous Delivery and Continuous Discovery process of software deployment.
If they are not automated, then they are executed manually during deployments of updates for the components or periodically for the critical-path health-checks monitoring purposes.
What to include in PDV tests
With PDV tests you verify, that your service just does its job right: you ask allocation service to allocate you something, you ask conversion service to convert you something, to cache and retrieve you something you ask a cache server, etc., etc. — and if the result is the same as a known ethalon, then test passed and the service should be marked, as working properly — that’s all!
Autonomy of PDV tests is very important: you don’t need to verify with a single test a lot of functions of your service or server. Instead, with a single test you need to verify only 1 critical function or 1 major interconnection. This autonomy will help you to localize problems as fast as possible and maybe even to automate their bypass and resolution.
At the same time, you should keep a number of such tests per component as less as possible. That’s why verify only essentials. In these tests you already EXPECT that software works fine, but you just want to double-check, to make sure, that main feature or main interconnection simply operates as expected.
Such tests must exist in your test cases base, because otherwise even a simple power outage in a data center or a rollout failure may cause a significant downtime of your service.
I hope you enjoyed reading and found this article useful. If so, please like to recommend others!
If you have anything to add, share, argue or to comment in this article — please, do it! Only in collaboration we can build something really amazing in Software Quality Assurance.
