Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Testing Throughout The Software Life Cycle

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 10 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Testing Throughout The Software Life Cycle (20)

Anzeige

Aktuellste (20)

Anzeige

Testing Throughout The Software Life Cycle

  1. 1. Testing Throughout The Software Life Cycle Jurusan Sistem Informasi Fakultas Sains dan Teknologi Universitas Islam Negeri Sultan Syarif Kasim Riau Siti Rubayati
  2. 2. • SOFTWARE DEVELOPMENT MODELS 1
  3. 3. V-Model
  4. 4. Although variants of the V-model exist, a common type of V-model usesfour test levels. The four test levels used, each with their own objectives,are: 4  componenttesting:  Virsearches for defects in and verifies the functioning ofsoftware components (e.g. modules, programs, objects, classes etc.) that areseparately testable;is sensibus sit no. Mei ei delenit maiorum copiosae.  systemtesting  concerned with the behavior of the whole system/product asdefined by the scope of a development project or product. The main focus ofsystem testing is verification against specified requirements  integrationtesting:  tests interfaces between components, interactions to different parts of a system such as an operating system, file system and hardware or interfaces between systems  acceptancetesting  validation testing with respect to user needs, requirements, and business processes conducted to determine whether or not toaccept the system
  5. 5.  Not all life cycles are sequential. There are also iterative or incremental lifecycles where, instead of one large development time line from beginning to end,we cycle through a number of smaller self-contained life cycle phases for thesame project. As with the V-model, there are many variants of iterative lifecycles. Iterative life cycles
  6. 6. Rapid Application Development  Rapid Application Development (RAD) is formally a parallel development offunctions and subsequent integration.
  7. 7. Dynamic System Development Methodology  Dynamic System Development Methodology [DSDM] is a refined RADprocess that allows controls to be put in place in order to stop the processfrom getting out of control. Remember we still need to have the essentials ofgood development practice in place in order for these methodologies towork. We need to maintain strict configuration management of the rapidchanges that we are making in a number of parallel development cycles.From the testing perspective we need to plan this very carefully and updateour plans regularly as things will be changing very rapidly (see Chapter 5 formore on test plans).  The RAD development process encourages active customer feedback.The customer gets early visibility of the product, can provide feedback on thedesign and can decide, based on the existing functionality, whether toproceed with the development, what functionality to include in the nextdelivery cycle or even to halt the project if it is not delivering the expectedvalue. An early business-focused solution in the market place gives an earlyreturn on investment (ROI) and can provide valuable marketing informationfor the business. Validation with the RAD development process is thus anearly and major activity.
  8. 8. Agile development It states that integration and testing of the code shall happen several timesa day. It states that we always implement the simplest solution to meet today'sproblems It promotes pair programming and shared code ownership amongst thedevelopers. It states that component test scripts shall be written before the code iswritten and that those tests should be automated. Extreme Programming (XP) is currently one of the most well-known agiledevelopment life cycle models. (See [Agile] for ideas behind this approach.)The methodology claims to be more human friendly than traditional development methods. Some characteristics of XP are: It promotes the generation of business stories to define the functionality It demands an on-site customer for continual feedback and to define andcarry out functional acceptance testing.
  9. 9. Testing within a life cycle model the analysis and design of tests for a given test level should begin during thecorresponding development activity; each test level has test objectives specific to that level; for every development activity there is a corresponding testing activity; testers should be involved in reviewing documents as soon as drafts are available in the development cycle.
  10. 10. Thank you http://sif.uin-suska.ac.id http://fst.uin-suska.ac.id http://uin-suska.ac.id Sumber : Graham et.al (2011)

×