Fundamentals of testing
- 1. Fakultas Sains & Teknologi Fundamentals of testing Novika Damai Yanti
- 2. Nama : Novika Damai Yanti Nim : 11453205428 Jurusan : SISTEM INFORMASI FAKULTAS SAINS DAN TEKONOLOGI UNIVERSITAS ISLAM NEGERI SULTAN SYARIF KASIM RIAU
- 3. 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
- 4. WHY IS TESTING NECESSARY? • Describe, with examples, the way in which a defect in software can cause harm to a person, to the environment or to a company. (K2) • Distinguish between the root cause of a defect and its effects. (K2) • Give reasons why testing is necessary by giving examples. (K2) • Describe why testing is part of quality assurance and give examples of how testing contributes to higher quality. (K2) • Recall the terms 'mistake', 'defect', 'fault', 'failure' and the corresponding terms 'error' and 'bug'. (K1) • Explain the fundamental principles in testing. (K2)
- 5. Introduction In this section, we're going to kick off the book with a discussion on why testing matters. We'll describe and illustrate how software defects or bugs can cause problems for people, the environment or a company. We'll draw important distinctions between defects, their root causes and their effects. We'll explain why testing is necessary to find these defects, how testing promotes quality, and how testing fits into quality assurance. In this section, we will also introduce some fundamental principles of testing.
- 6. 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).
- 7. 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.
- 8. Viewpoints of expectations and quality
- 9. How much testing is enough? Testing Principle - Exhaustive testing is impossible • Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
- 10. of the driving to the point where the driver cannot pass. The format of the driving test and the conduct of the examiner are worth considering: • The test is planned and prepared for. In advance of the test, the examiner has planned a series of routes which cover the key driving activities to allow a thorough assessment of the driver's performance. The drivers under test do not know what route they will be asked to take in advance, although they know the requirements of the test. • The test has known goals – assessing whether the driver is sufficiently safe to be allowed to drive by themselves without an instructor, without endanger ing themselves or others. There are clear pass/fail criteria, based on the number and severity of faults, but the confidence of the examiner in the driving is also taken into account. • The test is therefore carried out to show that the driver satisfies the require ments for driving and to demonstrate that they are fit to drive. The examiner looks for faults in the driving. The time for the test is limited, so it is not a complete test of the driver's abilities, but it is representative and allows the examiner to make a risk-based decision about the driver. All the drivers are tested in an equivalent way and the examiner is neutral and objective. The examiner will log factual observations which enable a risk assessment to be made about the driving. Based on this, a driver who passes will be given a form enabling him to apply for a full driving license. A driver who fails will get a report with a list of faults and areas to improve before retaking the test. • As well as observing the driver actually driving, the examiner will ask questions or the driver will take a written exam to check their under standing of the rules of the road, road signs, and what to do in various traffic situations.
- 11. Defining software testing • With that analogy in mind, let's look at the ISTQB definition of software testing. Let's break the definition down into parts; the definition has some key phrases to remember.
- 12. First, let's look at testing as a process: • Process – Testing is a process rather than a single activity – there are a series of activities involved. • All life cycle activities – Chapter 2 looks at testing as a process that takes place throughout the software development life cycle. We saw earlier that the later in the life cycle we find bugs, the more expensive they are to fix. If we can find and fix requirements defects at the requirements stage, that must make commercial sense. We'll build the right software, correctly and at a lower cost overall. So, the thought process of designing tests early in the life cycle can help to prevent defects from being introduced into code. We sometimes refer to this as 'verifying the test basis via the test design'. The test basis includes documents such as the requirements and design specifications. You'll see how to do this in Chapter 4. • Both static and dynamic – We'll see in Chapter 3 that as well as tests where the software code is executed to demonstrate the results of running tests (often called dynamic testing) we can also test and find defects without exe cuting code. This is called static testing. This testing includes reviewing of documents (including source code) and static analysis. This is a useful and cost effective way of testing. • Planning – Activities take place before and after test execution. We need to manage the testing; for example, we plan what we want to do; we control the test activities; we report on testing progress and the status of the software under test; and we finalize or close testing when a phase completes. Chapter 5 covers these test management activities.
- 13. • Preparation – We need to choose what testing we'll do, by selecting test con ditions and designing test cases. Chapter 4 covers the test design activities. • Evaluation – As well as executing the tests, we must check the results and evaluate the software under test and the completion criteria, which help us decide whether we have finished testing and whether the software product has passed the tests. • Software products and related work products – We don't just test code. We test the requirements and design specifications, and we test related documents such as operation, user and training material. Static and dynamic testing are both needed to cover the range of products we need to test.
- 14. Software test and driving test compared We can see that the software test is very like a driving test in many ways, although of course it is not a perfect analogy! The driving examiner becomes the software tester. The driver being examined becomes the system or software under test, and you'll see as we go through this book that the same approach broadly holds.
- 15. – Planning and preparation - Both the examiner and the tester need a plan of action and need to prepare for the test, which is not exhaustive, but is repre sentative and allows risk-based decisions about the outcome. – Static and dynamic - Both dynamic (driving the car or executing the software) and static (questions to the driver or a review of the software) tests are useful. – Evaluation - The examiner and the tester must make an objective evaluation, log the test outcome and report factual observations about the test. – Determine that they satisfy specified requirements – The examiner and tester both check against requirements to carry out particular tasks successfully. – Demonstrate that they are fit for purpose - The examiner and the tester are not evaluating for perfection but for meeting sufficient of the attributes required to pass the test. – Detect defects - The examiner and tester both look for and log faults.
- 16. When can we meet our test objectives? We can use both dynamic testing and static testing as a means for achieving similar test objectives. Both provide information to improve both the system to be tested, and the development and testing processes. We mentioned above that testing can have different goals and objectives, which often include: • finding defects; • gaining confidence in and providing information about the level of quality; • preventing defects.
- 17. • Referensi : Graham et.al (2011)