Development and implementation of a complex testing framework for sophisticated critical care products for the worldwide leader in medical device manufacturing.
The key features of the project include:
- 100% coverage of functional test cases
- 100% coverage of regression automated tests scripts
- The integration framework with automated testing tools protocols
- Definition of the test specifications and manual test implementation
- Design and implementation of complex automated testing frameworks based on Rational Robot and CppUnit unit testing library
- Design and implementation of several debugging and inspecting tools
- Implementation of Unit tests in accordance with high-level component requirements
- Integration of resulted products into Customers components environment
Tools and technologies: С++; XML; MVS 2003; CppUnit; Rational Robot; Team city; SCRUM Works
You can download full version case-study via link
This is Part #3 of the series of posts devoted to combining agile methodologies with software development outsourcing. You can find Parts #1 and #2 here and here.
One of the main challenges in agile outsourcing is organizing the agile process (e.g., Scrum) in a distributed team. Typically, the Product Owner is on the client side, while the development team is on the provider side, often several time zones away from the client. The Scrum Master is normally residing with the development team, though some clients insist on using their Scrum Master. But let’s leave the remote Scrum Master situation for somebody else to dissect and concentrate on the ever-present issue: the remote Product Owner (PO). Continue reading
Agile is far from being a purely hype-driven software development phenomenon. In fact, if you think about it, it’s a very natural methodology to embrace for technology vendors.
First, a company that develops its own high-tech product—hardware and software—has to deal with constantly changing requirements. You get new clients (especially new key clients at the dawn of the new product development), and they bring new requirements. You hit the market with a new version, and you get feedback that affects your roadmap. You start developing something only to be met with unforeseen technical obstacles or come up with a new inventive approach that simplifies everything but affects the way your project looks and feels. In short, you never know how your requirements will change in three months from any point in its lifecycle. Continue reading