![Role of testing in software development,
maintenance and operations
We may also be required to carry out software testing to meet contractual or legal
requirements, or industry-specific standards. These standards may specify what
type of techniques we must use, or the percentage of the software code that must be
exercised. It may be a surprise to learn that we don't always test all the code; that
would be too expensive compared with the risk we are trying deal with. However -
as we'd expect - the higher the risk associated with the indus- try using the software,
the more likely it is that a standard for testing will exist. The avionics, motor,
medical and pharmaceutical industries all have standards covering the testing of
software. For example, the US Federal Aviation Administration's DO-178B standard
[RTCA/DO-178B] has requirements for test coverage.](https://image.slidesharecdn.com/01fundamentalsoftesting-171209121558/85/01-fundamentals-of-testing-7-320.jpg)
01 fundamentals of testing
- 1. Ilham Wahyudi Program Studi S1 Sistem Informasi Fakultas Sains dan Teknologi Universitas Islam Negeri Sultan Syarif Kasim Riau Referensi : Graham et.al (2006) http://sif.uin-suska.ac.id/
- 2. CHAPTER 1 Fundamentals of testing In this chapter, we will introduce you to the fundamentals of testing: why testing is needed; its limitations, objectives and purpose; the principles behind testing; the process that testers follow; and some of the psychological factors that testers must consider in their work. By reading this chapter you'll gain an understanding of the fundamentals of testing and be able to describe those fundamentals. We should assume our work contains mistakes, we all need to check our own work. However, some mistakes come from bad assumptions and blind spots, so we might make the same mistakes when we check our own work as we made when we did it. So we may not notice the flaws in what we have done.
- 3. Software systems context 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. 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.
- 4. Causes of software defects 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. These are called defects or sometimes bugs or faults. Remember, the software is not just the code; check the definition of soft- ware again to remind yourself. When the software code has been built, it is executed and then any defects may cause the system to fail to do what it should do (or do something it shouldn't), causing a failure. Not all defects result in failures; some stay dormant in the code and we may never notice them.
- 5. Cont... 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. We could argue that if a mistake does not lead to a defect or a defect does not lead to a failure, then it is not of any importance - we may not even know we've made an error. Additionally, we are more likely to make errors when dealing with perplexing technical or business problems, complex business processes, code or infrastructure, changing technologies, or many system interactions. This is because our brains can only deal with a reasonable amount of complexity or change - when asked to deal with more our brains may not process the information we have correctly.
- 6. Cont... 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.
- 7. Role of testing in software development, maintenance and operations We may also be required to carry out software testing to meet contractual or legal requirements, or industry-specific standards. These standards may specify what type of techniques we must use, or the percentage of the software code that must be exercised. It may be a surprise to learn that we don't always test all the code; that would be too expensive compared with the risk we are trying deal with. However - as we'd expect - the higher the risk associated with the indus- try using the software, the more likely it is that a standard for testing will exist. The avionics, motor, medical and pharmaceutical industries all have standards covering the testing of software. For example, the US Federal Aviation Administration's DO-178B standard [RTCA/DO-178B] has requirements for test coverage.
- 8. Testing and quality Testing helps us to measure the quality of software in terms of the number of defects found, the tests run, and the system covered by the tests. We can do this for both the functional attributes of the software (for example, printing a report correctly) and for the non-functional software requirements and characteristics (for example, printing a report quickly enough). A well-designed test will uncover defects if they are present and so, if such a test passes, we will rightly be more confident in the software and be able to assert that the overall level of risk of using the system has been reduced. When testing does find defects, the quality of the software system increases when those defects are fixed, provided the fixes are carried out properly.
- 9. Cont... What is quality? Projects aim to deliver software to specification. For the project to deliver what the customer needs requires a correct specification. Additionally, the delivered system must meet the specification. This is known as validation ('is this the right specification?') and verification ('is the system correct to specification?'). Of course, as well as wanting the right software system built correctly, the customer wants the project to be within budget and timescale – it should arrive when they need it and not cost too much. The ISTQB glossary definition covers not just the specified requirements but also user and customer needs and expectations. It is important that the project team, the customers and any other project stakeholders set and agree expectations. We need to understand what the customers understand by quality and what their expectations are.
- 10. Cont... What we as software developers and testers may see as quality – that the software meets its defined specification, is technically excellent and has few bugs in it – may not provide a quality solution for our customers. Furthermore, if our customers find they have spent more money than they wanted or that the software doesn't help them carry out their tasks, they won't be impressed by the technical excellence of the solution. If the customer wants a cheap car for a 'run- about' and has a small budget then an expensive sports car or a military tank are not quality solutions, however well built they are.
- 11. Cont... If your testing is confined to software, you might look at these and say, 'These are not software problems, so they don't concern us!' So, as software testers we might confine ourselves to reporting the printer driver failure. However, our remit as testers may be beyond the software; we might have a remit to look at a whole system including hardware and firmware. Additionally, even if our remit is software, we might want to consider how software might help people prevent or resolve problems; we may look beyond this view. The software could provide a user interface which helps the user anticipate when paper or ink is getting low. It could provide simple step-by-step instructions to help the users change the cartridges or replenish paper. It could provide a high temperature warning so that the environment can be managed. As testers, we want not just to think and report on defects but, with the rest of the project team, think about any potential causes of failures`.