Foundation Level Alexandar Despotovici

Foundation Level Overview

Alexandar Despotovici

About ISTQBfounded in November 2002 a not-for-profit association legally registered in Belgiumin Romania, since 2007 ISTQB trainings and certifications are done by ANIS (Employers Association of the Software and Services Industry) Trainings by ANIS are done in partnership with Quality House BulgariaANIS is handling exams by an agreement with SEETB (South East European Testing Board)Geographic coverage

ISTQB Levels

Fondation Level

Learning materialsFoundatin Level SyllabusStandard glossary of terms used in Software TestingLearning materials from Quality House:Over 400 slides of training materialBasics of Software-TestingBooks:Software Testing Foundations: A Study Guide for the Certified Tester Exam; A. Spillner, T. Linz, H. SchaeferSoftware Testing - An ISTQB-ISEB Foundation Guide Second Edition; B. Hambling, P. Morgan, A. Samaroo, G. Thomson, P. WiliamsFoundations of Software Testing - ISTQB Certification; D. Graham, E. van Veenendaal, I. Evans, R. BlackExercises and sample examsTrainingTakes 3 days

Mainly is theoretical but there are also some exercises

All syllabus is covered with more focus on some important parts

In day three is an mock examExamThe exam is structured on multiple-choice questions Each question has only one correct answerNumber of questions and length of exams are: 40 questionslength = 1h (75 minutes for candidates taking exams not in their native language) Questions are defined in a very strict way Exams can be held without attending the courseTo pass the exam 26 correct answers are needed Promovability is 75%

Exam QuestionsQuestions are selected according to defined set of rules: Proportional distribution of questions on the basis of Syllabus chapters topics. Section 1 7 questionsSection 2 6 questionsSection 3 3 questionsSection 4 12 questionsSection 5 8 questionsSection 6 4 questionsDistribution of questions on the basis of different types: K1 = Remember (mnemonic contents), K2 = Understand (conceptual contents), K3 = Apply (exercise that requires the use of testing notions or techniques) K4 = Analyze (exercise that requires also a contextual analysis) Fondation Level

SW Testing FundamentalsError its a mistake made by a person (the cause)Bug=Defect=Fault=Problem A flaw in a component or system Failure Actual deviation of the component or system from its expected delivery, service or result.

Defect Masking - It is possible that a fault is hidden by one or more other faults in different parts of the applicationSW Testing FundamentalsTesting can show failures that are caused by defectsDebuging is a development activity that identifies the cause of defect, repairs the code and checks that the defect has been fixed correctly

The responsability for each activity is differentTesters testDevelopers debugTesting is not debugging!SW Testing FundamentalsPrinciple 1: Testing shows the presence of defects, not their absencePrinciple 2: Exhaustive testing is not possiblePrinciple 3: Testing activities should start as early as possiblePrinciple 4: Defects tend to cluster togetherPrinciple 5: The pesticide paradoxPrinciple 6: Testing is context dependentPrinciple 7: Absence-of-errors fallacySW Testing Fundamentals what and how is going to be testedfine detail of what to test (test conditions)the most visible part of testingat the end of test executionmaking sure that everything is tided away

Fondation Level

Testing Throughout the SW Life Cycle

Testing Throughout the SW Life CycleTest typesFunctional testing WHAT the system doesBlack-box testingIncludes Security and Interoperability testingNon-functional testing HOW the system worksUsability testingStress testingStorage testingPerformance testingRecovery testingVolume testingInstallability testingDocumentation testingLoad testingStructural testing white-box testingTesting related to changesRe-testingRegression testingFondation Level

Static TechniquesReview ProcesWalktroughInformal ReviewTechnical ReviewsInspectionsWhatReq & DesignEverythingEverythingSpecs & CodeApproachInformalInformalFormalFormalWhy/whenBefore detailAlways*Before detailBefore sign offLead byAuthor(s)PeerTechnical ExpertModeratorAddressed toIT & BusinessAuthorIT & BusinessAuthor(s)/ Project team*Always: can be done at all points when a document is releasedStatic TechniquesStatic Analisys by toolsIs performed without actually executing the software being examined by tool; dynamic testing does execute the software codeCan locate defects that are hard to find in testingFinds defects rather than failuresAtatic Analisys tools:Analyze program code, as well as generated output as HTML and XMLTypically used by:Developers before and during component testingDesigners during software modelling Fondation Level

Test Design TechniquesThe purpose of test design techniques is to identify test conditions and test casesSome techniques fall clearly into a single category, others have elements of more than one category

The syllabus refers to:Specification-based approaches as black-box techniquesStructure-based approaches as white-box techniquesExperience-based approachesTest Design TechniquesBlack box testing focuses on functionalityBlack box test techniquesEquivalence PartitioningBoundry Value AnalysisDecision Table (Cause Effect Graphing)State TransitionUse Case TestingSyntax TestingRandom TestingTest Design TechniquesWhite box testing focuses on codeWhite box test techniquesStatement TestingDecision TestingBranch Condition TestingBranch Condition Combination TestingModified Condition Decision TestingLinear Code Sequence & Jump (LCSAJ)Data Flow TestingTest Design TechniquesIn the Experience-based testing the tests are derived from the testers skills, intuition and experience

Error guessing a technique where the testers experience is used

Exploratory testing an informal test design technique where the tester actively controls the design of the testsFondation Level

Test Management

Test ManagementTest planning and estimationTest planningEntry criteriaExit criteriaTest estimationTest strategy and approachTest progress monitoring and controlTest progress monitoringTest reportingTest control

Test ManagementRisk a factor that could result in future negative consequences, usually expressed as impact and likelihoodLevel of risk = probability of the risk occurring impact if it did happenProject risksSupplier issues:Failure of a third party to deliver on time or at allContractual issues, such as meeting acceptance criteriaOrganisational factorsSkills, training and staff shortagesPersonal issuesTechnical issuesTest environment not ready on timeProblems in defining the right requirementsProduct risksFailure-prone software deliveredThe potential that a defect in the software/hardware could cause harm to an individual or companySoftware that does not perform its intended functions.Test ManagementIncident managementThe process of recognising, investigating, taking actionand disposing of incidents.It involves recording incidents, classifying them and identifying the impact. The process of incident management ensures that incidents are tracked from recognition to correction, and finally through retest and closure.Configuration managementFor testers, configuration management helps to uniquely identify (and to reproduce) the tested item, test documents, the tests and the test harness(es)Fondation Level

Tool support of testing Types of Test Tools:Tool support for management of testing and testsTest management toolsRequirements management toolsIncident management tools (Defect Tracking Tools)Configuration management toolsTool support for static testingReview toolsStatic analysis toolsModeling toolsTool support for test specificationTest design toolsTest data preparation toolsTool support for test execution and loggingTool support for performance and monitoringTool support of testing Stages in the process of introducing a tool into an organisation

Objectives of the Pilot Project

Success factors for the tool deployment

http://www.istqb.org/