Presentation Material
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Presentation Material

on

  • 321 views

 

Statistics

Views

Total Views
321
Views on SlideShare
321
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Pete Couper – (Probably already covered in the intro.) I work for AMR & Associates, a Wellington based independent IT professional services company. I am Practice Manager of the Systems Integration and Testing practice. I have over 1 5 years IT experience. Computer Science Degree from University of Canterbury, 7 years at LINC Dev Centre Chch, I have been in Wellington since early 1996 Why – The quality of solutions that are deployed into production is something that has interested me for sometime. I am here to share some of my thoughts in 1 of the areas that influence quality , that of testing and the skills required by testing professionals . Topic – This topic, Contemporary Application Development: Are Testing Teams and Techniques Keeping Pace? , covers an area that I have been doing some research into while developing our Testing services at AMR & Associates . As I go through you will notice that some of the slides have changed slightly from what you have in your notes. Session is 45 mins, the presentation is 4 0 mins allowing approximately 5mins at the end for questions.
  • “ Software development practices have changed dramatically over the years. They have gone from small, local teams working on relatively straightforward applications, to highly complex applications developed and continually enhanced by large, distributed teams. The new applications represent multi-faceted, cross-disciplinary efforts that involve the work of many individual contributors. They are orders of magnitude larger and more complex than applications of only a decade ago, and they have been profoundly influenced by the Web and the move to e-business. In short, contemporary application development depends on too many contributions, from too many individuals, to be managed with notes, meetings or the heroic efforts of individuals. ” “ Planning your SCM Growth Strategy” a White Paper from Merant. What I mean by Contemporary Application Development . . . I am using the term “ Contemporary Application Development ” fairly loosely here to cover – current technology, life cycle and project methods/approaches , that are generally accepted “best practice”, at this time.
  • Cross Org. Bus. Process Integration: In a number of business sectors this is a new “trend” where online integration of business processes requires the definition of public/published interfaces to your systems (via Web or other). E.g. eProcurement – integration of the procurement business process across organisations. Enterprise View: There is an increasing awareness of the value of looking at IT from an enterprise perspective, this includes Enterprise Data Models , Enterprise Architecture , Enterprise Application Integration (EAI) etc.
  • ROI: Many argue that IT has got away with murder from an ROI perspective over the last 20 years. This has lead to a significant increase in the focus on the real value that an IT Project will return to the organisation. Speed to Market: This seems to be ever increasing and is arguably the drive behind the componentisation (discussed later) etc. (Which is ultimately a drive towards commoditising software – like microwave ovens or cars). This is meaning new technology and more (time) pressure on all stages of projects including testing. Aside - Where is Quality? It is interesting to note that while time (speed to market) and cost (ROI) are included in recent trends the other corner of the triangle, Quality, is not mentioned! Less Large Projects: Following the failure (and very public failure) of some large projects (most notably INCIS) there has been a strong move away from large projects to smaller and more “containable” project (from a scope, budget and media POV). Buy/Build: To some extent this follows from the speed to market point above. It also stems from the “best of breed” notion. That is, why build from scratch when we can buy a product and configure/modify it to meet our specific needs. Agile: I have shown a number of Agile Development Methods here to show that there is significant activity in this area, it is real and it is here to stay! eXtreme Programming (XP) Scrum – The term scrum originally derives from a strategy in the game of rugby where it denotes “getting an out-of-play ball back into the game” with teamwork (Schwaber and Beeble 2002) Feature Driven Development (FDD) Dynamic Systems Development Method (DSDM) Adaptive Software Development (ASD)
  • Speed of Change: As always technology is moving quickly, by the time a project is complete it can be viewed as being built on old technology. Or in fact, as has happened to me, the Chief Architect can start referring to the application that you are still working on (I.e. it has not gone live) as legacy !! That is a fairly strong indication that things have changed under you! Technology Mix: It is common, in part due to the speed of technological change but also due to simple Architectural drift (change of Chief Architect, Arch. change due to problems with previous project etc.), for organisations to end up with a mix of technologies that all need to be able to talk to each other . This can present significant problems. Component Based: Componentisation is a new twist on the Buy/Build – a component is :- “ A Component is an independent, encapsulated and physical part of a system. . . . A Component may be developed, tested and deployed in complete isolation to other components within the system, even if it seems unlikely that the component ever will be deployed in isolation it should still be possible. This is important for testing and quality.” - From www.componentgroup.com Web Services: What are Web Services – we’ve all heard of them but what is a simple definition. “ Web services are self-contained business functions that operate over the Internet. They are written to strict specifications to work together and with other similar kinds of components. . . . Web services give companies (like ours) the capability do more business electronically, with more potential business partners, in more and different ways than before, and at reasonable cost.” - From www.webservices.org EAI: Enterprise Application Integration is a challenge that faced by a number of organisation. How do I pass information between disparate (often legacy) systems? How can I implement a comprehensive CRM solution when customer details are held in multiple systems? EAI is under technology due to the number of products that exist in the market place to assist with solving these question and due to the complex technical nature of the integration of disparate systems within and across organisations.
  • Fully Integrated Environment: With software solutions now including integration with existing legacy systems, off the shelf packages, various delivery channels etc. it is essential that testing is carried out in a fully integrated environment. Test Multiple Delivery Channels: Some delivery channels may in fact be difficult and/or expensive to test as they may require special equipment or co-ordination with external Organisations. Requirements: With Agile Development Methods traditional testing processes will struggle as requirements could change repeatedly throughout the life of the project. Time Pressure: This is nothing new it seems that time pressure has always been part of Software Development however it does continue to increase and a number of promises are being made to business that speed to market will be improved. These come from Componentisation, Agile Development Methods etc.
  • Complex Test Planning: The prospect of a multi-system, multi-package, multi-vendor project should send a chill up the spine of even the most experienced of testers. However more and more this is becoming the norm , the planning required to test a software solution of this sort is complex and requires buy in from all parties involved . Then of course when something changes . . . Support for new Packages: When new packages are introduced as part of a project it is common for there to be limited support for the package especially from the operations group who may not have even seen t he package before. What can happen is that at the end of the project the group that has the best understanding of the new package is the testing team as they have had to investigate problems that occurred during testing. Identify Faults: With multiple vendors and potentially multiple packages it becomes more difficult for tester to analyse the faults that they find and assign them to the appropriate vendor for them to be resolved. Match Prod. Environment: Given the complex nature of the solutions being developed it is very difficult (verging on impossible without spend vast amounts of money) to get testing environments that match the production environment. This has the most impact on Technical and Performance testing.
  • Non-functional Testing: With the complex integrated software solutions that we have been discussing it is essential that both functional and non-functional testing is undertaken. I like to refer to non-functional testing as “abilities” testing as what we are doing is testing the various “-abilities” of the system – I will discuss these later in the presentation. Environment Stability: Again with the complexity of the software solutions being built it can be expected that the test environments stability may be at risk. The System support group have production that takes priority, multiple vendors are releasing changes into the same environment, the box may well be shared with the (or part of the) development team or another test team or even belong to another organisation etc. Test on Incomplete Solution: With iterative development and, potentially, different delivery dates for various vendors it may be necessary or desirable to test with the parts of the solution that are available. The more traditional testers amongst us may struggle with this. There can be a feeling that testing on an incomplete solution is a waste of time as all of the testing done will have to be re-done when the complete solution is finally delivered to the test team. Synchronisation Issues: Depending on the solution under test there may well be a requirement that user access needs to be defined across multiple systems, all of these system s need to be up and running, data synchronised in the various systems and even the date of the systems may need to be rolled forward together. I have lumped these all under synchronisation but they may well appear to the tester as system stability issues and to the developers/system support as poor planning by the testers.
  • We should be taking an Enterprise view of testing, as we are with other aspects of IT – Enterprise Architecture , Enterprise Data Models , Enterprise Application Integration etc.. To do this it is necessary to develop an Enterprise Level Test Strategy that covers – all existing systems plus all IT projects in progress and yet to be undertaken. The Test Strategy should be a reference document that is used by Project Managers and/or Project Sponsors during project initiation, it should essentially tell them how it is done in this organisation. not only the testing carried out internally it must also include the testing that is undertaken by vendors . This should clearly define where demarcation lines need to be set to ensure that no aspect of testing is missed and equally as importantly that there are no significant overlaps . This will require negotiation with vendors and may need to be included in Service Level Agreements (SLAs) and/or Maintenance/Project Contracts. All Test team involvement in the SDLC . It is appropriate to define what and when the test team should be involved in BAU as well as projects. If your organisation expects the test team to make tea & coffee for the development team throughout the build phase of the project or only passes system requirements to the test team once they have been signed off by the business then that should be stated in the Test Strategy, Project Managers will need to know this so that these activities can be included in budget and schedule development during project initiation . Some additions to what is seen as “normal” are discussed later in this session. The aim of the Enterprise Test Strategy is to ensure that appropriate levels of testing are being undertaken and that the organisation is getting value for its testing dollar .
  • Test Plan More complex due to (point to list) multiple systems, packages, external Orgs, integration etc. It is critical that the test plan is clear and signed off by all parties involved. The Test Plan should be the “contract” between all parties involved in the testing effort (vendors, operations, both internal and external groups etc.). Test Early Testers look at things differently to BAs - a BA works with the business to establish and then document the user requirements. They are constantly looking at how the system should or will work , they define the requirements so that the business can review them and sign them off as complete. A tester is not constrained to only look at what the system is required to do they should also ask questions as to what will happen in various circumstances or conditions. They will review a user requirements document with “How can I test this requirement?” in their mind. If the user requirements are not testable then the chances are that the development team will struggle or will fill in the gaps by making assumptions. The same applies with Use Cases except with Use Cases you can get the testers involved in the definition of the Use Cases . This will increase joint ownership (i.e. reduce any us and them that exist between BAs and Testers). Get the BAs to define the Use Case and then get the testers to go through and review the Use Case and add the alternate flows. The tester should be thinking “What if …?” when they review the Use Case, they should add these as alternate flows . Finally, take advantage of iterative development , test what is delivered (even though it is not the complete solution). Take the opportunity to help improve the final version of the solution that will be delivered for full end-to-end testing.
  • Plan to allow Testers Flexibility Testers should be trusted to follow “hunches” that they have. That is, if they believe a part of the system that they have touched on when executing a script feels flaky there should be enough room or flexibility in the Test Plan to allow them to do some exploratory testing in this area. The testers should not be constrained by rigid scripts and an inflexible test schedule. This has to be within reason and should be monitored to ensure value. Include Non-functional Testing Simply put Non-functional testing is the process of testing the non-functional requirements of the systems, however it is seldom this simple as the non-functional requirements usually do not exist or a woefully inadequate . It is often better to approach non-functional testing completely unencumbered (I.e. ignoring any requirements that may exist) and look at the system “-abilities”. These include reliability, scalability, recoverability, availability, usability, manageability, compatibility, even securability (I saw it on a Microsoft site once so it must be a word!). Mix of Testing Techniques Don’t restrict yourself to a single type of testing , automated testing is valuable, manual testing is also valuable and exploratory (or ad-hoc) testing is valuable too. But what has the most value is using a mix of these testing techniques. With automated testing you run the chance of missing the same faults over and over , manual testing coverage can vary from release to release and with exploratory testing there is no guarantee that you will get adequate coverage . However with a combination of the 3 you will get the benefit of all and the weaknesses will be picked up by the others.
  • Risk Based Approach to Testing A Risk Based Approach to testing best suits the Non-functional Testing of a solution and is especially useful when there are no or minimal Non-functional Requirements. However it can also be very usefull for testing BAU releases – in this case the Work Requests/Changes that have been made can be analysed and based on these the testing restricted to save time and money. Test Mission Is this project high profile (mission critical) and subject to external scrutiny (e.g. Internal Audit, External Audit, Central Agencies etc.) or is it building a brochure-ware website that needs to be operational in the shortest possible time? These systems would have very different Testing Mission s and this would influence the testing process that is followed (e.g. fully documented, complete audit trail etc. or total ly based on exploratory testing driven off a risk analysis, no documentation etc.) Risk Assessment There are 2 approaches that can be used for a solution risk assessment, both rely on the experience and technical appreciation of the testers conducting the risk assessment. Both approaches are best carried out in a workshop session . The first approach is an Outside-in look at the solution . Go through each of the “-abilities” and ask what risks are there for this solution for this “-ability” e.g. Manageability or Recoverability etc. The second approach is an Inside-out look at the solution . This entails having a workshop with the Solutions Architect and Technical Team Lead (or similar) and getting them to explain how the solution is actually built, as they do this you should be asking what if this link/component/module or what ever fails . Basically with the testers experience of other solutions similar to this one and with the explanations and answer given a list of risk should be captured. Both of these approaches will result in a list of risks that apply to this solution. Risk Prioritisation The next step is to go through and prioritise the risks based on the Likelihood of the risk occurring and the consequence if it did occur . Risk Task List Now that you have a prioritised risk list what do you do with it? The first thing that you do is put together a Risk Task List. Simply put a Risk Task List states “If you are concerned about ‘x’ then you need to do ‘y’ (draw this on the white board). This is the first (and in some cases – brochure-ware site – the last) step in producing your test scripts. Aim – “Find the fundamental faults fast” – that is reduce the chance of project slippage due to a fundamental fault being found at the end of the testing cycle.
  • Glenford Myers is the author “The Art of Software Testing” 1979. This book soon became the bible of the Software Quality movement. In his book, he talks about the importance of Inspections, Black and White Box testing, and the benefits of regression testing. It is interesting that these same terms are still widely used today!
  • Technical Appreciation is not intimate knowledge of the particular technology (e.g. Java – J2EE - .NET – C++ etc.). Technical Appreciation includes having an understanding of what can go wrong in your production environment (especially important when development is outsourced ). It is the ability to understand, logically, what the solution must do to achieve the desired results – in fact it is being interested/inquisitive as to how it actually works “under the hood”.
  • Test Team Build Test Plans We have just discuss test planning and how complex this can be for an integrated solution. This task, however, is still the responsibility of the Test Team. The Test Team needs to include resources that can develop a comprehensive test plan that covers all aspects of testing the solution. From environment set-up to data set-up. Resources required both human & environmental. Predicted release schedules, test cycles, batch processing, date rolling etc. Analyse Faults In a project that involves multiple vendors/systems and (potentially) organisations significant time can be lost when faults are not analysed sufficiently before being assigned. A fault that is assigned to the wrong vendor or system can “bounce” around for some time before it is “owned” and resolved. This can also happen when appropriate levels of technical detail are not included in the fault report (I.e. irrefutable evidence) – vendors blame each other, the infrastructure or the configuration in the testing environment. The more complex the environment you are working in the more important it is to analyse the fault and be very clear where the ownership lies. Identify then Prioritise Risks It can be argued that testing is all about risk mitigation and therefore it makes sense to mitigate the highest risks (in terms of likelihood and consequence) early in the testing phase. Also if you do use a risk-based approach to testing then it is a basic requirement that you are able to identify risks and then prioritise those risks. Risk identification comes from a number of source – previous experience, discussions (or workshops) with developers, complexity of requirements (either functional or non-functional), introduction of new technology (either to the dev. Team or to the operational environment) etc. Non-functional Test Scripts Non-functional test scripts often involve testing the behaviour of the solution when failures (or partial failures) occur. Generally these tests are best executed when the solution is under normal business load. For example in an n-tier system with a clustered middle tier what happens if 1 of the application servers is powered off while the system is under load? The system should continue to operate, response time s may be impact ed but the system should remain functional. There are many other scenarios that may be covered in non-functional testing and a number of them will require the tester to have a good technical understanding of the solution and the environment it runs in.
  • Testing Professionals - When I say Testing Professionals I mean team members who have been trained and are experienced tester, preferably they have chosen testing as their career of choice. Not all members of the test team need to be Test Professionals but the experience and knowledge that they bring to the table is very valuable for the test team as a whole. Testing Professionals Understand Technology - When working with complex integrated software solutions it is important that the Test Professionals have appropriate technical experience and skills. The test team will be required (as stated earlier) to develop a Test Plan that is comprehensive, the more complex the solution the more important the Test Plan. When technical faults are discovered these need to be analysed and then reported to the vendor, these faults will be resolved much more quickly if the Test Team contains resources that can communicate with the development team in terms that they understand – by having Test Professionals that are technically capable any communication gap between the Development Team and the Test Team can be bridged. Mentor/Train Business Resources - Business resources that are added to the Test Team should be given training in testing techniques and processes, at the very least they should get significant support and mentoring from the experienced members of the team. It is not fair on them or the rest of the Test Team to just dump them in the deep-end to see if they will swim. You may not discover that they were not doing a good job until the module they were testing is deployed into production. Consider Outsourcing - It may make more sense for your organisation to outsource complex test planning or the more technical testing tasks – including Scalability, Reliability, Compatibility, Securiability (there it is again) etc. These areas of testing are specialised and depending on the solution under test may not be required on a regular basis - I.e. not required for monthly business as usual releases but required for any more significant changes/projects or specific changes like changes to searching or infrastructure upgrades etc.
  • Quote from AsiaSTAR (STAR - Software Testing Analysis and Review ) Conference call for papers – “Our job is often a complex and difficult one. We are faced with many challenges, including increasingly complex integrated solutions, an ever-expanding assortment of tools and techniques, and market-driven time and budgetary constraints. At the same time, we are expected to remain effective in our testing methods and efficient in our process of doing so. “
  • Test Professionals Essential This is absolutely the case when the software solution under test is complex. Testing is a Profession Gone are the days that the newest resource in the Development Team is made the tester, if they show promise they are “promoted” to Business Analyst. And then if they are good they move up to project management. Testing is becoming a respected career in it’s own right and a respected and valued part of the development team. As it should!!

