1. How can software quality be determined?
2. Levels of ST
2.1. L10 - White-box Testing Techniques
2.1.1. Introduction
2.1.1.1. When is it applied?
2.1.1.2. What is white-box testing?
2.1.1.3. Who would be the best to do white-box testing?
2.1.1.3.1. What is the goal of applying white-box testing techniques to design test cases?
2.1.2. ECP/BVA
2.1.3. White-box Testing Techniques
2.1.3.1. What are advantages and disadvantages of white-box testing?
2.1.3.1.1. What does basic path testing mean?
2.1.3.2. Basic Path Testing
2.1.3.2.1. How can we design test cases by applying basic path testing technique?
2.1.3.3. Control-flow / Coverage Testing
2.1.3.3.1. Which strategies can we apply for coverage testing?
2.1.3.3.2. What is difference between method coverage and statement coverage?
2.1.3.3.3. What is difference between branch coverage and compound condition coverage (predicate coverage)?
2.1.3.3.4. How can we design test cases to test source code loops?
2.1.4. Important Tips
2.2. L11 - Unit Testing
2.2.1. Introduction
2.2.1.1. What is unit testing?
2.2.1.2. How do most developers test their code?
2.2.1.3. What is a good unit test?
2.2.2. Test-Driven Development (TDD)
2.2.2.1. What does test-driven development (TDD) mean?
2.2.2.2. What is difference between traditional and test-driven development approach for writing a unit test?
2.2.2.3. What are benefits of TDD approach?
2.2.2.4. Who would be the best to do unit testing?
2.2.3. Frameworks for Unit Tests
2.2.3.1. What do unit test frameworks offer?
2.2.3.2. What do xUnit frameworks mean?
2.2.3.3. Which basic rules for placing and naming unit tests?
2.2.4. Unit Test Report
2.2.4.1. What is the purpose of a unit test report?
2.2.4.2. Which main items should be included in a unit test report?
2.3. L12 - Integration Testing
2.3.1. Introduction
2.3.1.1. What is integration testing?
2.3.1.2. When is integration testing applied?
2.3.1.3. What are goals of integration testing?
2.3.1.4. What do driver and stub mean?
2.3.2. Integration Testing Procedures
2.3.2.1. Which activities should be conducted for integration testing?
2.3.2.2. What are entry/exit criteria for integration testing?
2.3.2.3. Which information should be included in an integration test plan?
2.3.3. Strategies for Integration Testing
2.3.3.1. Big bang approach
2.3.3.1.1. What does it mean?
2.3.3.1.2. What are advantages and disadvantages of this approach?
2.3.3.2. Top-down approach
2.3.3.2.1. What does it mean?
2.3.3.2.2. How does it performed?
2.3.3.2.3. What are advantages and disadvantages of this approach?
2.3.3.3. Bottom-up approach
2.3.3.3.1. What does it mean?
2.3.3.3.2. How does it performed?
2.3.3.3.3. What are advantages and disadvantages of this approach?
2.3.3.4. Sandwich approach
2.3.3.4.1. What does it mean?
2.3.3.4.2. What are advantages and disadvantages of this approach?
2.3.4. Best Practices
2.4. L13 - System Testing
2.4.1. Introduction
2.4.1.1. What is system testing?
2.4.1.2. When is system testing applied?
2.4.1.3. What should we verify in system testing?
2.4.2. Types of system testing
2.4.2.1. How many types of system testing?
2.4.2.2. What should testers depend on to select the suitable types of system testing for their project?
2.4.3. Activities of system testing
2.4.3.1. Which activities should be conducted for system testing?
2.5. L14 - User Acceptance Testing
2.5.1. Introduction
2.5.1.1. What is user acceptance testing (UAT)?
2.5.1.2. When is UAT applied?
2.5.1.3. Who should be involved in performing UAT?
2.5.1.4. Why should we perform UAT?
2.5.2. User Acceptance Testing Process
2.5.2.1. How should we perform UAT?
2.5.2.2. What are qualities of UAT testers?
3. Test Mgmt.
3.1. L15 - Test Management
3.1.1. Introduction
3.1.1.1. What is test management?
3.1.1.2. What is the role of software testing in software development life cycle?
3.1.1.3. What is the role and responsibility of test manager?
3.1.1.4. What are the challenges in test management?
3.1.2. Test Management Phases
3.1.2.1. Planning
3.1.2.1.1. 1. Risk Analysis & Solution
3.1.2.1.2. 2. Test Estimation
3.1.2.1.3. 3. Test Strategy & Planning
3.1.2.1.4. Test Organization
3.1.2.2. Execution
3.1.2.2.1. Test Monitoring and Control
3.1.2.2.2. Issue Management
3.1.2.2.3. Defect Management
3.1.2.2.4. Test Report and Evaluation
3.1.3. Test Process Improvement
3.1.3.1. What is the test process improvement?
3.1.3.2. Why do we need improve process?
3.1.3.3. How can we implement the test process improvement?
4. Types of ST
4.1. L03 - Static Testing
4.1.1. Definition, goal, importance, and the objects of static testing
4.1.1.1. What is Static Testing?
4.1.1.2. What is the goal of static testing?
4.1.1.3. What is it important?
4.1.1.4. What can be tested by static testing?
4.1.2. Types of review
4.1.2.1. Managerial reviews
4.1.2.2. Formal reviews
4.1.2.2.1. Software Inspections
4.1.2.2.2. Summary Report
4.1.2.2.3. Software Walkthroughs
4.1.3. Review Guidelines
4.2. L04 - Common Testing Types
4.2.1. Regression Testing
4.2.1.1. What is regression testing?
4.2.1.2. When is it performed?
4.2.1.3. Why do we need to perform regression testing?
4.2.1.4. What are regression testing techniques?
4.2.1.5. What are differences between regression testing and re-testing?
4.2.2. Smoke Testing
4.2.2.1. What is smoke testing?
4.2.2.2. When is smoke testing performed?
4.2.2.3. Why do we need to perform smoke testing?
4.2.2.4. What is the strategy for smoke testing?
4.2.3. Sanity Testing
4.2.3.1. What is sanity testing?
4.2.3.2. When is sanity testing performed?
4.2.3.3. Why do we need to perform sanity testing?
4.3. L05 - Usability Testing
4.3.1. Introduction
4.3.1.1. What are differences between smoke testing and sanity testing?
4.3.1.2. Usability Testing: goal, benefits, and major considerations
4.3.1.2.1. What is the goal of usability testing?
4.3.1.2.2. When is usability testing performed?
4.3.1.2.3. What are benefits of usability testing?
4.3.1.3. Usability and Factors of Usability
4.3.1.3.1. What is usability?
4.3.1.3.2. What are the factors of usability?
4.3.1.3.3. What is usability testing?
4.3.2. Rubin's Approach to Usability Testing
4.3.2.1. Basic elements of usability testing and the role of participants : Sự phát triển của một mục tiêu kiểm tra do designer và tester Sử dụng một mẫu đại diện của người dùng cuối do tester Một môi trường để kiểm tra đại diện cho môi trường làm việc thực tế do designer và tester Quan sát của người dùng xem xét hoặc sử dụng một đại diện của sản phẩm (sau này có thể là một nguyên mẫu) do developer và tester Việc thu thập, phân tích và tóm tắt các dữ liệu đo lường chất lượng và định lượng và dữ liệu đo lường ưu tiên do designer tester và developer Đề xuất cải tiến sản phẩm phần mềm do designer và developer
4.3.2.2. Types of usability testing
4.3.2.2.1. 1. Exploratory Usability Testing
4.3.2.2.2. 2. Assessment Usability Testing
4.3.2.2.3. 3. Validation Usability Testing
4.3.2.2.4. 4. Comparison Test
4.3.2.3. Resource requirements for usability testing: Mục đích là để lập tài liệu những gì bạn sẽ làm, cách bạn sẽ tiến hành kiểm tra, thước đo những gì bạn sẽ giành được, số người tham dự bạn sẽ kiểm tra và kịch bản những gì bạn sẽ sử dụng.
4.3.2.4. Data-Gathering Methods for Usability Testing
4.3.2.4.1. Videotaping a user test and using think-aloud protocol
4.3.2.4.2. Remote user testing
4.3.2.4.3. Eye tracking
4.3.2.4.4. Usability Questionnaire
4.4. L06 - Black-box Testing Techniques
4.4.1. Introduction
4.4.1.1. What is black-box testing? When is it applied?
4.4.1.1.1. test chức năng, ktra đầu vào và đầu ra, mà ko quan tâm bên trong nó có gì.
4.4.1.1.2. When?
4.4.1.2. What is the goal of applying black-box testing techniques to design test cases?
4.4.1.2.1. đạt được các trường hợp test hợp lí
4.4.1.2.2. cho biết có lỗi hay ko có lỗi
4.4.2. Black-box Testing techniques
4.4.2.1. How can we design test cases by applying ECP technique?
4.4.2.1.1. Who would be the best to do black-box testing?
4.4.2.2. Equivalence Class Partitioning (ECP)
4.4.2.2.1. What does equivalence class partitioning (ECP) mean?
4.4.2.2.2. What are the applicability and advantages of ECP technique?
4.4.2.3. What is the applicability of BVA technique?
4.4.2.4. Boundary Value Analysis
4.4.2.4.1. What does boundary value analysis (BVA) mean?
4.4.2.4.2. How can we design test cases by applying BVA technique?
4.4.2.4.3. What is difference between ECP and BVA?
4.4.2.5. Decision Table-Based
4.4.2.5.1. What does decision table-based testing mean?
4.4.2.5.2. How can we design test cases by applying decision table-based testing technique?
4.4.2.5.3. What is difference between ECP/BVA and Decision Table-based Testing technique?
4.4.3. Test Design Guidelines
4.5. L07 - Functional Testing
4.5.1. Definition and objectives of functional testing
4.5.1.1. What is functional testing?
4.5.1.2. What can you base on to develop test cases for functional testing?
4.5.1.3. What is the objective of functional testing?
4.5.2. Developing functional test cases from use cases
4.5.2.1. How can we develop test cases to test a function of software application?
4.5.2.1.1. A Four-Steps Process
4.5.2.2. We need to weight the test cases, based on:
4.5.2.2.1. the criticality of the condition being tested
4.5.2.2.2. the likely frequency of use of the path or condition
4.5.2.2.3. prior defect patterns
4.5.2.2.4. and the complexity of the path through use case
4.5.2.3. Why do we need prioritize test cases? How can we do that?
4.6. L09 - Performance Testing
4.7. L08 - Testing Internet Applications
4.7.1. What are differences between mainframe systems and desktop PC systems? (components, characteristics, operation)
4.7.1.1. Components
4.7.1.2. Characteristics
4.7.1.3. Operation
4.7.2. Typical Application Model
4.7.2.1. How is a typical application model operated?
4.7.2.1.1. User transfer data input(Data entries, Data requests, Data rules)
4.7.2.1.2. Manipulate data
4.7.2.1.3. System Read/Write/Store data
4.7.2.1.4. System Feedback Requested data
4.7.2.2. Cấu trúc vật lý : Yếu tố cơ bản trong mô hình khách chủ là trong hệ thống phải có các máy tính kết nối chung với nhau sử dụng một giao thức bất kỳ nhằm mục đích sử dụng các tài nguyên, dữ liệu của nhau.
4.7.2.3. What are components of traditional client-server systems? How are they operated?
4.7.2.3.1. Máy trạm (Client) : Các máy trạm truy xuất các tài nguyên đã được chia sẻ trên mạng như các dữ liệu dùng chung trên máy chủ và in ấn các tài liệu trên máy in dùng chung.
4.7.2.3.2. Máy chủ (Server) : Cùng một lúc sẽ có nhiều người truy xuất về máy chủ thong qua máy trạm do đó máy chủ phải có bộ vi xử lý tốc độ cao (CPU), tài nguyên lớn (RAM, Hardisk) để hoạt động tốt. Trong hệ thống mạng có thể có nhiều máy chủ có chức năng độc lập nhau.
4.7.2.3.3. Dây cáp mạng (Cable) : Hệ thống dây kim loại hoặc quang học nối kết vậy lý các máy tính, máy in lại với nhau
4.7.2.3.4. Dữ liệu chung (Shared data) : Các tập tin, thư mục mà người sử dụng có thể truy xuất trên máy chủ thông qua các máy trạm và dây cáp mạng.
4.7.2.4. Giao diện người dùng (User interface): Giao diện người dùng là không gian tương tác giữa người dùng và máy móc
4.7.2.5. What are components of web-based systems? How are they operated?
4.7.2.5.1. Client
4.7.2.5.2. Server
4.7.3. Web Application Architectures
4.7.3.1. What are differences between web application architectures of web 1.0, web 2.0, and web 3.0?
4.7.3.1.1. What are advantages and disadvantages of web applications compared with standalone applications?
4.7.3.1.2. Web 2.0 facilitates interaction between web users and sites, so it allows users to interact more freely with each other. Web 2.0 encourages participation, collaboration, and information sharing
4.7.3.1.3. Web 3.0 is a semantic web which refers to the future. In Web 3.0, computers can interpret information like humans and intelligently generate and distribute useful content tailored to the needs of users.
4.7.3.2. Web 1.0 is only limited interaction between sites and web users. Web 1.0 is simply an information portal where users passively receive information without being given the opportunity to post reviews, comments, and feedback.
4.7.3.3. What is a design pattern? Which design patterns can be applied to web-based systems?
4.7.3.3.1. Design pattern is a general repeatable solution to a commonly occurring problem in software design
4.7.4. Web testing challenges
4.7.4.1. Which challenges should we concern when testing web applications
4.7.4.1.1. Large and varied user base
4.7.4.1.2. Locales
4.7.4.1.3. Business environment
4.7.4.1.4. Security
4.7.4.1.5. Testing environment
4.7.5. Testing strategies for web applications
4.7.5.1. What is an overall testing strategy for web applications?
4.7.5.1.1. Developing a testing strategy for Internet-based applications requires a solid understanding of the hardware and software components that make up the application.
4.7.5.2. How should we do to overcome these challenges?
4.7.5.3. Presentation layer testing: What is the testing objective of this layer? What testing strategies for this layer?
4.7.5.3.1. Objective: Find defects in the GUI or front end of your application
4.7.5.3.2. Three major areas: - Content Testing - Website Architecture - User Environment
4.7.5.4. Business layer testing: What is the testing objective of this layer? What testing strategies for this layer?
4.7.5.4.1. Objective: Focus on finding errors in the business logic of your Web application.
4.7.5.4.2. Strategies: - Internal and external components Testing - Performance Testing - Data Validation - Transactional Testing
4.7.5.5. Data layer testing: What is the testing objective of this layer? What testing strategies for this layer?
4.7.5.5.1. Objective: Focus primarily on testing the DBMS that your app. uses to store and retrieve info.
4.7.5.5.2. Three major areas: - Response Time Testing - Data Integrity Testing - Fault Tolerance and Recoverability Testing
5. Fundamentals of ST
5.1. L01 - Testing Fundamentals
5.1.1. Definition of Some Basic Terms
5.1.1.1. What is the difference between
5.1.1.1.1. errors, faults (defects) and failures?
5.1.1.1.2. testing and debugging?
5.1.1.1.3. test suite, test oracle, and test bed?
5.1.1.2. verification and validation?
5.1.2. Definition, Primary Objectives, and Importance of Software Testing
5.1.2.1. What is software testing?
5.1.2.2. Why is it impossible to test everything?
5.1.2.2.1. Why should software testers have programming skill?
5.1.2.3. Why is software testing important?
5.1.2.4. What are primary objectives of software testing?
5.1.3. Software Testers vs. Software Developers
5.1.3.1. Which skills should a software testing professional have?
5.1.4. Who should be on the test team?
5.1.4.1. What are the works that a software tester do?
5.1.5. Vital Program Testing Guidelines
5.1.5.1. Principle 1. Static and execution testing contribute to risk reduction.
5.1.5.1.1. There are a large number of documents produced during software development that, if reviewed for defects (static testing), could significantly reduce the number of execution defects before the code is written.
5.1.5.2. Principle 2. Make the highest risks the first testing priority.
5.1.5.2.1. When faced with limited testing staff, limited testing tools, and limited time to complete the testing (as most testing projects are), it is important to ensure that there are sufficient testing resources to address at least the top business risks.
5.1.5.3. Principle 3. Make the most frequent business activities (the 80/20 rule) the second testing priority.
5.1.5.3.1. It is common industry knowledge that 80% of any daily business activity is provided by 20% of the business system functions, transactions, or workflow. This is known as the 80/20 rule.
5.1.5.4. Principle 4. A necessary part of a test case is a definition of the expected output or result.
5.1.5.4.1. If the expected result of a test case has not been predefined, chances are that a plausible, but erroneous, result will be interpreted as a correct result because of the phenomenon of ‘‘the eye seeing what it wants to see.’’
5.1.5.4.2. A test case must consist of two components:
5.1.5.5. Principle 5. Test cases must be written for input conditions that are invalid and unexpected, as well as for those that are valid and expected.
5.1.5.6. Principle 6. Examining a program to see if it does not do what it is supposed to do is only half the battle; the other half is seeing whether the program does what it is not supposed to do.
5.1.5.6.1. Programs must be examined for unwanted side effects.
5.1.5.6.2. For instance, a payroll program that produces the correct paychecks is still an erroneous program if it also produces extra checks for nonexistent employees, or if it overwrites the first record of the personnel file.
5.1.5.7. Principle 7. A programmer should avoid attempting to test his or her own program.
5.1.5.7.1. Firstly, it relates to psychological issues
5.1.5.7.2. The second significant problem
5.1.5.8. Principle 8. Avoid throwaway test cases unless the program is truly a throwaway program.
5.1.5.9. Principle 9. Do not plan a testing effort under the tacit assumption that no errors will be found.
5.1.5.9.1. This is a mistake project managers often make and is a sign of the use of the incorrect definition of testing—that is, the assumption that testing is the process of showing that the program functions correctly.
5.1.5.9.2. It should be obvious that it is impossible to develop a program that is completely error free. Even after extensive testing and error correction, it is safe to assume that errors still exist; they simply have not yet been found.
5.1.5.10. Principle 10. The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section.
5.1.5.10.1. Untitled
5.1.5.10.2. At first glance this concept may seem nonsensical, but it is a phenomenon present in many programs. Another way of stating this principle is to say that errors tend to come in clusters and that, in the typical program, some sections seem to be much more prone to errors than other sections, although nobody has supplied a good explanation of why this occurs.
5.1.5.10.3. If a particular section of a program seems to be much more prone to errors than other sections, then this phenomenon tells us that, in terms of yield on our testing investment, additional testing efforts are best focused against this error-prone section.
5.2. L02 - Testing & SDLC
5.2.1. What are the generic framework activities that are presented in every software process?
5.2.2. Overview of SDLC
5.2.2.1. What is Software Development Lifecycle?
5.2.2.2. What are the main elements of a software process?
5.2.2.2.1. What is the difference between SDLC and STLC?
5.2.3. Evolution of SDLC and the involvement of testing in prescriptive and agility development
5.2.3.1. What is the original goal of prescriptive (“traditional”) process models?
5.2.3.1.1. Prescriptive process models were originally proposed to bring order to the chaos of software development.
5.2.3.1.2. History has indicated that
5.2.3.1.3. Their intent is to
5.2.3.1.4. make projects more manageable
5.2.3.1.5. It emphasizes
5.2.3.2. improve system quality
5.2.3.3. What is the most compelling characteristic of the agile approach?
5.2.3.3.1. These process models emphasize maneuverability and adaptability.
5.2.3.3.2. Agile process models emphasize project “agility” and follow a set of principles that lead to a more informal (but, proponents argue, no less effective) approach to software process.
5.2.3.3.3. They are appropriate for many types of projects and are particularly useful when web applications are engineered.
5.2.3.4. What is the key difference of software testing involvement in traditional process models and agile process models?
5.2.4. Some commonly process models
5.2.4.1. Traditional Process Models
5.2.4.1.1. Waterfall
5.2.4.1.2. V-model
5.2.4.1.3. Incremental
5.2.4.2. Agile Process Models
5.2.4.2.1. Pros & Cons of Agile Methodologies
5.2.4.2.2. XP
5.2.4.2.3. SCRUM
5.2.4.3. Lean Process Models
5.2.4.3.1. Pros & Cons of Lean Methodologies
5.2.4.3.2. Kanban
5.2.4.3.3. Scrumban
5.2.5. The way testing is applied
5.2.6. Application Lifecycle Management (ALM) and DevOps
5.2.6.1. What does ALM stand for?
5.2.6.2. Which common features do ALM software suits support?
5.2.6.3. What does DevOps mean?
5.2.6.4. What are principles and benefits of continuous delivery?