| tester | can stop testing when - all of the level 1 test cases have passed
- certain pre-defined percentages of level 2 and level 3 test cases have passed
- the targets are achieved and are maintained for at least two cycles of builds
|  |
| cannot test every possible system-wide equivalence class because of the combinatorial explosion of the space of test cases | |
| cannot test software until all the test cases have passed because it is too expensive, and perhaps futile, to try to remove every last bug from most systems | |
finds defects by - anticipating typical errors made by developers
- anticipating unusual things that users might try to do
| |
| is responsible for the first stage of testing | |
| is part of software development team | |
| is a subtopic of 10.2 - Effective and Efficient Testing | |
| is a kind of software developer | |
| knows that software developers tend to have certain habits that can lead to errors, and hence to defects | |
| must be suspicious | |
| must design tests that explicitly try to catch a range of specific types of defects that commonly occur | |
| must pay attention to detail | |
| must try to understand how programmers. designers and users think, so as to better find defects | |
| needs knowledge of software design to determine the equivalence classes of inputs | |
| should complete basic testing before inspecting software | |
| should measure the quality of both the product and the process which This allows you to plot the quality over a period of time and determine whether it is improving or not | |
| should not stop testing just when money or time runs out - the result is low quality software that fails often when users start to use it | |
| should only run one test per equivalence class using a representative member of that equivalence class as input | |
should test - every equivalence class of every individual input
- all combinations where an input is likely to affect the interpretation of another
- values at the boundaries of equivalence classes
| |
| software developer | asks several evaluators to independently perform heuristic evaluations | |
| can avoid creating design documents before starting to program but this is not a good idea and tends to result in an inflexible and overly-complex system | |
| develops software | |
| has goal rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise | |
| is part of software development team | |
| maintains software | |
| may be judged on when they deliver product, not on its quality level | |
may be reluctant to develop new libraries, APIs and frameworks because- developing anything reusable is seen as not directly benefiting the current customer
- If a developer has painstakingly developed a high-quality reusable component, but management only rewards the efforts of people who create the more visible 'final product', then that developer will be reluctant to spend time on reusable components in the future
- Efforts at creating reusable software are often done in a hurry and without enough attention to quality. People thus lose confidence in the resulting components, and in the concepts of reuse and reusability
| |
| may refuse to reuse components in which they lack confidence | |
| most often works on custom software | |
| must ensure that the set of use cases is complete and that they are expressed consistently and unambiguously | |
| must inform the project manager about any problems | |
| often fails to adequately involve users in the development process | |
| often has significantly less knowledge about modelling than about design and programming | |
| often underestimates software development time because it is very hard for people to assess the quality of software or to appreciate the amount of work involved in its development | |
| performs cost estimation | |
| reuses libraries and APIs delivered with a programming language | |
| should avoid the use of obscure features of technology because later versions of the technology might be changed in ways that are incompatible with how you have used it or the producer of the technology might go out of business or withdraw it from the market | |
| should be rewarded for developing reusable components | |
| should emphasize the use case or use cases which are central to the system, which represent a high risk because of problematic implementation, or which have high political or commercial value | |
| should identify all the use cases associated with the software product | |
| should not document a design only after it is complete | |
| should not omit design documentation | |
| should not use a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces | |
| should only reuse technology that others are also reusing | |
| should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them | |
| should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence | |
| should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs | |
| should work for several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software | |
| wants software that is easy to design and maintain and which has parts that are easy to reuse | |
| stakeholder | must agree on requirements | |
Object Oriented Software Engineering View all facts Glossary Help
