Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Foundation 2011 slideshow ch 1 lesson 1
Ähnlich wie Foundation 2011 slideshow ch 1 lesson 1 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Foundation 2011 slideshow ch 1 lesson 1
- 1. Introduction – Fundamentals of Testing – Why Test?
- 2. Fundamentals of Testing – LO 1.1.1 – Why Test? Software defects can cause harm! Loss of Time Loss of Money Loss of Business Reputation Injury or Death
- 3. Fundamentals of Testing – LO 1.1.2 – Why Test? Definitions An error or mistake is something that a person does unintentionally The result of an error occurring while developing software or creating documentation is a defect or bug (also can be known as a fault) If a defect exists in software that produces an incorrect result or does not perform the correct action this is known as a failure
- 4. Fundamentals of Testing – LO 1.1.2 – Why Test? Does every defect result in a failure?
- 5. Fundamentals of Testing – LO 1.1.3 – Why Test? The Importance of Testing Software testing: Reduces risk Increases quality Required to meet contractual requirements Required to meet legal requirements Required due to industry specific standards
- 6. Fundamentals of Testing – LO 1.1.4 – Why Test? Testing and Quality Quality can be measured by analysing pass rates of functional requirements, for example: Suitability Accuracy Interoperability Compliance Security Source: ISO standard 9126 “Software engineering – Product quality”
- 7. Fundamentals of Testing – LO 1.1.4 – Why Test? Testing and Quality Quality can also be measured by analysing pass rates of non-functional requirements, for example: Reliability Usability Efficiency Maintainability Portability Source: ISO standard 9126 “Software engineering – Product quality”
- 8. Fundamentals of Testing – LO 1.1.5 – Why Test? How much testing is enough? A number of factors are important in determining how much testing is enough: Risk Quality Time Budget
Hinweis der Redaktion
- To class: Fundamentals of Testing should take approximately 2.5 hours to complete and is broken up into 5 main areas:Why is testing necessaryWhat is testing – Yes, we convince you testing is necessary before explaining in more detail, what testing is General testing principlesFundamental test processThe psychology of testingTo class: Before we start I would like to do a quick 1 minute introduction around the room. Please state your name, primary role at work and an interesting fact / hobby or favourite movie.I’ll go first – My name is James, I am a senior consultant and training manager at Knight Errant and I also enjoy Test Managing projects. A fun fact about me is that I like to grow chilli plants at home (I normally have about 10 different varieties from mild to extremely hot)
- Key Learning Objective: Software defects can cause harmAsk class: How does a software defect cause loss of time? (Looking for something like “takes user longer to complete a task”)Ask class: How does a software defect cause loss of money? (“Time is money” so the above also applies to money, but a software defect may mean a company may not meet a regulatory requirement and may be liable to pay. Virgin Airlines computer system crashing is also a good example of a company losing a lot of money due to software failure)It’s quite easy to imagine how software defects can cause loss of time, money or even business reputation.Not all software may have defects that could lead to injury or death, but can anyone give examples?You can imagine that computer software that a pilot uses will need extremely rigorous testing.=====Software systems are an increasing part of life, from business applications (e.g. banking) toconsumer products (e.g. cars). Most people have had an experience with software that did not workas expected. Software that does not work correctly can lead to many problems, including loss ofmoney, time or business reputation, and could even cause injury or death.
- Key Learning Objective: Understand definitions – Humans make errors or mistakes, when in code, they are called defects, bugs or faults.Draw the distinction between an error made in design and an error made by a coder (Diagram on whiteboard with Design document feeding code. So an error can occur in documentation and in code, and both are referred to as defects, bugs or faults).An Error or Mistake is a human action. When a human action (being an error or mistake) is made that results in incorrect code, this is known as a defect, bug or fault. “Defect in the system”, “Bug in the system” or “Fault in the system”.A failure occurs when a piece of code that contains a defect / bug / fault is executed and produces an incorrect result.Ask class: Give reasons as to why defects occur.Presenter to lead students to the following conclusions:Humans are not perfectTime pressure / constraints on a projectComplexity in code / requirements / technologiesIt should be noted that failures can also occur if there is a problem with hardware (so not just software).Many environmental factors can lead to damaged hardware which can lead to failures.=====A human being can make an error (mistake), which produces a defect (fault, bug) in the code, insoftware or a system, or in a document. If a defect in code is executed, the system will fail to dowhat it should do (or do something it shouldn’t), causing a failure. Defects in software, systems ordocuments may result in failures, but not all defects do so.Defects occur because human beings are fallible and because there is time pressure, complexcode, complexity of infrastructure, changed technologies, and/or many system interactions.Failures can be caused by environmental conditions as well: radiation, magnetism, electronic fields,and pollution can cause faults in firmware or influence the execution of software by changinghardware conditions.
- Key Learning Objective: Not every defect results in a failureAsk class: Does every defect result in a failure? Let the students debate for 1 minute maximumThe answer is ‘No’ because it is possible that in larger more complex systems not all code will be executed, even in the whole lifetime of the software.
- Key Learning Objective: Testing is important. Understand the drivers behind why we conduct software testing.Testing by itself reduces risk:If you complete testing and find no major defects, this will increase confidence that the code is of a high enough quality to ‘go-live’.If after you begin testing and find major defects, you can be confident the code is of low quality and requires fixes before it can ‘go-live’Testing is required to understand the quality of the codeOn the other hand, testing is only part of increasing the quality of the code. To increase quality, defects must be both identified (through testing) and fixed. Testing is more than finding defects, it is about having the confidence that when your system, or changes to a system go live, everything will run as expected. The confidence comes from the correct coverage of testing. Making sure the scope of testing is well defined and correct for the changes being implemented.Well planned testing up front will give a much greater chance of delivering a better product on time and to budget.Mention to class: There is great importance and benefit of testing requirements / documentation, not just code. As we saw on a previous slide, defects occur in documentation and in code. But more on that on a future slides.==============Rigorous testing of systems and documentation can help to reduce the risk of problems occurringduring operation and contribute to the quality of the software system, if defects found are correctedbefore the system is released for operational use.Software testing may also be required to meet contractual or legal requirements, or industry-specificstandards.
- Key Learning Objective: There is more than one way of measuring quality.Quality can be a measure of pass/fail rates of functional requirements.To class: We are introducing two concepts here. The concept of Quality in terms of software, as well as the concept of functional vs non-functional requirements of a system.To class: It is important to note that a system can have high quality functional requirements and still fall down in terms of non-functional requirements.To class: In short, functional requirements are “what” the system does or what the system should do.To class: Non functional requirements are “how” the systems does a task or how it should do the task.To class: We will cover non-functional requirements on the next slide.The functions that a system, subsystem or component are to perform may be described in workproducts such as a requirements specification, use cases, or a functional specification, or they maybe undocumented. Suitability: The capability of the software product to provide an appropriate set of functionsfor specified tasks and user objectives. [ISO 9126] See also functionality.Accuracy: The capability of the software product to provide the right or agreed results or effectswith the needed degree of precision. [ISO 9126] See also functionality testing.Interoperability: The capability of the software product to interact with one or morespecified components or systems. [After ISO 9126] See also functionality.Compliance testing: The process of testing to determine the compliance of the component orsystem.Security: Attributes of software products that bear on its ability to prevent unauthorizedaccess, whether accidental or deliberate, to programs and data. [ISO 9126] See alsofunctionality.======With the help of testing, it is possible to measure the quality of software in terms of defects found,for both functional and non-functional software requirements and characteristics (e.g. reliability,usability, efficiency, maintainability and portability). For more information on non-functional testingsee Chapter 2; for more information on software characteristics see ‘Software Engineering –Software Product Quality’ (ISO 9126).Testing can give confidence in the quality of the software if it finds few or no defects. A properlydesigned test that passes reduces the overall level of risk in a system. When testing does finddefects, the quality of the software system increases when those defects are fixed.Lessons should be learned from previous projects. By understanding the root causes of defectsfound in other projects, processes can be improved, which in turn should prevent those defects fromreoccurring and, as a consequence, improve the quality of future systems. This is an aspect ofquality assurance.Testing should be integrated as one of the quality assurance activities (i.e. alongside developmentstandards, training and defect analysis).
- Key Learning Objective: Quality can also be a measure of pass/fail rates of non-functional requirementsNon-functional testing includes, but is not limited to, performance testing, load testing, stresstesting, usability testing, maintainability testing, reliability testing and portability testing. It is thetesting of “how” the system works.To class: For example, a function within software performs correctly and passes functional test case, but if the user performs the same function on the screen 4 or more times the user receives an error and the system shuts down. Functionally, the operation is sound, but the software is not reliable and fails to be of high quality due to non-functional reason – reliability. You can easily imagine that end users of software will be frustrated with both functional and non-functional defects in software, so it is important to have the right test coverage of both.Reliability: The ability of the software product to perform its required functions under statedconditions for a specified period of time, or for a specified number of operations. [ISO 9126]Usability: The capability of the software to be understood, learned, used and attractive to theuser when used under specified conditions. [ISO 9126]Efficiency: The capability of the software product to provide appropriate performance,relative to the amount of resources used under stated conditions. [ISO 9126]Maintainability: The ease with which a software product can be modified to correct defects,modified to meet new requirements, modified to make future maintenance easier, oradapted to a changed environment. [ISO 9126]Portability: The ease with which the software product can be transferred from one hardwareor software environment to another. [ISO 9126]
- Key Learning Objective: There are four main driving factors that determine how much testing is enough.To class: This is not an easy question to be answered. There is no simple formula. Every project will be different.To class: A test plan written by a test manager attempts to answer this question which should then be signed off by the business. Risk will be discussed in more detail in chapter 5Quality is a function of how many test cases have been executed and passed or failed for the different types of testing in scope for the given projectTime and budget can both be constraints. The end goal of testing is to deliver high quality low risk software on time and to budget, but this is not always achievable. There are factors that are both within and outside the control of the test team. Ask class: What are some of these factors?Unrealistic deadlineUnrealistic budgetScope creep Low quality codeBadly written requirementsBadly interpreted requirementsPoorly tested codeSkill gapsIncorrect team sizeTeam structure and dynamicsTo class: Communication between the test manager and the project manager is key to reducing the risk, increasing the quality and using whatever preventative methods to steer the project towards the best possible outcome by avoiding where possible the above pitfalls.To class: Testing should provide sufficient information to stakeholders to make informed decisions about therelease of the software or system being tested, for the next development step or handover tocustomers.======Deciding how much testing is enough should take account of the level of risk, including technicaland business product and project risks, and project constraints such as time and budget. (Risk isdiscussed further in Chapter 5.)Testing should provide sufficient information to stakeholders to make informed decisions about therelease of the software or system being tested, for the next development step or handover tocustomers.