Overview of the AgileSOA Testing Challenge Agile Testing

I’ll start with my three favorite things about agile methods:

  • They have improved many organizations’ ability to deliver with short-term focus as they place a lot of focus on the iteration to plan the project team’s work and deliver the solution incrementally.
  • They encourage customer involvement in the process.
  • They are relatively simple to understand and succinct to describe.

Expanding on this, one of the most tangible ways I’ve seen agile methods impress is in improving the amount of focus of activity to get the first release of a solution into production. This solves the problem that many organizations have, which is that their projects seem to drag on forever without actually delivering anything.

Agile methods normally achieve this level of focus by planning short-term, using iterations, and by measuring progress in terms of functionality produced by each increment. This works very well as teams are motivated by short-term success. After all, success breeds success! Also, if there are any issues with the project’s delivery capability they will soon be encountered early in the project life cycle rather than being hidden until late. The sooner the issues are identified, the sooner they can be resolved.

Turning to SOA, it’s important to note that many of the important benefits of SOA are realized when building “long-term IT solutions.” It’s fundamentally about building your software in such a way that it improves the long-term costing and flexibility of your IT solutions.1 The following define the usage of “long term” and “short term”:

  • Long-term IT solutions(strategic)
    • support an ongoing business function,
    • have a “long” life span(5 years plus),
    • are core IT systems that support the business need to be able to be extended to support new business requirements,
    • have high quality requirements,
    • often have a high degree of interconnection with other IT systems, and
    • the consequences of failure are considerable.
  • Short-term IT solutions(tactical)
    • solve a niche problem,
    • have a “short” life span,
    • are often required to provide an edge over competitors,
    • have lower-quality requirements,
    • do not have considerable consequences of failure, and
    • can sometimes be R;D-type efforts.

Agile methods have achieved huge success when approaching short-term IT solutions. However, I have seen issues arise when these same methods have been applied to SOA “long-term solutions.”

This doesn’t need to be the case. The challenge for our agile SOA projects is to stay simple to understand and to keep a short-term focus while adding the necessary support to plan and design SOA solutions and addressing the long-term considerations of the solutions you deliver.

Before we move on to look at my development process, I’d like to outline this challenge by mentioning some of the issues we want to avoid when building SOA solutions:

  • “Loose” requirements factoring results in duplication of effort and/or increased refactoring. A requirement is “a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value andutility to a user”.
    I very much like the “factory/production-line” analogy when thinking aboutour agile software development projects. A master list of requirements is createdusing one of the popular mechanisms for expressing requirements–features, usecases, or story cards, to name a few. Iteration planning will scope out a subset ofthis master list to be delivered by each iteration.
    The “factory” (combination of team and tools)will then continue to produceincrements “production-line style” by running these scoped iterations, with eachiteration producing an increment.As it is the requirements that define the contents of each iteration, it isimportant that there is no functional overlap between any of the requirements;otherwise, the result will be duplication of effort and inevitably this will result insome refactoring of previous increments.
  • “Fat requirements” don’t fit well into iterations. Your requirements specifications need to be structured in such a way that they fit well into iterations. If the smallest unit of requirement that you have results in two months of work to deliver, then you’ve got a problem as this doesn’t fit well with an iterative mode of delivery.
  • Lack of agility in specifications. If we take agility to mean the ability to change direction quickly, then we know that our specifications need to be able to handle two kinds of changes:(1) changes to modify functionality (i.e., functionality that has already been delivered)and (2) changes to include new functionality. By “lack of agility in specifications,” I mean specifications that are not able to quickly incorporate these kinds of changes. Otherwise we risk ending up in a situation where the specifications get sidelined and become out of touch with the solution code.
    So we need to focus on producing agile specifications as we know that we’re at a minimum going to encounter a lot of the second type of change when doing iterative development, as each iteration adds new functionality that builds on that delivered by previous iterations. Hopefully we’ll also try and minimize the first type of change, but more on that later.
  • Extensibility and flexibility qualities suffer without design specifications. Two very important qualities in a good SOA solution are its degree of extensibility and flexibility:
    • A good SOA solution is able to incorporate functional extensions without undue effort(extensibility). Also, a good SOA solution should allow for its constituent parts to change without compromising its functionality and reliability(flexibility). This is required when the same parts are shared between multiple SOA solutions and one of the solutions requires changes that shouldn’t compromise the other solutions.
    • Extensibility and flexibility don’t happen by accident. They need to be built in, either as a forethought(design specifications)or an afterthought(refactoring). There are limits to the extensibility and flexibility that you will achieve in a solution through refactoring–so design specifications are critical to achieve these qualities in meaningfully sized solutions.
  • Mixing requirements and design makes it harder to understand what the system will do. Requirements specifications provide a tangible understanding of what thesolution will do. As such they need to be understandable by the customer, whoneeds to be satisfied that what the solution is planned to do(requirements)is whatthey want it to do. Mixing in solution design in your requirements specificationsmeans it becomes difficult to achieve this.
  • Lack of specifications means code can become impenetrable(or costly to understand). Not only can a lack of specifications cause problems with the initial production release of the solution, but there will definitely be problems later. As we’re focusing on our previously defined “long-term IT solutions” with SOA, it is inevitable that during a sizeable part of the solutions life span there will be a number of pairs of eyes that will be peering at the code and will need to understand how the solution works. Now, even with the best of intentions, there is a limit to the degree that the code for a solution can be “self-documenting.” Specifications will play an important role in helping to understand the solution’s requirements and design in a cost-efficient manner.
  • Solution costs don’t end with delivery of the first production release. It is a well known fact that when it comes to long-term IT solutions as defined previously, the cost of producing the first release is relatively small compared to the costs over the total life span of the solution. Examples of later costs include
  • costs associated with delivering functional extensions,
  • costs associated with providing support to the users,
  • costs associated with fixing defects found, and
  • costs associated with technology upgrades.

