![Představení firmy ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Konference PSQT](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Practical Software Quality and Testing
Semelhante a Practical Software Quality and Testing (20)
Mais de jerrykprague
Último
Último (20)
Practical Software Quality and Testing
- 1. PRACTICAL SOTWARE QUALITY AND TESTING 2008 Zpráva z konference Ing. Jaroslav Kalvoda (prezentace na pracovní snídani, čtvrtek 19.6.2008)
- 26. Move From Monolithic Applications in Steps Intermediate stage: Break out individual services Application Application service service Application Application service Goal: Service-oriented architecture service service service service Application Monolithic applications Application
- 31. Building a Validation Framework System Test E2E Test Unit Test QA Testing Development Requirements Unit Test Standard Interface Agreements (IAs) Augment current processes to populate and utilize framework Interface Agreement Management System Meta data about code droplets across SDLC Interface Simulator and Testing Validates functional code against design (IAs) Validation Framework System Test
- 32. Example: Time to Market Compression PRODUCTION Def Dev Test Backend Billing Systems (eCare/Telegence) Middleware Tier (CSI) Middleware Tier WOW/BAS Tier Def Dev Test Def Dev Test Def Dev Test Requirements CONSULTATION IONA Framework Def Dev Test IONA Framework Def Dev Test IONA Framework Def Dev Test 7-14 Weeks TTM Improvement
- 39. Test Strategy
- 40. Reporting & Tracking Test Milestones
- 41. Reporting & Tracking Test Milestones
- 42. Reporting & Tracking Test Milestones
- 43. Reporting & Tracking Test Milestones
- 44. Reporting & Tracking Test Milestones
- 48. Work Products This diagram shows which Work Products are to be generated for each phase and activity. Red bordered items are produced once, for the whole project, blue bordered items will be produced for each test phase. Test Planning Test Preparation Test Execution Test Strategy Master Test Plan Test Environment Requirements Acceptance Criteria High Level Test Specifications Detailed Test Plan Test Data Acceptance Criteria/ Test Spec. Matrix Detailed Test Specifications Test Execution Schedule Environment Utilisation Plan Test Results Report End of Phase Test Reports Incident Reports Test Process
Notas do Editor
- Ok, so we have talked about the need to design services to support the business’s goals. If we are moving from a non service enabled environment, how do we move toward an SOA in a sensible and controlled way? The answer is to start thinking about monolithic applications as source material for services. Somewhere in the cookie dough of existing applications are nicely formed services wanting to get out. The job is to identify those services that fit general purpose requirements and that can be potentially reused by other applications. These can include redundant functionality (if the same function exists in multiple applications, it’s a great candidate for a service) or functionality that’s clearly needed by multiple applications, such as get customer record, lookup inventory, or calculate current interest rates or currency exchange rates. Eventually once enough services are identified and carved out of existing applications, new applications can be created more and more by combining services.
- The key to developing a good service, is a good contract. A contract allows the parties to a service (i.e. the requester and provider) to agree on terms and conditions, such as what messages will be exchanged and what data will be included in the messages. Well formed contracts also include quality of service requirements for reliability, security, transactions, etc. Service contracts need to align closely with business services, as we’ve said. Service interfaces must be clear, simple, and easy for any requester to understand (stay away from complex data types and structures, avoid execution environment specifics such as return codes, exception codes, or names.) A good service contract is essential to achieve the primary goals of reusability and abstraction.
- WSDL happens to be the best technology available for the implementation of service contracts. It separates the logical contract from its physical deployment, meaning that the definition of the data and the messages to be exchanged is separated from the physical format and protocol used to transport the message and data. This allows multi-protocol and data formats needed in complex, heterogeneous environments. WSDL is easy to create and manage. Import or create new, annotate with QoS (i.e. policy).
- (This slide is optional for some audience. It’s purpose is to establish the broader context of SDLC/QA Solutions that we provide and how ISTF fits into that solution set).
- (Build Slide) The typical problem IONA management consulting personnell see these days is that projects that are simply taking too long. SOA and other distributed techniques are allowing IT organizations to control costs by increasing re-use of assets and increasing the efficiency of increasingly specialized IT teams and providers. On the downside, it has created a situation where major projects are taking significantly longer. - Early proponents of SOA actually claimed it would be faster. But for large projects among the early adoprter this has simply proven not to be true. Like early assembly lines, early SOA adoptions have typically used a sequential model when it comes to project planning. The goal is now to find ways to do more work in parallel and save time. However doing work in parallel creates new risks and problems that must be resolved.
- Pain – how do I manage so many development cycles Multiple projects to deliver, in this example trying to schedule 24 projects of varying complexity. Projects arise from marketing, applications, bugs etc Project managers need to own and deliver, scheduling like lining up the stars – very difficult, requires tremendous co-ordination and increasing pressure on test environment – hardware, software growth. ?And the business wants more,, functionality , applications, changes enhancements etct etc
- If you pressed the power button on your car radio and it doesn’t turn the radio on, this would be a broken feature. If it finally worked every time after smacking it, that would be a work around. Would you want to own that car with that radio?