How do you approach testing?

One aspect of this field I have always been curious about since day one is: how do other people approach testing? I've been developing and building our testing requirements and procedures and am always interested to see how other people and teams handle their tests.

 

For example, I usually work SOAP services, and usually a service fits into one of three categories:

1. Read Service where the source data is external and is ingested.
2. Stand-alone service that is Read/Write all in one WSDL/Schema package.
3. Service pair where the Read and Write services are both individual to each other but work in conjunction.

 

Most of my tests are the 3rd of the list, and there are a few that match 1 and 2. I'll walk through my approach for the read/write pair since that closely matches both the 2nd and 3rd. 

 

 

 

1. Analyze the write object and write a groovy script to generate data based on uniqueness required from business rules. 
2. Determine the different possibilities of a Write. 
3. Build at least one write test for each possible combination, if possible.
4. Also build a write test to later update, and one to delete.
5. Follow the same pattern for Delete, if there are choice models make a test for each of those.
6. Similar for update.

For all of these, I will have one overarching test suite that contains one test case for each of the operations. It'll look like:

1. Test Suite
   1. Properties 
   2. Add Test Case
   3. Update Test Case
   4. Delete Test Case

Read services are similar, in that, I'll have a test case for each of the operations. Read services are usually less complex in that they only have a Get or an Is method, but often offer different branching conditionals or logical operators that can be used to query against the data from Write. Here, I tend to cover as many logical/conditional read steps as I can and often leverage a groovy script assertion to validate the response matches the query made.

 

1. I can usually have an combination of:
   1. Element Equals/Does not equal/contains/does not contain
   2. AND/OR

With that, I'll work with all of the available filters to cover as many cases as possible to show that the Read service works as intended.  The And/OR statement lets me chain different queries together and just adds another layer of stuff to test.

 

That's just a quick and brief overview of how I approach testing. I'd love to learn and see how others attack their services. :)