A number of practices already mentioned contribute to minimizing these costs:up-to-date agile specifications, built-in flexibility, and extensibility through design specifications. An overriding focus on functional delivery at the expense of these practices will mean that any “savings” made by taking shortcuts in the delivery of the first production release will be heavily outweighed by later resulting costs.

  • Lack of design guidance often results in technologies being inappropriately used.An end-to-end SOA solution might end up including a number of differentimplementation technologies–Portlets2 running in a Portlet engine for the userinterface, an enterprise service bus to plug together the various service-oriented parts, executable business processes running in a Business Process Execution Language(BPEL) engine, messaging middleware to connect to external systems, adapters for connecting to specific external solutions. Many of these technologies are fairly specific in terms of the type of solution part they should be used to implement, which means that it takes a bit of foresight to plan to use the technologies appropriately. As an example, although you could write most if not all of your solutions logic as BPEL, is that a good idea? Probably better to only use it to write your business process logic which, strangely enough, is what BPEL was designed for.
    Without a design for the SOA solution being built, it is that much harder for developers to pick and choose where to use implementation technologies appropriately.
  • Overreliance on refactoring to fix design problems results in projects stalling.Agility is about being able to quickly change direction when you need to. However, this doesn’t mean that it is a good idea to rely on changing direction a lot to get you on the right track. This is especially true when it comes to your SOA design. Sure, you could try to “evolve” this by building the code to meet the functional requirements and then refactor later to achieve a good design for this code–but this isn’t a way of working that scales well or suits SOA-style solutions. I have seen projects where the delivery of new functionality has stalled for months while the team refactored the current solution before adding new functionality. This just isn’t acceptable to the customer. Although refactoring might have its place, overreliance on it as a way of evolving the solutions design does not work when it comes to SOA solutions.
  • Planning and measuring just developer activities is not enough. Our software projects consist of more than just developers. Excluding project managers and other supporting roles, they include systems analysts, architects/designers, and testers. Each of these subteams needs to be taken into account in both planning of project activities and measuring of project progress. If you’re not measuring the progress of your system’s analysts in creating requirement specifications, then you might miss the fact that you are running out of completed requirement specifications to hand to
    your architect/designers, which will have a knock-on effect on your developers and then later testers.
  • Relying on having the entire project team co-located is often not practical.Having your entire project team co-located will undoubtedly have benefits interms of improving communications. However, this is often not practical. Mostof the SOA projects I’ve worked on have included multiple suppliers, and more often than not each of the supplier’s resources is geographically distributed.Your development method cannot rely on co-location of resources toachievegood communication between team members.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics