Web Service Testing or SOA? Requirements vs. Rules?
There is so much complicated talk about Web Service testing. or is it SOA? There is a difference! SOA is more involved, and we will get into that.
Web Service Testing can be a simple thing, since there are really ony 3 elements to the process:
1. Create and send the Web Service “Request”
2. Receive the “Response”
3. Evaluate whether or not it worked.
These can be tested with home-grown interfaces, free downloads such as soapUI, and even automated with the same. No need for complicated toolsets.
Rules and Requirements
Great. Now there is this subject of validating an application’s set of rules. Rules are the functional expression of a Work Flow or a Business Process as described by a set of Requirements. What? no Business Requirements? Why – how can that be? I can tell you that that is the usual state of companies these days. No requirements. OR if there ARE requirements they are written at a general level, with not enough specificity to drive a functional requirement through a paper bag. Occasionally we see good requirements, but as a rule – “there is just not enough time… here – just do this…”.
Process before Testing
Unfortunately, that opens the whole question about …. “Hey, WHERE is the PROCESS?”…. Some have better process than others, some have none – but in either case, there is always a need to improve a process forgotten, minimal, broken or non-existent. Testing without a well defined and full SDLC (Software Development Life Cycle) is like trying to drive a car without a steering wheel.
There needs to be a Charter, Planning, Joint Accelerated Development meetings, Business Requirement Documents to define the product, Analysis of the BRD to create a Development Framework and a Testing Strategy, a Construction period for both Development and Testing, a release phase into a Testing Environment, a full Testing cycle for Functional, Integration, End to End and User Acceptance testing. All of this before the public ever sees one piece of it.
Does this sound familiar? How much of it is in place for your project? Is your company or project chasing it’s tail and failing to meet the desired outcomes? Don’t feel alone. These problems are in every single company I have ever consulted with over the past 16 years. There is ALWAYS a solution and a remedy to make it better. “That’s the we have always done it” is not the right answer – ever. The right questions are what do you expect to have when you are finished? How do you expect to get there? How long will it take you if you have a specific plan for delivery and resources?
Just saying we are going to develop something and release it will not work. The IT and Testing departments will be chasing their tails forever. Especially if there are no checks and balances between the Business, Development, Testing and Operations. Many a company is run by it’s Business which is good, some by the Development group, which is ok, but not the best. Mostly the Business runs the show as they have the checkbook. If Development runs the show, it is because there are no checks and balances. Process levels the playing field a good bit, and makes everyone play with the same playbook.
So, when testing Web Services, or Rules Engines, Testing cannot be expected to just sit on the other side of the wall until Development throws something over and says “Hey, just test this”. The results will be as obtuse as the request. Testing should be involved from the Requirements phase until delivery to Production. Testing can participate early on to grasp the direction of the development and prepare for the releases to come. Partnership between Dev and Test needs to be a close and working relationship.
to be continued…
