Thread Based Integration Testing

Thread-based integration Testing Tweet this post
If the project is big enough and we have to deliver early, then, in order to deliver the product on schedule, parallel development and rapid integration that occurred on the related software many functional areas. To facilitate the decomposition of design into manageable components, the concept of thread of a "functional" as a basic element for the integration can be chosen. In this context, a "functional thread" is defined as a logical sequence of implementation through a series of software interface components resulting from or to the receipt of a message, event or operator interaction.

The discussions not only serve as a basis for integration, but also tend to drive the entire software development effort of programming for the submission of status reports. Each thread itself represents a microcosm of the system in which each has a documented definition and general execution path, interior design and testing of partners. Hilo definition is intended to communicate functional background and details of implementation between the developers and from developers to testers. More importantly, the desired independence of threads supports the progressive integration and system testing, while the corresponding thread definition corroborates the results. Finally, since all system development activities are progressing in relation to the issues, the management has an accurate method of judging the status of individual tasks, functional areas and requirements.

Maintenance of the objectives of iterative development and software testing in mind, each thread has its own life cycle autonomous states and a formal process for state transitions. Team leaders normally break down the general requirements in clusters at the beginning of officers, six months of software builds and assign issues to developers. Developers maintain ownership of its threads and are responsible for the documentation of a scenario in which an integrator can verify the basic functionality, providing the rudimentary definition thread. After implementation and testing unit, the developer releases of the software components corresponding to a daily build integration, at which time the thread enters a "testable" state. After verifying the functionality in the integration of construction, the developer marks the thread "ready" for an integrator that performs more extensive testing, and finally "integrates" the thread and corresponding software components in the system. At the end of formal construction, a team of key engineers in relation to quality control against all topics as requirements for regression testing and the latest "hot" items that happen.

While the original development team follow-up discussions manually, quickly developed an application of shared database to serve as a central repository for the development of thread, maintenance and monitoring. The database provides a formal mechanism to define and document the discussions, the thread state change and status reporting to project management. Moreover, the database manages references between threads. Themes can serve as preconditions for other threads and developers can incorporate wire test measures the previous discussions. Most importantly, the interface helps to strengthen the process by demonstrating the autonomy of the subject yarn and the establishment of clear responsibility between developers and testers.

Thread Test Steps
Thread test steps and other materials from the database will serve as a contract between developers and integrators. Hilo integrators steps use the test as a simple scenario to determine the scope of a thread, rather than a rigid test case that can only rubber-stamp a developer unit test. Therefore, integrators are responsible for developing various scenarios of implementation within the bounds of the thread and the application of appropriate testing mechanisms, known as exceptional cases and border control. In addition, the integration team often dwells in the performance of the subsystem integration test, which was an area that steps thread often overlooked.
In addition to helping formalize the application process, the focus of the thread test standardizes the integration testing process. As a result, the number of coding errors increased almost 250 percent over three after the formal test is based yarn were introduced. Despite the errors attributable to the integration doubled during the first formal construction in which our group uses thread later, that number has dropped to almost fifty percent below the level at which we started using threads.

While thread-based development undoubtedly contributes greatly to the main objectives of the early, rapid integration and iterative development, we have also identified several potential areas of process improvement. Perhaps most notably, developers and testers shared the concern that the scope thread is no uniformity among the subsystems. Sometimes, the definitions were too specific thread and integrator of consciousness can check the basic functionality in fewer steps than the developer identified. Similarly, developers sometimes defined topics at a level too high, requiring the integrator to seek more information from the developer to ensure a significant test. A review process thread, perhaps as part of a walk through the design, they can respond to this problem. It is also recommended to require the completion of a walk through code as a prerequisite for the realization thread because of the implications of walking through the design and code changes.

Maintenance thread
A related area is the maintenance of the improvement thread. While the process was encouraged (and supported database) refers to discussions of other issues, maintaining consistency was not always an easy task. Moreover, while software that composes a theme often changes after a thread has been integrated, there is no formal process for updating the thread. The changes in this process are evident and could modify the tool to help meet these concerns. For example, the tool would benefit from the ability to attach the references to the source code units for the changes in the code could trigger the need for changes associated thread.

In addition, empirical results suggest that the introduction of wireless exposure tests based on design and coding errors before and fewer errors attributed to the integration process itself, probably due to increased communication between developers and testers. In summary, our method seems to have timed the concept of completion of tasks among the developers, testers and management.

Abstract -Thread-based integration testing played a key role in the success of the software project. At the lowest level, is provided to integrators with a better understanding of the scope of what may prove, in effect, a contract between developers and testers. At the highest level, provided a unified state monitoring method and facilitated an agreement between management and developers as to what should be provided at each formal build. Moreover, instead of testing software components directly, it requires integrators to focus on tests of logical execution paths in the context of the entire system. Because of this, strongly supports the objectives of integration early, rapid, along with an iterative development approach. In summary, the approach of thread can result in tangible situations executable driving the development and integration, while the self-employed, well-defined thread States reinforce the use of threads as an accurate method of programming and monitoring of their condition.