1 / 17

Kualitas Perangkat Lunak (lanjutan) Pertemuan 3

Kualitas Perangkat Lunak (lanjutan) Pertemuan 3. Matakuliah : M0232/Testing dan Implementasi Tahun : 2008. TIK. Mahasiswa akan dapat menjelaskan dua macam metoda yang dapat digunakan untuk melakukan penilaian dan analisa terhadap resiko kualitas. (C2) TIK-10

pahana
Download Presentation

Kualitas Perangkat Lunak (lanjutan) Pertemuan 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Kualitas Perangkat Lunak (lanjutan)Pertemuan 3 Matakuliah : M0232/Testing dan Implementasi Tahun : 2008

  2. TIK • Mahasiswa akan dapat menjelaskan dua macam metoda yang dapat digunakan untuk melakukan penilaian dan analisa terhadap resiko kualitas. (C2) TIK-10 • Mahasiswa dapat menerangkan pengelompokan tahap-tahap proses pelaksanaan pengujian. (C2) TIK-11 • Mahasiswa dapat menyebutkan faktor-faktor yang harus diperhatikan untuk mengestimasi sumber daya dan anggaran yang diperlukan. (C1) TIK-12 • Mahasiswa dapat menjelaskan relasi antara jadwal, sumber daya, anggaran, dan faktor kualitas dalam perencanaan pengujian. (C2) TIK-13

  3. Penilaian dan Analisa Resiko Kualitas

  4. Resiko Kualitas • Bug/Kesalahan yang mungkin terjadi disebut sebagai resiko kualitas (quality risk). • Gejala yang ditimbulkan oleh bug yang dapat dirasakan disebut mode kesalahan (failure mode). • Ada dua metode yang dapat digunakan untuk melakukan penilaian dan analisa terhadap resiko kualitas: (1) Metoda Informal; dan (2) Metoda Formal.

  5. Informal Risks Analysis Techniques • Goals: Address as many of quality risks as possible, developing tests in an order consistent with customer priorities. • Breaking down the test process into the classic phases of component testing, integration testing and system testing

  6. Component Testing • States • Transactions • Code Coverage • Data Flow Coverage • Functionality • User Interface • Mechanical Life • Signal Quality

  7. Integration Testing • Component or subsystem interface • Functionality • Capacity and volume • Error / Disaster Handling and recovery • Data Quality • Performance • User Interface

  8. Functionality User Interface Operations Capacity and Volume Reliability, Availability, and stability Error/disaster handling and recovery Stress Performance Date and Time Handling Localization Network and Distributed environments Configuration option and compatibility Standard compliance Security Environment Power Input, consumption and output Shock, vibration and drop Installation, cut-over, setup and initial configuration Documentation and Packaging Maintainability Alpha, beta and other live tests System and Acceptance Testing

  9. Failure Mode and Effect Analysis • A Formal Method for Understanding Quality Risks • FMEA is a technique for understanding and prioritizing possible failure modes (or quality risks) in system functions, features, attributes, behaviors, components and interfaces

  10. 3. What you can test? Jadwal, Sumber Daya, dan Anggran (Schedule, Resources, and Budget)

  11. Schedule, Resource, Budget

  12. Tahap-tahap Proses Pelaksanaan Pengujian • Perencanaan • Konfigurasi • Pengembangan • Pelaksanaan

  13. Penerapan: Fitting a Test Schedule into the Project

  14. Perkiraan Sumber Daya dan Anggaran • Staf • Alat Bantu Pengujian (Test Tools) • Fasilitas dan Pendukung • Sistem Pengujian • Laboratorium Eksternal

  15. Computer User's Bill of Rights • The user is always right • The user has the right to easily install and uninstall software and hardware systems without negative consequences • The user has the right to a system that performs exactly as promised • The user has the right to easy-to-use instructions for understanding and utilizing a system to achieve desired goals and recover efficiently and gracefully from problem situations • The user has the right to be in control of the system and to be able to get the system to respond to a request for attention • The user has the right to a system that provides clear, understandable, and accurate information regarding the task it is performing and the progress toward completion • The user has the right to be clearly informed about all system requirements for successfully using software or hardware • The user has the right to know the limits of the system's capabilities • The user has the right to communicate with the technology provider and receive a thoughtful and helpful response when raising concerns • The user should be the master of software and hardware technology, not vice versa. Products should be natural and intuitive to use.

More Related