Software testing is an indispensable part of software development; it aims to assess the software quality and confirm whether the functions meet the requirements defined at the start of the project. In 1990 the IEEE/ANSI defined testing as: "The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component." (IEEE/ANSI, 1990 [Std 610.12-1990]). The "specified conditions" could be comprehended as requirements or designs.

Software Development V-Model Pipeline
We develop software using a process known as the "V" model of systems development. The V model supplies us with an ideal development mode that can help us understand the relationship among different software development phases. The V-model was originally developed from the waterfall software process model. The three main process phases - requirements, high-level design and detailed specifications - have a corresponding verification and validation testing phase. Implementation of modules is tested by unit testing; system design is tested by integration testing; and finally operational testing verifies from the requirements. The V-model gets its name from the timing of the phases. Starting from the requirements, the system is developed one phase at a time until the lowest phase, the implementation phase, is finished. At this stage testing begins, starting from unit testing and moving up one test level at a time until the operational testing phase is completed. According to the V model, testers could enter into the development process at the requirement acquisition phase. So different work could be done concurrently and potential problems could be detected in advance. This is necessary to reduce development risk and lower the cost of correcting errors. (Figure 1)

What Is a Test Strategy?
Why do a test strategy? The test strategy is the plan on how to approach testing. The purpose of a test strategy includes:

• To obtain consensus of goals and objectives from stakeholders (e.g., management, developers, testers, customers, users)
• To manage expectations from the beginning
• To be sure we're "headed in the right direction"
• To identify the types of tests to be conducted at all test levels

  A test strategy provides an overall perspective of testing, and identifies or references:
  

• Project plans, risks, and requirements
• Relevant regulations, policies, or directives
• Required processes, standards, and templates
• Supporting guidelines
• Stakeholders and their test objectives
• Test resources and estimates
• Test levels and phases
• Test environment
• Completion criteria for each phase
• Required test documentation and review methods

Sybase Workspace
Workspace Software Introduction
Sybase Workspace is the first integrated development environment (IDE) that is capable of delivering all of the application types in demand today - service-oriented, mobile, Java, composite, event-driven, or data-driven. Sybase Workspace is built on the Eclipse open source framework, making it easier and faster for developers to develop complex applications that link heterogeneous infrastructures such as databases, messaging systems, and enterprise applications. (Figure 2)

Sybase Workspace fills a void that would otherwise require the use of development tools from multiple vendors that don't offer the ability to interact or cross-pollinate between development tasks. No other IDE offers a similar breadth and depth of functionality.

Sybase Workspace comprises six major components: Enterprise Modeling, Service Frameworks, Integration and Orchestration, Database Development, Mobile and Portal Development, and Web Application Development.

Workspace Characteristics Analysis
From the perspective of testing, Workspace-based projects have the following characteristics:

• The large scale of such projects requires more repetitious testing.
• The software architecture is stable.
• The procedure of software compiling and release is steady and similar among different versions, which requires compiling and unit testing everyday.
• The use of a large number of components raises the risk in problems during integration testing.

  Therefore, the testing process could become more effective and efficient if the test strategy incorporated some of the following changes:
  

• Replace the heavy repetitious manual testing with automatic testing.
• Use testing architecture to form unit testing sets.
• Add everyday compiling, auto unit sets testing, and auto script testing.
• Use more effective and valuable analysis methods to evaluate testing process in order to avoid the high risk in integration.

Workspace Test Strategy
Testing Workflow
1.  Confirm requirements and design
The validity of the requirements and design effects the software development directly; if the software does not meet the customer's requirements, it will be useless no matter how well written. To avoid this situation, testing engineers should participate in the auditing of requirements and design documents. These documents include:

• Requirement Specification written by the project manager, including the information coming from the marketing department and the customer support department
• Functional Design Specification, also written by the project manager, that references the Requirement Specification
• Implementation Design Specification, written by developers, that references the Functional Design Specification

As a testing engineer the core task is to check the integrity, strictness, and function testability of software in these documents. Also this process could help the testing engineers to enter the project earlier.