Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>

X
BLOG

Testing Resource Constraints in Composite Apps

Testing Resource Constraints in Composite Apps Reading Time: 3 minutes

Resource constraints inherent in today’s heterogeneous enterprise environments can impede a QA/development team’s ability to construct test suites. This ultimately handicaps the team’s ability to deliver and evolve secure, reliable, and compliant applications on time and on budget. As applications continue to grow increasingly complex and certainly more distributed, this problem compounds significantly.

Efforts to ensure the quality of today’s heterogeneous applications are hindered not only by system availability constraints innate to the applications’ distributed architectures, but also by human constraints associated with the way in which such systems are developed, tested, and evolved.

System Constraints

Today’s heterogeneous applications involve a number of components; for example, consider the following diagram of a common enterprise application architecture:

Testing Resource Constraints in Composite Apps

Efforts to test such applications are commonly delayed (and often cut short) because one or more component is incomplete, evolving, unstable, inaccessible, or otherwise unavailable for testing.  Such difficulties stem from the following constraints:

  • Access to distributed applications
    Business processes are enabled by a complex interaction of distributed systems. Testing a use case that leverages a single system is complex…and if the use case calls multiple distributed systems, complexity increases exponentially.
  • Access to partner services
    Service-oriented architectures allow organizations to take advantage of “units of work” distributed as services across organizational boundaries. In order to exercise internal applications, the organization must have a way to model the behavior of these services (units of work) to conveniently test.
  • Access to new or evolving services
    A service-oriented architecture introduces an organization to a constant state of change.  From a testing perspective, this can prove to be very frustrating since access to evolving services might be limited or completely unavailable.
  • Ability to simulate failures and performance issues
    Service-oriented systems need to be tested under failing conditions to ensure that applications fail gracefully when a dependent component fails to respond, or fails to meet the required quality of service metrics from a performance perspective. If the dependent applications are used or replicated, it is very difficult to simulate such conditions in a test environment. Besides, it is costly to replicate the dependent systems in performance testing environments. As a result, it is important to virtualize the dependent system’s performance characteristics as well as its business functionality.

Human Constraints

In addition, the following human constraints compound the difficulty of performing thorough testing with the given time frame and resources:

  • Changing services or application components
    The impact of changing services can have unknown ramifications if specific functions are modified or deprecated.  Having the ability to model tests and run “what-if” scenarios based on the planned changes is important for keeping the project on track.
  • Tight deadline and development is late
    It is a well-known fact that software development is not an exact science.  Rarely does development deliver their application to QA prior to the deadline on the project plan.  Having the ability to emulate the behavior specific functionality to create regression suites to “test around” the changing functionality is critical for QA satisfying the given project timelines.
  • Last minute changes to the application
    Last minute changes to the application are very common in any software development lifecycle. The test plan should not necessarily have to wait to exercise the application in context of the planned changes.

Overcoming Testing Constraints with Service Virtualization

Service virtualization is key to overcoming testing constraints that moat projects suffer from. By simulating services that are out of your control or unavailable, service virtualization enables users to access complete and realistic test environments, enabling teams to develop and test their applications earlier and more completely. By applying service virtualization in testing environments, organizations can reduce or eliminate the dependence on unavailable, unstable, or costly dependencies, such as 3rd party services, databases, mainframes, etc. Parasoft Virtualize provides intuitive service virtualization solution makes it easy for users to create, scale, and share virtual services.

Using virtual services means quicker recovery from change as fast (or faster) than their real counterparts. Testers can use automated workflows to easily update impacted virtual services and test data as necessary. Automated tools can also keep track of all these changes, with  versioning by storing all relevant data as comparable files that are compatible with standard version control systems.

A key aspect of test automation and service virtualization is the creation and reuse of test assets for not only functional testing but for other critical testing such as security and performance testing.  In addition, it’s possible to rapidly build virtual services on the fly, and inject them with business logic and test data to support local API development. Virtual services benefit from a file-based configuration, making them easy to share between development and QA for defect reproduction and support.

Written by

Rami Jaamour

将最新的软件测试新闻和资源发送到您的电子邮箱。