SWRT.pdf

Software Testing Foundation Software Requirement for Tester 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 1 Lesson Objectives  Be introduced Requirement Concepts  Know how to study and clarify functional requirements  User Interface  Functi...

Software Testing Foundation Software Requirement for Tester 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 1 Lesson Objectives  Be introduced Requirement Concepts  Know how to study and clarify functional requirements  User Interface  Function 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 2 AGENDA Requirement Concepts Requirement Types Study & Clarify Requirement 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 3 Section 1 REQUIREMENT CONCEPTS 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 4 Requirement Definition A statement of a service the system must do OR A statement of a constraint the system must satisfy 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 5 Requirement Definition o Let us dissect this definition in order to better understand it: A requirement is a statement…: this means that each requirement is a relatively short and concise piece of information, expressed as a fact. It can be written as a sentence or can be expressed using some kind of diagram. We will call a collection of requirements a requirements document. “As a [personal/actor], I [want to], [so that].” E.g. As a manager, I want to be able to understand my colleagues progress, so I can better report our success and failures. 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 6 Requirement Definition o …an service of what the proposed system must do…: most requirements say something about the tasks the system is supposed to accomplish. They do not describe the domain. E.g. UC1: Log in - This function allows user to login to system o …a constraint on the system’s development…: requirements often specify the quality levels required. They may also specify details such as the programming language to be used if this is truly important to the customer. They should, however, avoid discussing incidental aspects of the design. E.g. The system will be initially operating on a Microsoft Windows 2000 server platform with latest service pack (SP2 and above) 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 7 Why do we need requirements? 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 8 Requirement Classification 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 9 Requirement Document Classification During attend to software project, you can see some kinds of requirement document below:  High Level Requirement (HLR) Document / User Requirement Definition (URD)  Use Case Document  Software Requirement Specification Document  Note: these documents are in many templates 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 10 Section 2 REQUIREMENT TYPES 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 11 Requirement Types  Requirements can be divided into two major types:  Functional Requirements  Non-functional Requirements 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 12 Functional Requirement  Discuss the functionality required by the users from the system  Things that a system has to do related to business flow  Example:  Do a calculation: add, new, edit, delete functions  Make a report  Security: access right 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 13 Non-functional Requirement  Is a statement of how a system must behave;  Is a constraint upon system’s behaviour  Non-functional requirements can be categorized as  Quality constraint  Performance constraint  Design constraint  Environmental / platform constraint  Process constraint 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 14 Quality Constraints Quality constraints reflects the quality attributes. These quality requirements constrain the design to meet specified levels of quality.  Maintainability and Enhancement: in order to ensure that the system can be adapted in the future, you should describe changes that are anticipated for subsequent releases. This constrains design and improves quality without adding explicit new functional requirements.  Reusability: is the likelihood a segment of source code that can be used again to add new functionalities with slight or no modification. Reusability reduces implementation time as reusable model is already tested.  Reliability: is specified by using mean time to failure. It is the ability of a system to perform its functions under stated conditions for a specified period of time. E.g. System should not down for more than 5 minutes. / less than 1hr downtime. 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 15 Performance Constraints  Response time: is time system take to compute the result. Low response time is desirable.  Throughput: is number of computation or transactions per unit time. Some systems take long time for processing or Some systems are continually responding to client , it is necessary to consider throughput. E.g. System must handle 1,000 transactions/sec  Utilization: is resources consumed by the system. Utilization of resources such as memory or network bandwidth are specified. E.g. system should not use more than 20MBPS of bandwidth. 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 16 Design Constraints  Availability: measures the amount of time that a server is running and available to respond to users. E.g. The system is operational during standard working hours (9am to 5pm). However, there should be the flexibility to operate the system 24 hours a day 7 days a week  Recovery from failure: If the hardware or software crashes, or the power fails, then the system will be able to recover within a certain amount of time, and with a certain minimal loss of data. 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 17 Environmental/Platform Constraints  Platform: Platform specifies the hardware and operating system used for developing system. E.g. Linux operating system with 2GB RAM.  Technology to be used: It signifies the programming language (framework) used to develop a system. Sometimes client places constraint on programming language to be used for developing system. E.g. System should be developed by using java language. 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 18 Process Constraints  Development process to be used: In order to ensure quality, some requirements documents specify that certain processes be followed; E.g. Microsoft SQLServer 2000 will be used for LMS  Cost and delivery date. 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 19 Assignment 1 - Identify Functional, Non- Functional Requirements  Objectives: Học viên xác định được rõ đâu là yêu cầu kiểm thử chức năng, đâu là yêu cầu kiểm thử phi chức năng và yêu cầu kiểm thử phi chức năng đó thuộc nhóm ràng buộc – Constraint nào  Technical Requirements:  Chia học viên thành các nhóm (~5 hv), tối đa 4 nhóm / lớp  2 nhóm sẽ làm 1 SRS (1 nhóm làm về Functional requirement, 1 nhóm làm về Non-Functional requirement)  Các bạn trong nhóm sẽ đọc, trao đổi và thống nhất và điền kết quả bài làm vào 2 biểu mẫu:  Danh sách các functional requirement hoặc non-functional requirement mà nhóm phải làm và đã xác định  Danh sách các câu hỏi mà nhóm cần hỏi  Thời gian làm bài tập nhóm: 30 phút  Mỗi nhóm lên trình bày trước lớp về kết quả bài làm của nhóm mình: tối đa 30 phút / nhóm 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 20 Section 3 STUDY & CLARIFY REQUIREMENT 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 21 Study & Clarify, Validate Requirement Collect requirements/BA present the SRS to members in the team Self study related materials: Top-Down approach Clarify requirements Validate requirements 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 22 Top-Down Approach  High level requirement:  Use Case Diagram: a diagram that depicts the interactions between the system and external systems and users.  Workflow: sequence of connected steps to run end-to- end a system  Functional Requirements: use case/function details  Non-functional Requirements: ex. Performance requirement 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 23 Use Case Diagram Depicts system functions that are performed for actors 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 24 Workflow 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 25 Study Functional Requirement  User Interface  Function, Business 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 26 User Interface Requirement Study  User Interface is the space where interaction between humans and machines occurs (wiki)  User Interface is key to application usability  User Interface is also called as the front-end of the system.  User interfaces exist for various systems, and provide a means of:  Input, allowing the users to manipulate a system  Output, allowing the system to indicate the effects of the users' manipulation  Bad UI design make not-good first impression about the system. 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 27 User Interface Requirement Study  Mock-up screen/prototype  Screen description: describe detail objects in screen  Field name  Control type  Data type  Default value  Mandatory  Editable  Max length  Value  Description  Validation  UI Style 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 28  Mock-up Screen Client Creation 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 29 Screen Description 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 30 Graphic User Interface Style 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 31 Use Case/Function Study  Purpose: Brief overview of the use case, describing the main idea  Actor: Someone that interacts with the use case  Pre-condition: State(s) the system can be in before the use case starts  Trigger: Event that causes the use case to be initiated  Basic Flow: what happens and in what order when all is well  Alternative Flow: what happens and in what order when something goes wrong  Post-condition: State(s) the system can be in after the use case finishes  Business Rule: defines or constrains some aspect of business 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 32 Use Case/Function Study – Example Client Creation  Purpose: Add a new client to system  Actor: Practice Business User ( Manager, Administrative or Sales user )  Pre-condition:  User login to system as Practice Business User before running the Use Case  User has [Full control - Client Management] permission including Client Creation function permission  Trigger: User select Client Creation sub menu from Menu bar or user selects Create Client button on Client Search screen 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 33 Use Case/Function Study – Example Client Creation  Basic Flow: 1. Access to Create Client Details screen 2. Input Client Information 3. Click Save 4. System validate inputted data successfully 5. System update data 6. System write Audit trail 7. Display Client Detail screen & Client details are successfully added into database  Alternative Flow:  User select Cancel -> navigation use case  Data (Date of Birth, Telephone number, postcode...) is invalid -> display error message  System failed to update -> write Audit trail then backs to main flow -> display error message 5/9/2023 09e-BM/DT/FSOFT - ©FPT SOFTWARE – Fresher Academy - Internal Use 34 Use Case/Function Study – Example  Post-condition: System  Display Client Detail screen  Audit trail of changes made, when changed and by whom.  Client is created successfully.  Client details are successfully added into database  Business Rule: Mandatory field, max length, email format validation refer to Common Validation – Overarching SRS IF format of Date of Birth is wrong THEN system displays error message IF Date of Birth is a date in the future THEN system displays error message IF Telephone Number Home, or Telephone Number Work is invalid format THEN system displays the error message