12.1 Introduction Checklists are used as a technique to give status information in a formalized manner about all aspects of the test process. This chapter.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
Advertisements

System Integration Verification and Validation
ICT Class System Life Cycle.  Large systems development projects may involve dozens of people working over several months or even years, so they cannot.
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
What is Software Design?. Systems Development Life- Cycle Planning Analysis Design Implementation Design.
Software Engineering 1. Software development – the grand view 2. Requirements engineering.
Software Engineering Software quality. Software quality characteristics:  External: user is aware of. User cares about.  Internal: programmer is aware.
Introduction to Software Engineering Lecture 5 André van der Hoek.
8.
SE 555 Software Requirements & Specification Requirements Quality Attributes.
Evaluating Architectures Quality control: rarely fun, but always necessary
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
Software Process and Product Metrics
Software Engineering Tools and Methods Presented by: Mohammad Enamur Rashid( ) Mohammad Rashim Uddin( ) Masud Ur Rahman( )
Configuration Management
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Non-functional requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Design with Reuse l Building software from reusable components.
Chapter 7 Software Engineering Objectives Understand the software life cycle. Describe the development process models.. Understand the concept of modularity.
Managing Software Quality
 The software systems must do what they are supposed to do. “do the right things”  They must perform these specific tasks correctly or satisfactorily.
Chapter 2 The process Process, Methods, and Tools
Sept - Dec w1d11 Beyond Accuracy: What Data Quality Means to Data Consumers CMPT 455/826 - Week 1, Day 1 (based on R.Y. Wang & D.M. Strong)
Quality Models and Quality Attributes. Outline  Process and product quality Improving the quality of the process can improve the quality of the product.
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Some Sub-Activities within Requirements Engineering 1.Prototyping 2.Requirements Documentation 3.Requirements Validation 4.Requirements Measurements 5.Requirements.
Sommerville, Mejia-Alvarez, 2009Software Engineering, Slide 1 Software Design u Deriving a solution which satisfies software requirements.
Software Engineering Quality What is Quality? Quality software is software that satisfies a user’s requirements, whether that is explicit or implicit.
Question To know that quality has improved, it would be helpful to be able to measure quality. How can we measure quality?
Software Development Cycle What is Software? Instructions (computer programs) that when executed provide desired function and performance Data structures.
SE: CHAPTER 7 Writing The Program
Lecture 7: Requirements Engineering
Chapter 6 Architectural Design.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Chapter 19 Verification and Validation.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
Chapter 4 프로세스 모델 Process Models
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Prepared by: Hussein Alhashimi.  This course introduces fundamental concepts related to Quality Assurance and Measurements and Metrics in the software.
Chapter 13: Software Quality Project Management Afnan Albahli.
UKTMF 27 th January 2010 Non-Functional Testing1 Non-Functional Testing Non-Functional Testing Why is this so often done badly or not done at all? Can.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Evaluating Architectures. Quality Control Rarely fun, but always necessary 1.
CSE 303 – Software Design and Architecture
 System Requirement Specification and System Planning.
Chapter 2: The Process. What is Process? Software Engineering Process is the glue that holds the technology layers together and enables rational and timely.
Software Project Configuration Management
Software Quality Control and Quality Assurance: Introduction
Rekayasa Perangkat Lunak Part-10
Rekayasa Perangkat Lunak
Evaluation Forms for Blockchain- Based System ver. 1.0
Quality Management chapter 27.
Security SIG in MTS 05th November 2013 DEG/MTS RISK-BASED SECURITY TESTING Fraunhofer FOKUS.
SYSTEM ANALYSIS AND DESIGN
Software Processes (a)
Developing Information Systems
Software Quality Engineering
Software engineering.
Rekayasa Perangkat Lunak
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Charakteristiky kvality
Chapter 2 – Software Processes
ISO/IEC Systems and software Quality Requirements and Evaluation
Tomaž Špeh SURS TF SERV, Luxembourg,
Presentation transcript:

12.1 Introduction Checklists are used as a technique to give status information in a formalized manner about all aspects of the test process. This chapter contains the following categories of checklists: checklists for quality characteristics; general checklist for high-level testing; general checklist for low-level testing; test design techniques checklist; checklists concerning the test process.

12.2 Checklists for quality characteristics connectivity; reliability; flexibility; maintainability; portability; reusability; security; testability; usability.

Connectivity Connectivity is the capability of the system to establish connection with different systems, or within this (distributed) system. Reliability Reliability is the capability of the system to maintain a specified level of performance when used under specified conditions. The quality attribute “reliability” is divided into three subattributes – maturity, fault tolerance, and recoverability.

Flexibility Flexibility is the capability of the system to enable the user to introduce extensions or modifications without changing the system itself. Maintainability Maintainability is the capacity of the system to be modified. Modifications may include corrections, improvements, or adaptation of the system to changes in the environment, and also in requirements and functional requirements.

Portability Portability is the capability of the software to be transferred from one environment to another. Reusability Reusability is the capability of the software to enable the reuse of parts of the system or design for the development of different systems. Security Security is the capability of the system to ensure that only authorized users (or systems) have access to the functionality.

Testability Testability is the capability of the system to be validated. Usability Usability is the capability of the system to be attractive to the user under specified conditions, and to be understood, learned, and used.

Usability is a rather subjective quality characteristic – just what usability means depends on the individual taste of a user. However, it is usually possible to identify different groups of users with their own demands. Another factor often ignored is the culture that influences the acceptance of the user interface. The only way to get a clear picture of the usability of a system is to let a user implement use the system as if it were in daily use. If it is thought that culture could be an important factor, the forum used should have a diverse cultural background, or otherwise use more forums. To give a clear picture of the usability of a system, a questionnaire can be filled in by the members of the user forum. Possible items in the questionnaire include the following.

12.3 General checklist for high-level testing General Division into subsystems and interfaces Function structure User dialog Quality requirements

12.4 General checklist for low-level testing General System structure Program division Program description Performance requirements

12.5 Test design techniques checklist Control flow test The desired test basis is a flow chart, or a decision complemented by a description. Classification-tree method Elementary comparison test Statistical usage testing and rare event testing State-based testing technique Evolutionary algorithms Safety analysis

12.6 Checklists concerning the test process The checklists in this section provide guidelines for a diversity of activities concerning the test process. They are not exhaustive but can serve as a basis for constructing organization-dependent and project- dependent checklists. The following checklists are included.

Test project evaluation. This checklist contains attributes for intermediate and final evaluations of a project. Global investigation of the system. This checklist can be used to support the global review and study activity from the planning and control phase. Preconditions and assumptions. This checklist contains examples of preconditions and assumptions to include in a test plan. Test project risks. The risks regarding the test project must be made explicit. This checklist contains a number of potential risks.

Structuring the test process. This checklist is used to assess the current situation of testing. Test facilities. This checklist is useful for organizing and establishing the test infrastructure, the test organization, and test control during the planning and control phase. Production release. This is a checklist for the determination of completeness of the product, test activities, production parameters, and production operations. Coding rules. This checklist applies to the low-level testing activities concerning analysis of the code.

Test project risks The project risks are identified and described in the test plan. For each risk, the consequence and the solution, and/or measures to minimize the risk or consequences, are mentioned.