Presentation Material Presentation Transcript

  • 1. Contemporary Application Development Are Testing Teams and Techniques keeping pace? Pete Couper AMR & Associates [email_address] October 200 3
  • 2. Question!
    • How many of you have been in Testing Teams asked to transition from
      • Mainframe environment, predominantly batch/file based interfaces, to
      • GUI based N-tier solutions with complex realtime integration across bespoke and shrink wrapped systems including integration to legacy systems running in vendor supplied frameworks (eg application server or .NET)?
    • What process changes, training and tools were supplied to help you with this transition?
  • 3. Session Outline
    • Contemporary Application Development Defined
    • Contemporary Application Development – Challenges for Testing
    • Some Contemporary Testing Techniques
    • A look at a Contemporary Testing Team
    • Session Summary
  • 4. Contemporary Application Development Defined
    • Dictionary definition of Contemporary
      • Date: 1631 1 : happening, existing, living, or coming into being during the same period of time 2 a : SIMULTANEOUS b : marked by characteristics of the present period : MODERN , CURRENT
    • Often Contemporary Application Development refers to :-
      • Methods, or
      • Tools
  • 5. Contemporary Application Development Defined (cont.)
    • What do I mean by Contemporary Application Development?
      • Method used & Structure of Teams
      • Tools – both Development and Runtime
      • n-Tier, distributed
      • Mix of bespoke, shrink wrapped, legacy
      • Complex integration – sync and async
      • Web Services – internal and/or external
      • Cross organisation business process integration
      • Etc.
  • 6. Contemporary Application Development Defined (cont.)
    • Emphasis on “Speed to Market” & ROI
    • Less Large Projects
    • Increase in Buy/Build
    • Agile Software Development Methods (XP, SCRUM, FDD, DSDM, ASD etc.)
  • 7. Contemporary Application Development Defined (cont.)
    • Speed of Technology Change
    • Mix of Technology
    • Service Oriented Architecture (SOA)
    • Enterprise Application Integration (EAI)
  • 8. Session Outline
    • Contemporary Application Development Defined
    • Contemporary Application Development – Challenges for Testing
    • Some Contemporary Testing Techniques
    • A look at a Contemporary Testing Team
    • Session Summary
  • 9. Contemporary Application Dev . – Challenges for Testing
    • Need fully integrated test environment
    • Ability to test multiple delivery channels
    • Changing requirements
    • Ever Increasing Time Pressure
  • 10. Contemporary Application Dev . – Challenges for Testing (cont.)
    • Complex test planning
    • Lack of support for new packages
    • Faults hard to identify/define
    • Hard to match Prod. Environment
  • 11. Contemporary Application Dev . – Challenges for Testing (cont.)
    • Non-functional testing of solution
    • Environment stability
    • Testing on incomplete solutions
    • Access, availability, data & date sync. issues
  • 12. Session Outline
    • Contemporary Application Development Defined
    • Contemporary Application Development – Challenges for Testing
    • Some Contemporary Testing Techniques
    • A look at a Contemporary Testing Team
    • Session Summary
  • 13. Some Contemporary Testing Techniques
    • Develop a Test Strategy that
      • Takes an Enterprise Level view of testing
      • Covers all existing Systems
      • Defines “How to” for Projects
      • Includes vendor testing – for both Business-as-usual and projects
      • Covers the Testing Teams involvement throughout the SDLC
  • 14. Some Contemporary Testing Techniques (cont.)
    • Test Planning is more complex
      • Multi system, fully integrated, data driven, external interfaces, delivery channels, new packages, mix of technology, multiple vendors, incomplete solution, non-functional testing, etc.
    • Plan to Test early
      • Testers review functional and non-functional requirements specifications prior to sign-off
      • Testers review Use Cases and define alternate flows in Use Cases, again, prior to sign-off
      • Test iterations as they become available
  • 15. Some Contemporary Testing Techniques (cont.)
    • Plan to allow Testers flexibility
      • Testers should be encouraged to follow “hunches”, not simply stick to a rigid script
    • Plan to include Non-functional testing
      • Test the System “-abilities”
        • (Reliability, Scalability, Recoverability, Availability, Usability, Manageability, Compatibility, even Securability etc.)
    • Include a mix of testing techniques
      • Automated
      • Manual
      • Exploratory
  • 16. Some Contemporary Testing Techniques (cont.)
    • Consider a Risk Based approach to testing
      • Define testing mission
      • Risk Assessment
        • Outside-In – “-abilities”
        • Inside-Out
      • Risk Prioritisation
      • Develop Risk Task List
    Aim – “Find the fundamental faults fast”
  • 17. Session Outline
    • Contemporary Application Development Defined
    • Contemporary Application Development – Challenges for Testing
    • Some Contemporary Testing Techniques
    • A look at a Contemporary Testing Team
    • Session Summary
  • 18. Glenford Myers Quote
    • The design of “good” system test cases requires more creativity, intelligence and experience than required to design the system.
  • 19. Glenford Myers Quote - Modified
    • The design of “good” system test cases requires more creativity, intelligence, technical appreciation and experience than required to design the system.
  • 20. A Contemporary Testing Team (cont.)
    • Test Team is expected to develop a comprehensive Test Plan
    • Faults need to be identified and reported to appropriate vendor
    • Ability to identify and prioritise risks
    • Non-functional testing scripts need to be developed and executed
  • 21. A Contemporary Testing Team (cont.)
    • Test Teams need Testing Professionals
    • Testing Professionals need to understand technology
    • Business resources added to the Test Team need to be trained and mentored
    • Consider outsourcing technical testing tasks e.g. Test Planning, Performance Testing , Reliability Testing
  • 22. Session Outline
    • Contemporary Application Development Defined
    • Contemporary Application Development – Challenges for Testing
    • Some Contemporary Testing Techniques
    • A look at a Contemporary Testing Team
    • Session Summary
  • 23. Session Summary
    • Contemporary Application Development has increased the complexity of software solutions
    • This complexity directly impacts on testing
    • The effectiveness of testers will reduce if they do not change how they approach testing
  • 24. Session Summary (cont.)
    • Comprehensive Test planning is critical when testing a complex software solution
    • It is vital the Testing Team contains the experience and technical skills required
    • Test Professionals are essential to ensure a quality outcome
    • Testing is a profession in its own right, it needs to be recognised as such
  • 25. Session Summary (cont.)
    • We have Contemporary Application Development
    • Is it time that it is complemented by
    • Contemporary Application Testing?
    Well I think it is!
  • 26. THE END Questions?
  • 27. References
    • James Bach – Satisfice Inc. – www.satisfice.com
    • www.Stickyminds.com
    • “ Project Survival Guide” & “Rapid Development” - Steve McConnell
    • Dr. Magdy Hanna – International Institute for Software Testing – www.softdim.com/iist
    • Glenford Myers – “The Art of Software Testing” 1979
    • To get a soft copy of this presentation go to:-
    • www.amr.co.nz