Overview
Modern software continues to become exponentially more complex, requiring specialized software integration to preserve existing investments while at the same time requiring support for newer technologies and languages like Java, 3rd Party Software and distributed architectures, all of which are changing as well. Each transformation requires exploiting new and improved hardware, software and network environments making customer oriented testing increasingly difficult.
Current testing technologies primarily help companies build software test cases based upon the functional specifications and requirements. However, the industry struggles to capture and test for the “Real” usage of their product by their customers which is outside the functional specifications and requirements. Darwin addresses this problem space while preserving any existing investment in legacy tests that companies and organizations have already.
Modern systems and the requirement to transform stovepipes to yield new capabilities for organizations is a unique testing problem unsolvable using traditional testing techniques and test planning methodologies. Darwin provides advantage in re-use of the existing tests while extending their usefulness to address increasing system test coverage, and to better model the customer’s use scenarios.
Simulating Customer Usage Scenarios
Using proprietary algorithms, Darwin executes existing test plans in varying ways to increase the “Real” usage scenarios employed by the customer in a production environment and also increases the code covered by these existing test suites.
Traceback of Complex Testing Sequences
While leveraging existing test suites, Darwin continues to “invent” approaches to executing tests, powered by the Darwin Engine’s test selection algorithms, until the test execution breaks the system, all driven by a single “Seed” value. This value can be reused at any time in the Darwin Engine reproducing the exact test flow pursued previously. This can be used by development to obtain information such as the states of the software and environment along with sequencing of tests and events assisting development problem fixing in contrast to the “Difficulties of Reproducing a Failure” and the “Hunt & Peck” methods currently being used.
Mean Time Between Failure
As Darwin execution continues to construct test scenarios the average lifespan of those scenarios begins to model “Mean Time between Failure” for the product. Generations represent a sequence testing steps with failure count. The number of failures over the number of test steps performed provides for an “ Average Rate of Failure over a Testing Interval” to be developed.
 |
Failure Rate = Total Number Failures / Number of Test Steps
Mean Time Between Failure
- Product Team Establishes a Testing Time Interval
- Product Team Defines a Ratio of the Testing Time Interval to the Customer Usage Interval called the "Customer Constant"
- MTBF = Number of Failures expected in a Customer Usage Interval
|
Software systems interoperability scenarios, and test integration demands are not covered by current software test development. Federations and “Stovepipe” integration extension includes complex interactions that are statistically improbable to be detected in traditional testing techniques. Current Integration and interoperability testing techniques are inadequate often relying selecting and using data encountered in field-use to extend the breadth of testing. They are unable to provide the richness as supplied by Darwin to simulate these complex interactions as needed by a complete post-integration testing model.
Service Options Available
- e-Factory: Remote access to customer site to perform this service.
- Factory: Perform this service in proServices’ Trenton, NJ Factory.
Service Qualifications
- No legal / access constraints on originating testing platform.
- Testing Limitations - (F) Factory offerings will not be able to test functions when the factory does not possess the same configuration of machines and environment as the customer.
- Service Limitations - (F) factory services need identification that the customer’s Machines, OS’s and COTS are on approved Service lists or requirements to purchase/loan etc. those products and install them in the factory need to be addressed.
