Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
24 Cards in this Set
- Front
- Back
|
Causes of software defects |
Errors, mistakes, defects, faults, bugs, failure |
|
|
Error or Mistake: |
a human action that produces an incorrect result. |
|
|
Defect, Fault or Bug: |
a flaw in code, software, system or document that can cause it to fail to perform its required function |
|
|
Failure |
actual deviation of the component or system from its expected delivery, service or result. |
|
|
Objectives of Testing |
-Find defects -Gain confidence about the level of quality of a system -Providing information for decision-making P-reventing future defects |
|
|
Debugging vs.Testing |
-Testing can find defects or can generatefailures -Debugging is the process of fixing the defectthat was found or that caused the failure |
|
|
Seven TestingPrinciples |
Principle1 – Testing shows presence of defects Principle2 – Exhaustive testing is impossible Principle3 – Early testingo "Testingactivities shall be started as early as possible"· Principle4 – Defect clusteringo "Testingeffort shall be focused proportionally"o “Bugsare social creatures – they hang around together”· Principle5 – Pesticide paradoxo Softwarebecomes “immune” to the same tests· Principle6 – Testing is context dependent Principle7 – Absence-of-errors fallacy |
|
|
Preventative Test Planning and Control |
to start activities as soon as possible to prevent problems arising |
|
|
Reactive Testing |
Respondig to the situation once the software is delivered |
|
|
Test control has the following major tasks: |
-Measuring and analyzing results -Monitoring and documenting progress, test coverage and exit criteria -Making decisions and initiating corrective actions |
|
|
Test Analysis and Design |
-Review the documents that describe what the system should do -Review the software integrity level and risk analysis reportsIdentify test conditions -Design test cases -Traceability between test conditions and test cases should bemaintained -Test environment is designed |
|
|
Test Implementation and Execution |
-Writing test procedures or test scripts -Creating or acquiring the test data -Implementing the expected results -Purpose of test execution is to execute all of the test cases -Order in which the test cases are executed is significant |
|
|
Evaluating Exit Criteria and Reporting |
-Exit criteria were set in the Test Plan, and are now checked to see whether or not we have achieved them -Write a Test Summary Report |
|
|
Test Closure Activities |
-Checks are made that the correct deliverables have been produced and delivered to the right destinations -Incident reports should also be checked -Testware should be finalized, archived and handed over to those who will be responsible for maintaining it -Test environment should either be closed down or handed over -Post-project review should be held |
|
|
Sequential Software Development Models |
V-Model, W-Model, Waterfall |
|
|
Verification and Validation |
-Validation is more from a user's perspective -Verification is more concerned with internal workings |
|
|
Iterative - Incremental Development Models |
-Prototyping (Rapid Prototyping), -Rapid Application Development, -Rational Unified Process, -Agile Development Methods |
|
|
Prototyping (Rapid Prototyping) |
-Try something out (business or technical) -“Running”software, not full “working” software (not production quality), intentionallyincomplete Usesof prototypes: -Throw-away(learning what we should have built) -Pre-production(developed further) -Requirementbasis (what the system should do) -Testbasis (compare production version) -Experimental,evolutionary, exploratory |
|
|
Rapid Application Development |
Characteristics -Users, designers, testers and developers on the team --Jad = joint application development (similar idea) -Product developed in time-boxes -Number of iterations not known at start -Development of an iteration depends on feedback from earlieriteration(s) |
|
|
Rational Unified Process |
An iterative software design method -From Rational Software Corp, now part of IBM -a process framework/meta-model -Designed to be tailored for each situation -There are 6 best practices |
|
|
6 "best practices" in Rational Unified Process |
-Develop software iteratively -Manage requirements -Component based architecture -Visually model software -Verify software quality -Control changes |
|
|
Agile Development Methods |
-Best known: "extreme programming" -Values: communication, simplicity, feedback, courage -Practices: planing game, small releases, metaphor, simple design, testing (tests written first and automated), refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, coding standards |
|
|
Good Testing Within a Lifecycle Model |
-A corresponding test activity for every development activity (most visible in V-model) -Each test level has a corresponding objective specific to that level -Analysis and design of tests should begin during the corresponding development activity for each level -Testers should be involved in reviewing documents as soon as possible in the lifecycle, even if they are only draft versions |
|
|
Component Testing |
|
