K2-Understand
Distinguish between the root cause of a defect and its effects(K2)
A human being can make an error (mistake), which produces a defect (fault, bug) in the program code, or in a document. If a defect in code is executed, the system may fail to do what it should do (or do something it shouldn't), causing a failure. All defects do not cause failure.
Explain and compare the terms error, defect, fault, failure, and the corresponding terms mistake and bug, using examples (K2)
A human being can make an error (mistake), which prod ces a defect (fault, bug) in the program code, or in a document. If a defect in code is executed, the system may fail to do what it should do (or do something it shouldn't), causing a failure.
Describe the role of regression testing and impact analysis in maintenance (K2)
maintenance testing includes regression testing to parts of the system that have not been changed. The impact analysis may be used to determine the regression test suite.
Compare the terms test condition, test case and test procedure (K2)
A test condition is defined as an item or event that could be verified by one or more test cases (e.g., a function, transaction, quality characteristic or structural element). A test case consists of a set of input values, execution preconditions, expected results and execution post-conditions, defined to cover a certain test objective(s) or test condition(s).
Explain the main purpose of each of the four testing techniques, what level and type of testing could use the technique, and how coverage may be measured (K2)
Black-box techniques: Equivalence partitioning-inputs to the software or system are divided into groups that are expected to exhibit similar behavior, Boundary Value analysis-. The maximum and minimum values of a partition are its boundary values. Decision table-logical conditions, (Boolean) State transition-system may exhibit different response depending (its state).A state table shows the relationship between the states and inputs, and can highlight possible transitions that are invalid. Use case testing-Tests can be derived from use cases.
Explain the difference between static and dynamic techniques, considering objectives, types of defects to be identified, and the role of these techniques within the software lifecycle (K2)
Compared to dynamic testing, static techniques find causes of failures (defects) rather than the failures themselves. Typical defects that are easier to find in reviews than in dynamic testing include: deviations from standards, requirement defects, design defects, insufficient maintainability and incorrect interface specifications
Describe the purpose of confirmation testing and regression testing (K2)
Confirmation testing is retesting after a fix to confirm that the original defect has been successfully removed. Regression testing is the repeated testing of an already tested program, after modification, to discover any defects introduced as result of the changes
Differentiate testing from debugging (K2)
Debugging and testing are different. Testing can show failures that are caused by defects. Debugging is the development activity that finds, analyzes and removes the cause of the failure.
Compare experience-based techniques with specification based testing techniques (K2)
Experience-based testing is where tests are derived from the tester‟ skill and intuition and their experience with similar applications and technologies. Specification is a more formal test technique.
Compare four software test types (functional, non-functional, structural and change- related) by example (K2)
Functional testing is what" the system does. Non-functional testing looks into "how" the system works. change-related testing occurs after a fix or when the software or environment is changed.
Explain the differences between different types of reviews: informal review, technical review, walkthrough and inspection (K2)
Informal-Inexpensive, No formal review, may be documented. Walkthrough-Led by author, main purpose is to gain understanding, learning, find defects Technical -documented, led by trained moderator(not author), main purpose to discuss, find alternatives, makes decisions,. Inspection-formal process, led by trained moderator, documented
Identify and describe non-functional test types based on non-functional requirements (K2)
Non-functional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and portability testing.
Explain the seven principles in testing (K2)
Principle 1 - Testing shows presence of defects Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness. Principle 2 - Exhaustive testing is impossible Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts. Principle 3 - Early testing To find defects early, testing activities shall be started as early as possible in the software or system development life cycle, and shall be focused on defined objectives. Principle 4 - Defect clustering Testing effort shall be focused proportionally to the expected and later observed defect density of modules. A small number of modules usually contains most of the defects discovered during pre- release testing, or is responsible for most of the operational failures. Principle 5 - Pesticide paradox If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this "pesticide paradox", test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to find potentially more defects. Principle 6 - Testing is context dependent Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site. Principle 7 - Absence-of-errors fallacy Finding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations.
Describe, with examples, the way in which a defect in software can cause harm too a person, to the environment or to a company (K2)
Software that does not work correctly can lead to many problems, including loss of money, time or business reputation, and could even cause injury or death. Defective software in a hospital can cause harm to a person. The hole in the ozone layer over Antarctica remained undetected for a long period of time because the data analysis software used by NASA was defective.
Explain the relationship between development, test activities and work products in the development life cycle, by giving examples using project and product types (K2)
Software work products (such as business scenarios or use cases, requirements specifications, design documents and code) produced during development are often the basis of testing in one or more test levels.
Explain the concepts of statement and decision coverage, and give reasons why these concepts can also be used at test levels other than component testing (e.g., on business procedures at system level) (K2)
Statement coverage is determined by the number of executable statements covered by (designed or executed) test cases divided by the number of all executable statements in the code under test. Decision coverage, related to branch testing, is the assessment of the percentage of decision outcomes that have been exercised by a test case suite.
Component testing
Test basis: Component requirements, Detailed design, Code Typical test objects: Components, Programs, Data conversion / migration programs, Database modules
Integration testing
Test basis: Software and system design, Architecture, Workflows, Use cases Typical test objects: Sub-systems database implementation, Infrastructure, Interfaces, System configuration and configuration data
System Testing
Test basis: System and software requirement specification, Use cases, Functional specification, Risk analysis reports Typical test objects: System, user and operation manuals, System configuration and configuration data
Acceptance testing
Test basis: User requirements, System requirements, Use cases, Business processes, Risk analysis reports Typical test objects: Business processes on fully integrated system, Operational and maintenance processes, User procedures, Forms, Reports, Configuration data
Give reasons why testing is necessary by giving examples(K2)
Testing can help reduce the risk of problems occurring during operation and contribute to the quality of the software system. Software testing may be required to meet contractual or legal requirements, or industry-specific standards.
Provide examples for the objectives of testing in different phases of the software life cycle (K2)
Testing should occur in different phases of the software lifecycle bcause test activities exist before and after test execution. These activities include planning and control, choosing test conditions, designing and executing test cases, checking results, evaluating exit criteria, reporting on the testing process and system under test, and finalizing or completing closure activities after a test phase has been completed. Testing also includes reviewing documents (including source code) and conducting static analysis. The thought process and activities involved in designing tests early in the life cycle (verifying the test basis via test design) can help to prevent defects from being introduced into code. Reviews of documents (e.g., requirements) and the identification and resolution of issues also help to prevent defects appearing in the code.
Explain the concept of use case testing and its benefits (K2)
Tests can be derived from use cases. Use cases are very useful for designing acceptance tests with customer/user participation. They also help uncover integration defects caused by the interaction and interference of different components, which individual component testing would not see.
Explain the benefits and drawbacks of independent testing within an organization (K2)
The benefits of independence include: o Independent testers see other and different defects, and are unbiased o An independent tester can verify assumptions people made during specification and implementation of the system Drawbacks include: o Isolation from the development team (if treated as totally independent) o Developers may lose a sense of responsibility for quality o Independent testers may be seen as a bottleneck or blamed for delays in release
Contrast the mindset of a tester and of a developer (K2)
The mindset we want to use while testing and reviewing is different from the one we use while analyzing or developing. By this we mean that, if we are build-ing something we are working positively to solve problems in the design and to realize a product that meets some need. However, when we test or review a product, we are looking for defects in the product and thus are critical of it. .
Describe why testing is part of quality assurance and give examples of how testing contributes to higher quality (K2)
When testing does find defects, the quality of the software system increases when those defects are fixed.
Identify and describe test types based on the analysis of a software system's structure or architecture (K2)
White-box testing is structural/architectural testing.
Describe, using examples, the typical benefits of static analysis (K2)
benefits of static analysis include: Early detection of defects prior to test execution o Early warning about suspicious aspects of the code or design by the calculation of metrics, such as a high complexity measure o Identification of defects not easily found by dynamic testing o Detecting dependencies and inconsistencies in software models such as links o Improved maintainability of code and design o Prevention of defects, if lessons are learned in development
Explain the factors for successful performance of reviews (K2)
o Each review has clear predefined objectives o The right people for the review objectives are involved o Testers are valued reviewers who contribute to the review and also learn about the product which enables them to prepare tests earlier o Defects found are welcomed and expressed objectively o People issues and psychological aspects are dealt with (e.g.,making it a positive experience for the author) o The review is conducted in an atmosphere of trust; the outcome will not be used for the evaluation of the participants o Review techniques are applied that are suitable to achieve the objectives and to the type and level of software work products and reviewers o Checklists or roles are used if appropriate to increase effectiveness of defect identification o Training is given in review techniques, especially the more formal techniques such as inspection o Management supports a good review process (e.g., by incorporating adequate time for review activities in project schedules) o There is an emphasis on learning and process improvement
Explain the characteristics, commonalities, and differences between specification-based testing, structure-based testing and experience-based testing (K2)
specification-based techniques are a way to derive and select test conditions, test cases, or test data based on an analysis of the test basis documentation. Structural techniques are based on an analysis of the structure of the component or system. Experienced based testing leverages the experience of developers, testers and users to determine what should be tested.
Describe the importance and value of considering static techniques for the assessment of software work products (K2)
static testing benefits include early defect detection and correction, development productivity improvements, reduced development timescales, reduced testing cost and time, lifetime cost reductions, fewer defects and improved communication. Reviews can find omissions, for example, in requirements, which are unlikely to be found in dynamic testing.
Differentiate between a test design specification, test case specification and test procedure specification (K2)
test procedure specification-where test cases are defined, implemented, prioritized and organized
