sanity check scripts # Top priority component in the success of overall software project # Most Ignored hero

Success of any software project lies into three areas

Development
Quality Assurance + Delivery
Operations

To assure the continous operation Projects do have state of the art 24/7 monitoring system, for Quality Assurance + Delivery Projects spend un-countable hours in CI-CD ,Test Automation, Regression Tests and many more. For Development we have Tools to get the functionality translated into Technical Artifacts. But one component which can smoothen the transition of Developed code till Production is often missed.

Sanity Check scripts save huge amount of Time if they are developed and maintained in the initial phase of any project. And they continue to save time in each area as we mentioned above.

In a SOA/BPM Project where Architecture is disctributed among layers, varous interfaces talking to different backend applications, technology stack serving different purpose (e.g. BE, BPM, BW, Spotfire, EMS) and on top of that this Architecture has to be scalable. No way the requirements may not find their way at enough speed to land into production even small bug fix may take good amount of time to land into target environment.

They help to check the Technical Readiness of your underlying stack before you beginn with any Test and save great amount of Time, even if you want to deploy a code into environments otherwise n number of hours can be vested to find the root cause of a problem
Absence of sanity can add more frustation to Developers and Test team to do their da to day job, if they found same issue is occuring 10 number of times which can be detected far before wasting whole day to figure out what went wrong.

Sanity checking can be on very high level divided into two areas:

Technical readiness of the Stack
Functional readiness of the Stack.

In Technical readiness following areas can be checked before running tests.

1. Filesystem check:

1. Sufficien space available or not
2. Expected mounts and partitions available or not
3. Can the Unix user write or ftp to filesystem or not

2. Database Availability:

1. TNS Ping
2. Tablespace availibility
3. Necessary database objects exists or not

3. Unix/Windows level process status:

1. Necessary applications are running or not
2. Check for the ghost processes

4. JMS and Application server availibility:

1. Needed JMS destinations are available or not
2. Needed Application Servers can be reached or not.

5. Necessary backend applications are available or not:

1. Making test Rest or SOAP calls

Above mentioned minimum technical readiness criterias can be checked. They are not only usefull before running functional tests but also before doing the Deployment or Rollout of the environment.

This can be easily automated by using the combination of Ant, Shell and Python.

Functional Readiness:

In this area we need to make sure if the data is available or not in the backend before we run tests. In the absence of data Tests fails and it takes time to figure out what went wrong. Every project has a different criteria for this area but all of them need the availability of data before running even a smoke test. This check can be easily fulfilled by using offered webservices by the stack and in case if data is missing data can be created.