![If we relate the scenarios mentioned
previously to Figure 1.2, we see that, if an
error is made and the consequent defect is
detected in the requirements at the
specification stage, then it is relatively
cheap to find and fix. The observation of
increasing defect-removal costs in software
traces back to [Boehm]. The
specification can be corrected and re-
issued. Similarly if an error is made and the
consequent defect detected in the design
at the design stage then the design can
be corrected and re-issued with relatively
little expense. The same applies for
construction.](https://image.slidesharecdn.com/softwaresystemcontexthazahara-171211040949/85/Software-system-context-hazahara-12-320.jpg)
Software system context hazahara
- 2. Testing is done differently in different contexts. For example, safety-critical software is tested differently from an ecommerce site.
- 3. These days, almost everyone is aware Of software systems. We encounter them in our homes, at work, while shopping, and because of mass-communication systems. More and more, they are part of our lives.
- 4. However, most people have had an Experience with software that did not work as expected: an error on a bill, a delay when waiting for a credit card to process and a website that did not load correctly are common examples of problems That may happen because of software problems.
- 5. Not all software systems carry the same level Of risk and not all problems have the same Impact when they occur. A risk is something that has not happened yet and it may never happen; it is a potential problem. We are concerned about these potential Problems because, if one of them didhappen, we'd feel a negative impact.
- 6. Some of the problems we encounter when using software are quite trivial, but others can be costly and damaging - with loss Of money, time or business reputation - and even may result in injury Or death. For example, suppose a user interface has typographical defects. Does this matter? It may be trivial, but it could have a significant effect, depending on the website and the defect: If my personal family-tree website has my maternal grandmother'smaiden name spelt wrong, my mother gets annoyed and I have to put up with some family teasing, but I can fix it easily and only the family see it (probably). If the company website has some spelling mistakes in the text, potential customers may be put off the company as it looks unprofessional.
- 7. Why is it that software systems sometimes don't work correctly? We know that people make mistakes - we are fallible. If someone makes an error or mistake in using the software, this may lead directly to a problem – the Software is used incorrectly and so does not behave as We expected. However, people also design and build The software and they can make mistakes during the Design and build. These mistakes mean that there are flaws in the software itself.
- 8. Do our mistakes matter? Our mistakes are also important because software systems and projects are complicated. Many interim And final products are built during a project, and people will almost certainly make mistakes and errors in all the activities of the build. Some of these are found And removed by the authors of the work, but it is difficult For people to find their own mistakes while building a product. Defects in software, systems or documents may result in failures, but not all defects do cause failures.
- 9. It is not just defects that give rise to failure. Failures can also be caused by environmental conditions as well: for example, a radiation burst, a strong mag- netic field, electronic fields, or pollution could cause faults in Hardware or firmware. Those faults might prevent or change the execution of software. Failures may also arise because of human error in interacting with the software, perhaps a wrong input value being entered or an output Being misinterpreted.
- 10. When we think about what might go wrong we have to consider defects and failures arising from: errors in the specification, design and implementation Of the software and system; errors in use of the system; environmental conditions; intentional damage; potential consequences of earlier errors, intentional damage, defects and failures.
- 11. In Figure 1.1 we can see how defects may arise in four requirements for a product. We can see that requirement 1 is implemented correctly - we understood the customer's requirement, designed correctly to meet that requirement, built cor- rectly to meet the design, and so deliver that requirement with the right attributes: functionally, it does what it is supposed to do and it also has the right non-functional attributes, so it is fast enough, easy to understand and so on.
- 12. If we relate the scenarios mentioned previously to Figure 1.2, we see that, if an error is made and the consequent defect is detected in the requirements at the specification stage, then it is relatively cheap to find and fix. The observation of increasing defect-removal costs in software traces back to [Boehm]. The specification can be corrected and re- issued. Similarly if an error is made and the consequent defect detected in the design at the design stage then the design can be corrected and re-issued with relatively little expense. The same applies for construction.
- 13. Graham et.al. (2011). ISTQB-Fondation of Software Testing. London: Cengage Learning EMEA.
- 14. http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/ http://www.uin-suska.ac.id/