As a tester on, for example, a SOA project, there are different viewpoints to consider. At the business level, where services are orchestrated into business processes, you want to make the assumption that the component services have already been tested thoroughly. Communicating directly with people from the business will be needed to formulate the right test cases, and to prioritize your test cases. When testing individual services, this will have to be done in a very technical and methodical fashion. The impact of a defect is typically very severe. If a defective service is re-used in multiple business processes, the end users will experience this as a ruinous duplication of the bugs. Testing the services will rely heavily on test automation, require direct communication with the development team, and an extensive familiarity with the technical details. As such, the ‘technical tester’ becomes a separate specialization from the ‘business oriented tester’.
Something similar can be seen when implementing ERP-packages and commercial-off-the-shelf (COTS) software. The supplier or middleware vendor will claim that mostly canned solutions have been used, that do not need to be tested. Testing will focus on checking whether the operations have been configured properly for the business, and whether solution provided meets the everyday demands of the end users. Test execution or scenario development together with end users is a natural solution for business oriented testers in this environment. Conversely, most ERP implementations also have a custom-made component, the proverbial remaining 20% which takes up 80% of the project budget. This dedicated software obviously does have to be tested well, because it is new and has not been tested yet. (It must have great business value, precisely because the business decided the extra features were worth the expense.) Quite likely, the testing becomes very technical, requiring tools for diagnostics and test automation.
Testing Data Warehouse / Business Intelligence solutions is a compound situation where we can once again make a distinction between business oriented and technical testing. The BI component requires a tester who communicates well with business representatives. It is hard to predict the expected result (desired system behavior) of a test that involves vast amounts of data. Domain experts can and should be able to provide the answers and formulate the criteria that are needed for testing and developing these solutions. The DWH component can be approached in a more low-level, technical fashion.
Let’s see look at the common denominators in these trends. Most business solutions tend to be very complex. As such, it is desirable if a partial delivery of the system is possible during development, allowing feedback from the business to be incorporated. Cross-functional teams are needed to be able to do development in short iterations. Testing will have to be integrated into the development cycle and not be a separate phase, simply because there is no time for longer cycles. Wait a minute! So we have a focus on both the business processes and the technology used in the solutions, lots of communication, short iterations, testing in parallel with development, and a process driven by the feedback it generates. What does this mean for the project management style? It is becoming Agile!!
Testing Data Warehouse / Business Intelligence solutions is a compound situation where we can once again make a distinction between business oriented and technical testing. The BI component requires a tester who communicates well with business representatives. It is hard to predict the expected result (desired system behavior) of a test that involves vast amounts of data. Domain experts can and should be able to provide the answers and formulate the criteria that are needed for testing and developing these solutions. The DWH component can be approached in a more low-level, technical fashion.
Let’s see look at the common denominators in these trends. Most business solutions tend to be very complex. As such, it is desirable if a partial delivery of the system is possible during development, allowing feedback from the business to be incorporated. Cross-functional teams are needed to be able to do development in short iterations. Testing will have to be integrated into the development cycle and not be a separate phase, simply because there is no time for longer cycles. Wait a minute! So we have a focus on both the business processes and the technology used in the solutions, lots of communication, short iterations, testing in parallel with development, and a process driven by the feedback it generates. What does this mean for the project management style? It is becoming Agile!!
This is a very important observation: if all of these trends demand agile project management, then agile is out there, and much bigger than most people realize. Sooner or later nearly every tester will encounter an agile project.
//Based on a presentation I gave at the EuroSTAR2008 testing conference.
