ISQTB Training Course

ISQTB software testing standard

1. ISTQB® Certified Tester Foundation Level (CTFL) Training Fernando Ferrer
2. Before We Start  Fernando – Trainer – Contact number: (312) 471-6730 – Email: Fernando.ferrer@nobleprog.ca  Participants – What do you do? – Why are you taking this course?  Course details – Theory + practice  A bit of practice test every day 2 ISTQB
3. Trainer  Fernando  Experience – 12+ years of experience as a data engineer and Big Data consultant – 8+ years of experience as a business consultant – 2+ years as corporate trainer – Your turn 3 ISTQB
4. Before we begin – Schedule  Starts 09:30  Ends 16:30  Lunch – 60 mins  Break – 10-15 mins AM – 10-15 mins PM  Practical portion at the end 4 ISTQB
5. Course details Course title: ISTQB® Certified Tester Foundation Level (CTFL)  Scope: Training – Knowledge needed for certification  At the end – Trainer evaluation sheet  Sent to your email inboxes – Course certificates of completion  Sent to your email inboxes 5 ISTQB
6. ISTQB® History and business case  ISTQB® (International Software Testing Qualifications Board)  Qualification certification organization ran by volunteers  Founded in 2002 in Scotland  Over 500,000 certifications issued  Levels: – Foundation – Advanced – Expert  Streams: – Core (horizontal: tech/methodology/ application) – Agile (SDLC in agile environment) – Become a specialist (vertical: usability, security, performance, etc.) 6 ISTQB
7. ISTQB® History and business case 7 ISTQB
8. ISTQB® Introduction  Foundation level – Foundation Level qualification is aimed at professionals who need to demonstrate practical knowledge of the fundamental concepts of software testing – Ideal for:  Test engineers  Non-technical managers  IT professionals  Anyone who needs basic understanding of software testing 8 ISTQB
9. ISTQB® Introduction  Advance level – Foundation Level qualification is aimed at professionals who have advanced in their careers in the software testing field – Ideal for:  Test managers  Test analyst  Technical test analyst  Must hold previous foundational level plus proven experience as tester 9 ISTQB
10. ISTQB® Introduction  Expert level – Defined business outcome – Maps to objective of individuals  Test management  Improving the test process  Test automation  Security testing 10 ISTQB
11. ISTQB® Introduction 11 ISTQB
12. ISTQB® Introduction  Foundation level – Objectives  Common language for effective communications  Understand and stablish testing concepts  Design and prioritize tests based on current techniques  Write clear incident reports  Effectively participate in reviews  Be familiar with testing tools, how and when to use them 12 ISTQB
13. ISTQB® Introduction  Foundation level – The exam  40 Multiple choice questions  1 point per correct answer  65% or better to pass  60 minutes time limit (75 if test is not in candidate’s mother tongue) 13 ISTQB
14. ISTQB® Introduction  Foundation level – The exam  40 Multiple choice questions  1 point per correct answer  65% or better to pass  60 minutes time limit (75 if test is not in candidate’s mother tongue)  Divided in “K” levels 14 – K1 (remember) Candidate must remember a term or concept – K2 (understanding) Candidate must select an explanation for a statement – K3 (apply) Candidate must choose what technique or process to be applied – K4 (analyze) Candidate must separate information of a technique process and break it down into its parts and how to use them ISTQB
15. ISTQB® Software testing  Why? – A software defect/bug can cause harm to a person, business or it can cost significant amounts of money  Aircraft navigation/communication/flight systems  Automated bank fraud detection systems  Chemotherapy pumps – Humans make mistakes, software is made by humans  “Coding is the process of inserting bugs into your software”  Some errors have minimal impacts, some others don’t  Knowing how to test software gives you the ability to prioritize and check for the kind of errors that will make the most damage 15 ISTQB
16. ISTQB® Software testing  Examples: – Personal blog?  Who does an error affect?  Perceive image/reputation damage? – Business website  Reputation damage  Unprofessional – Online banking websites  Clients might pull their money putting the bank out of business – Air traffic control systems  Risk of loss of lives 16 ISTQB
17. ISTQB® Software testing  Where do bugs/defects come from: – Mistakes during requirement gathering – Mistakes during design – Mistakes during coding (bugs) 17 ISTQB
18. ISTQB® Software testing 150X !!! ts c e ef d g ts n i nd efec time i f of g d er t s ixin ov o C d f es an reas inc Cost 18 ISTQB Requirements Design Coding Testing Production
19. ISTQB® Software testing and Software quality  Testing helps measure quality – The “Edwards Deming” Approach  Testing provides confidence in software – “Would you board a plane if you wrote the code for its systems?” – “A professor at a university is boarding a plane and his colleague says to him: did you know your students wrote the software for this plane? Aren’t you worried?. The professor replies: not one bit, knowing my students, this thing won’t get off the ground” 19 ISTQB
20. ISTQB® Software testing and Software quality  Quality – The degree to which a product, process or system meets requirements and expectations – For testers and developers, if software meets requirements it is of good quality – For stakeholders it might be different. They are looking value for money. They evaluate:  Fit for use  Ease of use  Attributes and features 20 ISTQB
21. ISTQB® Software testing and Software quality  Root cause – Pareto principle (80/20)  Named after Vincent Pareto – If your software fails, look for the actual cause of the failure  Often the failure seen is a symptom of something else 21 ISTQB
22. ISTQB® Software testing principles  There are 7 principles to study – Testing shows the presence of defects  It is almost impossible to prove a negative – Exhaustive testing is impossible – Early testing – Defect clustering – Pesticide paradox – Testing is context dependent – Absence-of-error fallacy 22 ISTQB
23. ISTQB® Software testing principles  Testing shows the presence of defects – Testing can show that defects are present, but cannot prove that there are no defects – Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not proof of correctness – The swan paradox  Have you ever seen a swan?  If you haven’t, this is a swan  Swans are white 23 ISTQB
24. ISTQB® Software testing principles  Testing shows the presence of defects – Testing can show that defects are present, but cannot prove that there are no defects – Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not proof of correctness – The swan paradox  Have you ever seen a swan?  If you haven’t, this is a swan  Swans are white????!!!! 24 ISTQB
25. ISTQB® Software testing principles  Exhaustive testing is impossible – Testing every possible combination of inputs is not feasible. Too much time and money. Except for trivial cases (Boolean) – Let’s test an input field that is 1 character long. How many tests are required?  10 numeric characters  26 lower case letters (English language)  26 Upper case letters (English Language)  Some additional special and punctuation characters  Total of ~70 different tests 25 ISTQB
26. ISTQB® Software testing principles  Exhaustive testing is impossible – Let’s test all 15 input fields on a form. Input is a drop down menu with 5 possible values  5 ^ 15 = Over 30 Billion combination 26 ISTQB
27. ISTQB® Software testing principles  Early testing – Start testing as early as possible in the SDLC – Cheaper and easier to fix errors early on – Objective after development: Find as may defects as you can – In maintenance phase the testing should be focus on integration and the introduction of new defects – Production testing should focus on reliability and availability 27 ISTQB
28. ISTQB® Software testing principles  Error clustering – Most defects cluster together around a particular modules – Should be part of the risk assessment when designing test plan – Testing should focus around those “hot-spots” 28 ISTQB
29. ISTQB® Software testing principles  Pesticide paradox At last! I got rid of all the mice! 29 ISTQB
30. ISTQB® Software testing principles  Pesticide paradox – If you fix all the issues, you need to focus on other part of the systems – Focus should change to requirements and design defects – Don’t just run same old test scenarios. Review them and create new ones 30 ISTQB
31. ISTQB® Software testing principles  Testing is context dependent – The higher the risk the more and better testing is required – There are different tools and methodology to test software  Some tools are expensive and do a good job – If software has the potential to harm life, affect businesses, a good methodology is a MUST! 31 ISTQB
32. ISTQB® Software testing principles  Absence-of-error fallacy – Customers NEVER ask how many errors did you fix or if the software is error free – Customers care their software meets their needs and expectations – An error free software package does not mean is a great software package – Example:  Tax filing system A: has a couple of errors, it crashes if multiple windows are open and it might log you out after random periods of time. However, software calculates all deductions and exceptions properly and facilitates the filing and calculation of taxes  Tax filing system B: No errors whatsoever, it never crashes, it never hangs, everything works. However, the system calculates deductions erroneously and makes you pay more taxes than you should  Which one will you choose? 32 ISTQB
33. ISTQB® Fundamental test process  Starts from the design phase until the closing phase  Should take into consideration amount of time from planning to conclusion  The idea of the fundamental test process has been developed over the years  Each portion of the test process can be implemented at different levels as required 33 ISTQB
34. ISTQB® Fundamental test process  Test process steps – Planning and control – Analysis and design – Implementation and execution – Evaluating exit criteria and reporting – Test closure activities 34 ISTQB
35. ISTQB® Fundamental test process  Test process steps – Planning and control  Decide which components, systems or other products are in the test scope  Decide the business, product, project and technical risks which need to be addressed  What are we testing for 35 – Uncover defects – Meets requirements – Fit for use ISTQB
36. ISTQB® Fundamental test process  Test process steps – Planning and control  Determine test approach – How testing will be done? – What techniques? – Who will be involved? – Deliverables (test case, test data)  Ensure testing adheres to company policies  Define resources needed 36 – Software – Hardware – Human capital ISTQB
37. ISTQB® Fundamental test process  Test process steps – Planning and control  Prepare plan and schedule tasks  Set when to finish testing (exit criteria)  Control test progress – Prepare reports – Benchmark progress against plan  Track 37 – Number of test executed – Pass/fail percentage – Remaining tests ISTQB
38. ISTQB® Fundamental test process  Test process steps – Analysis and design  We build procedures and test scripts to use – Review software requirements – Start designing black box testing – Prepare test conditions  Make sure all requirements are “testable” 38 ISTQB
39. ISTQB® Fundamental test process  Test process steps – Implementation and execution  Take test conditions and into test cases and define what needs to be done to execute plan 39 – Develop test cases and prioritize them – Prepare test environments – Execute test cases and record output – Report incidents comparing expected and actual results – Perform retest after initial fix ISTQB
40. ISTQB® Fundamental test process  Test process steps – Evaluating Exit Criteria and Reporting  Execution assessed against defined objectives 40 – All incident reports have been filed – All defects found fixed – Archive test infrastructure, cases and scripts – Record passed/failed percentage and determined if meets criteria to exit ISTQB
41. ISTQB® Fundamental test process  Test process steps – Test Closure Activities  Collect all documentation  Finalize test report  Document test ware for maintenance phase  Analyze lessons learned with improving SDLC in mind 41 ISTQB
42. ISTQB® The Psychology of testing  People psychological state and testing – Personal Ego – Antagonism – Self-doubt – Non-competitive actions – Constructive criticism sandwich  Objective – Clear objective – Independent testing – Feedback on defects – Clear and courteous communication 42 ISTQB
43. ISTQB® The Psychology of testing  Independent testing – Mindset of building something is different  Positive mindset towards finishing a build – Mindset of testing is negative  Look for defects, how to brake thinks – Finding mistakes in your own work is difficult  An independent party could find issues easier and faster  Developers test their code but actual QA is done by third party – Independent testing is more efficient and avoids author bias 43 ISTQB
44. ISTQB® The Psychology of testing  Levels of independence – Developers test their own code (0) – Developers test other developers code (1) – Another developer from another division/department test your code (2) – Another organization tests your code (3) 44 ISTQB
45. ISTQB® The Psychology of testing  How to communicate defects – Don’t gloat (reward good behavior) – Don’t criticize, punish or blame developers – Criticism sandwich  What worked – what didn’t work – what you like – Stay focused on test plan – Prioritize properly  If everything is high priority, nothing is high priority – DO NOT be pessimistic – Be polite and kind – Understand other people’s feeling 45 ISTQB
46. ISTQB® Software development models  Testing is not standalone activity and it does not exist isolation  Depending on the model, testing has its specific place  The selection of SD model determines how testing will be organized  Different test levels in SDLC – Unit testing (developers) – Integration – System – User acceptance 46 ISTQB
47. ISTQB® Software development models  There are different type of models – Waterfall  Very controlled  Testing not started after requirement gathers, approved and software written – Agile  Short sprints  Design, develop, test and deliver  Less controlled and more fluid – Testing for each of the models would be different  Depending on model selection, when and where to test is different – Verification and validation testing is done regardless of model 47 ISTQB
48. ISTQB® Software development models  Verification – Does the software meets requirements?  Is the deliverable built according to specifications?  Validation – Is the software fit for purpose  Does it meet end user needs?  Captures gaps in requirements design 48 ISTQB
49. ISTQB® Software development models  waterfall 49 ISTQB
50. ISTQB® Software development models  Waterfall – Issues regarding testing  Rigid, can’t modify a previous face if testers found it defective  Testing done after the fact  Expensive to fix defects 50 ISTQB
51. ISTQB® Software development models  V-model 51 ISTQB
52. ISTQB® Software development models  V-model – Issues regarding testing  Still rigid  It is still Expensive to fix defects because phases are tested in isolation after approval. If defects in designed are found they are usually found later down the line 52 ISTQB
53. ISTQB® Software development models  Iterative 53 ISTQB
54. ISTQB® Software development models  Rapid application development 54 ISTQB
55. ISTQB® Software development models  Agile methodology – Comes from word “Agility” – Rapid adoption of changes – No rigidity – Continuous stakeholder feedback – Based on iterative and incremental development 55 ISTQB
56. ISTQB® Test levels  Component or unit testing – A unit is the smallest piece of software  Module  Function – Done to ensure the smallest components of a software system are working correctly – Isolates smallest units and tests them independently – STUBS and DRIVERS are used to replace missing pieces during testing 56 ISTQB
57. ISTQB® Test levels  Component or unit testing – STUB  Dummy piece of code that interacts with unit being tested Calculate age Module Random date generator (stub) 57 ISTQB
58. ISTQB® Test levels  Component or unit testing – Driver  Dummy piece of code that generates and coordinates dummy calls to test units Calculate age (Driver) Get date of birth module 58 ISTQB
59. ISTQB® Test levels  Component or unit testing – Checking for functional and non-functional issues  Resource behavior (Memory leaks, disk space, etc.)  Robustness testing (validity of input)  Structural testing (branch coverage) – Always done by developers, rarely done by testers  Needs access to code and development environment – Defects are fixed as soon as found, rarely documented – Not defect logging 59 ISTQB
60. ISTQB® Test levels  Integration testing – Tests integration among components – Concentrates only on integration – Should be built in the most efficient order – Tests interactions between different parts of a software system » Internal components » External • • • • 60 ISTQB OS File system Remote client Among others
61. ISTQB® Test levels  Integration testing – Levels » Component integration • Integration of software components • Done after unit testing » System integration • Integration of different systems • Evaluate cross-platform issues 61 ISTQB
62. ISTQB® Test levels  Integration testing approaches – Big Bang approach » Test whole system » Advantage: no drivers or stubs required » Disadvantage: harder to trace issues – Incremental Integration testing approaches » Top down » Bottom up » Functional increments » Testing is done unit by unit • Easy to find defects 62 ISTQB
63. ISTQB® Test levels  Integration testing approaches – Incremental Integration testing » Top down • From top to bottom (GUI to back end) • Top level is tested using stubs for bottom level • Testing continues by replacing stubs with code » Bottom up • From Bottom up (backend to GUI) • Bottom level is testing using drivers for upper level • Testing continues by replacing drivers with code 63 ISTQB
64. ISTQB® Test levels  System testing 64 – Testing the behavior of whole system – Carried out by specialist – Test environment should be exactly the same as production environment – Should test functional and non-functional requirements – Black box techniques should be use for testing functional requirements – White box techniques might be used to test thoroughness ISTQB
65. ISTQB® Test levels  System testing – System testing includes test cases based on » Software requirement specifications » Business process » End user scenarios » High level descriptions of system » Risk of system 65 ISTQB
66. ISTQB® Test levels  Acceptance testing 66 – Done after all defects found have been fixed – Responsibility of customers (other stakeholders as well) – Main goal is to established confidence in the system – Environment should mirror production – Focus should not be in finding defects, it should be in assessing if software is fit for purpose ISTQB
67. ISTQB® Test levels  Acceptance testing – Forms of acceptance testing » User acceptance » Operational acceptance » Contract acceptance » Compliance acceptance » Alpha testing » Beta testing 67 ISTQB
68. ISTQB® Test levels  Acceptance testing – Forms of acceptance testing » User acceptance • Validate fit for use by business users and stakeholders • Example: Final demo of release candidate » Operational acceptance • Meeting operational requirements • Backups • Recovery • Updates • And so on 68 ISTQB
69. ISTQB® Test levels  Acceptance testing – Forms of acceptance testing » Contract acceptance • Test against Acceptance criteria on signed contract at beginning of relationship • Formally design BEFORE signing the contract 69 ISTQB
70. ISTQB® Test levels  Acceptance testing – Forms of acceptance testing » Compliance acceptance • Test the compliance of government, legal and regulatory framework impose by regulators in the space 70 ISTQB
71. ISTQB® Test levels  Alpha testing – Done at the site where software is being developed – Developers are not part of the test – Some customers are involved  Beta testing (Field testing) – Done by groups of existing users – No support from developers – Use to acquire feedback from the masses  Example of Alpha and Beta testing – Gmail was alpha tested by google. Other developers within Google tested it – Afterwards, Gmail had an invite process to allow access to a certain number of regular users 71 ISTQB
72. ISTQB® Test types  Functional testing (black box) – Testing of a function performed by the software (save/retrieve data, calculations, etc..)  Non-functional testing – Testing non-functional characteristics (performance, load, etc..)  White box (Structural) – Testing structure or architecture of the system  Regression testing (re-testing) – Testing previously tested components after a new change has been introduced 72 ISTQB
73. ISTQB® Test types  Functional testing (black box) – Functionality of system is usually described in software requirement documents or use cases – It considers the specified behavior of the system 73 ISTQB
74. ISTQB® Test types  Functional testing how to do it? – Requirements based  Uses SRS as basis for designing the tests  Prioritize based on risk criteria specified in requirements documents – Business processed based  Using knowledge of the business to design test cases  Describes the scenarios of the day to day of the business  Requires deep knowledge of the business  Use cases are very useful to design test cases 74 ISTQB
75. ISTQB® Test types  Non-functional testing – Test the attributes not related to the functionality of the software – Aims to test how fast or how well an operation is performed by the software – Some of the types are  Performance testing  Load testing  Stress testing  Usability testing  Reliability testing  Portability testing  Maintainability testing 75 ISTQB
76. ISTQB® Test types  Non-functional testing – Test the attributes not related to the functionality of the software – Aims to test how fast or how well an operation is performed by the software – Some of the types are  Performance testing  Load testing  Stress testing  Usability testing  Reliability testing  Portability testing  Maintainability testing 76 ISTQB
77. ISTQB® Test types  Structural/white box – It looks at what is actually happening “inside the box” – Performed with test coverage tools that access the executable elements – If less than 100% of the executables are not covered by those tools, additional tests need to be design 77 ISTQB
78. ISTQB® Test types  Regression/Re-testing – Test perform when changes are introduced into the software  After fixing defects and bugs  After adding additional functionality – Types  Confirmation – Once a bug/defect is logged as fixed, the test is done again to confirm it has been fixed – Same steps as initial test must be followed  Regression 78 – Done to find unexpected side effects of defect fixes or changes in other areas of the code – All tests MUST be performed to new release candidate ISTQB
79. ISTQB® Maintenance testing  After software is deployed to production it remains in service for years or sometimes even decades  All testing performed during this period is considered maintenance testing  During this period software is changed to add functionality and bugs are found and fixed  Testing must be done every time bugs are fixed and new functionality is added 79 ISTQB
80. ISTQB® Maintenance testing  After software is deployed to production it remains in service for years or sometimes even decades  All testing performed during this period is considered maintenance testing  During this period software is changed to add functionality and bugs are found and fixed  Testing must be done every time bugs are fixed and new functionality is added  Maintenance testing has two major parts – Testing any changes – Performing regression testing to ensure no side effects are missed  Impact analysis is the main aspect of maintenance testing – Stake holders meet to perform risk assessment and decide where to focus the regression testing efforts 80 ISTQB
81. ISTQB® Maintenance testing  Triggers – Planned changes (release cycle) – Changes of environment  New OS version  Database version upgrade – Emergency changes  Fatal errors found – Unplanned changes  Bugs and fixes found by users – Patches released to fixed vulnerabilities 81 ISTQB
82. ISTQB® Maintenance testing  Triggers – Planned changes (release cycle) – Changes of environment  New OS version  Database version upgrade – Emergency changes  Fatal errors found – Unplanned changes  Bugs and fixes found by users – Patches released to fixed vulnerabilities 82 ISTQB
83. ISTQB® Maintenance testing  Migration and retirement – When migrating to a new platform  Entire software must be tested in new platform (functional and non-functional) – If software is being retire and long data retention periods are mandated  Data archiving routines must be tested  Backup restores procedures need to be well documented and tested 83 ISTQB
84. ISTQB® Maintenance testing  Planned modification/changes – Perfective changes  Thins work well but changes introduced to improve performance or satisfy users – Adaptive changes  Adapting software to environment changes (OS, data storage, protocols, etc.) – Corrective planned modifications  Fixing of bugs that can be deferred (non fatal or mission critical) 84 ISTQB
85. ISTQB® Maintenance testing  Ad-hoc correction (DANGER! But necessary) – If an urgent ad-hoc defect arises it is not necessary to follow this structure test approach – Patch work can be done to correct the defect as soon as possible – Proper structured testing will be done later as this will be a trigger to initiate maintenance testing – Example:  Web application usage grew faster than expected and went offline 85 – Migrate to hardware with more available resources – Document it in order to trigger a maintenance test process – Structured functional/non-functional testing on new environment will be performed later and any issue that presents itself will be fixed then ISTQB
86. ISTQB® Static testing  Testing of code without executing it is called “Static testing” – Also known as Code review, technical review, etc  Software code is reviewed manually (sometimes with tools) but it is not executed  Helps verify deliverables that dynamic testing can’t help verify – SRS – Design documents – Test plan – Among others 86 ISTQB
87. ISTQB® Static testing  Powerful way of testing software early in SDLC  It is NOT a replacement for dynamic testing  All organizations must implement static testing techniques to improve software qualty 87 ISTQB
88. ISTQB® Static testing  Static vs. Dynamic – Static Verifies deliverable without execution – Dynamic verifies deliverable by executing it – Static testing finds cause of failures – Dynamic testing finds the failures – Static is known as Verification – Dynamic is known as validation 88 ISTQB
89. ISTQB® Static testing  Review technique – Evaluation to look for discrepancies from plan and recommend improvements  Informal review  Technical review  Inspection  Walkthrough – Usually performed before dynamic testing but it can also be done afterwards – The objective is informational and educational  Participants learn about products and general SDLC  Learn to plan for future work based on role – Defects are cheaper to find because they are found early in the SDLC 89 ISTQB
90. ISTQB® Static testing  Common defects found during static testing – Invalid or incomplete requirements – Unstable requirements – Incorrect software and system designs – Defective UI design – Deviations from regulations and standards 90 ISTQB
91. ISTQB® Static testing  Components usually tested statically – SRS – High/Low level design documents – UI specifications and wireframes – Software code – Test strategy – Test plans – Test cases – Guides (install, reference, user) 91 ISTQB
92. ISTQB® Static testing  Advantages – Early detection  Cheap to correct – Early feedback leads to good communication among team members – Less rework/fix work – Reduces dynamic testing efforts  By early reviews, code deployed is of higher quality – Reduces maintenance cost  Higher quality code, leads to less defects post deployment 92 ISTQB
93. ISTQB® Static testing  Reviews in detail – Early detection  Reviews vary from formal to informal  Formality depends on – Legal/regulatory requirements – Maturity of software  Formal process has 6 main steps  Informal reviews are the most commons  Informal reviews are not documented 93 ISTQB
94. ISTQB® Static testing  Reviews in detail – Formal process main steps  Planning  Kick-off  Preparation  Review meeting  Rework  Follow up 94 ISTQB
95. ISTQB® Static testing  Reviews in detail – Planning step  Starts when author submits review request to review leader/moderator  Moderator/leader schedule meeting for review  Moderator/leader ensures document is ready for review  Moderator/leader selects pages to review  Moderator/leader assigns who will play what role during review  Moderator/leader Identifies the exit criteria for review  95 ISTQB Moderator/leader schedules later stages of review
96. ISTQB® Static testing  Reviews in detail – Kick-off step  Optional step in the process  Initial meeting to ensure everyone understand what’s to be reviewed  Introduction of objectives of review, documents to be review given out  Relationship between documents to be reviewed and other documents is explained  Distribution of other materials source documents, related documents, etc.  Role assignments, checking rate, Pages to reviewed are all discussed 96 ISTQBEntry  criteria is also discussed
97. ISTQB® Static testing  Reviews in detail – Preparation step  Reviewers work individually to look for defects, doubts or discussion points  All issues recorded and given to author at end of the meeting  It is important not to exceed check rate (5 – 10 pages per hour) 97 ISTQB
98. ISTQB® Static testing  Reviews in detail – Review meeting step  Logging phase – Defects are logged one by one by author – No discussion takes place – Each defect is logged along side its perceived severity rate  Discussion phase 98 – Discussed previously logged issues – Participants discussed their reasoning for flagging defect – Moderator prevents discussion from getting personal (IMPORTANT) – Moderator ensures all defects are discussed and an action plan is created ISTQB
99. ISTQB® Static testing  Reviews in detail – Rework step  Author improves reviewed document based on feedback on meeting  Changes are reviewed on follow-up phase – Follow-up step  All changes made are reviewed  Moderator collects changed document and distributes it  Moderator collects feedback on new document 99 ISTQB
100. ISTQB® Static testing  Reviews in detail – Roles and responsibilities  All participants should have knowledge of the review process  A moderator is not a must, however reviews are more effective when one is present  Main roles – Moderator – Author – Scribe (Recorder) – Reviewers – Manager 100 ISTQB
101. ISTQB® Static testing  Reviews in detail – Roles and responsibilities  Moderator – AKA review leader because he/she leads the process – In cooperation with the author moderator decides composition of team – Performs entry check and follow up after review – Schedule meeting – Circulates documents before meeting – Coaches other team members – Leads discussion and collects data 101 ISTQB
102. ISTQB® Static testing  Reviews in detail – Roles and responsibilities  Author – Responsible for the document to be reviewed – Main responsibility is to understand the document and its issues/defects – Learn how to improve document  Scribe – AKA recorder – Records each defect and suggestions on how to improve it – Author can play this role to help understand comments better during rework – Having someone else can be good because it makes author think harder 102 ISTQB
103. ISTQB® Static testing  Reviews in detail – Roles and responsibilities  Reviewers – Check documents for defects – Should include professionals with a background that matches the type of review – Should represent different perspective and roles  Manager – Decides execution of review – Finds time and resources within the project – Can also play a role in the review meetings 103 ISTQB
104. ISTQB® Static testing  Reviews in detail – Types  Walkthrough  Technical review  Inspection 104 ISTQB
105. ISTQB® Static testing  Reviews in detail – Types  Walkthrough – In detail presentation of document to established understanding – Lead by the author of the document – Author does all preparations – Participants are from different groups and departments (not need to know much about the document) – Effective for high-level documents (SRS, architectural documents, etc) – Examines validity of propose solution 105 ISTQB
106. ISTQB® Static testing  Reviews in detail – Types  Technical review – Achieving consensus on technical content of document – Less formal than inspections – Defects found by experts (architects, chief designers) – Main goal is defect detection – Peer review without management participation – Lead by moderator 106 ISTQB
107. ISTQB® Static testing  Reviews in detail – Types  Inspection – Most formal type of review – Document check in depths by reviewers before meeting – Lead by moderator (not author) – Defined roles during review process – Peers look for defects – Based on rules with entry and exit criteria – Metrics gathered and analyzed to improve process – Main goal is to improve quality of document and learn from defects 107 ISTQB
108. ISTQB® Static testing  Reviews in detail – What makes a review successful  “Find a champion” – It should lead by a knowledgeable enthusiastic person with support from management  “Choose the right thing” – Review most important documents – Do not review every single document – Make sure each reviewer has a clear objective – Find the right people to perform review 108 ISTQB
109. ISTQB® Static testing  Reviews in detail – What makes a review successful  “Plan, plan and plan” – Time spent on reviews should be part of the timeline for the project – People should be encouraged to track hours spent on reviews  “Train to review” – Provide training on review techniques to participants – Provide specialize training to moderator  “Don’t get personal” – People/Psychological issues should be managed properly – Reviews SHOULD NOT get personal 109 ISTQB
110. ISTQB® Static testing  Reviews in detail – What makes a review successful  “KISS” (Keep it simple stupid) – Make process as formal as possible but keep it simple – Do not get too detailed or too theorical  “Get better at it” – Always learn from the process and apply the learning  “Report back” – Report results to people involved – Discuss consequences of defects if not found 110 ISTQB
111. ISTQB® Static testing  Reviews in detail – What makes a review successful  “KISS” (Keep it simple stupid) – Make process as formal as possible but keep it simple – Do not get too detailed or too theorical  “Get better at it” – Always learn from the process and apply the learning  “Report back” – Report results to people involved – Discuss consequences of defects if not found 111 ISTQB
112. ISTQB® Static Analysis  Analysis of SRS, design documents and software code before the software code is executed  Main goal is to find defects before starting to code or before executing the code  Looking for defects rather than failures 112 ISTQB
113. ISTQB® Static Analysis  Tools – Mostly used by developers during integration and unit testing – Tools provide details about coding standards  Nested depth  Cyclomatic complexity  General standards for language used – Compiler or IDE is also a tool – Code analyzer tools – Helps find defects that are hard to find by dynamic testing 113 ISTQB
114. ISTQB® Static Analysis  Most common type of defects found in static analysis – Unused variables – Unreachable code – Security vulnerabilities – Coding standard violations – Syntax issues 114 ISTQB
115. ISTQB® Static Analysis  Benefits – Code is never executed, no permanent damage if wrong – Finds defects not found by dynamic testing – Tools show warnings for structure and other code issues – Improves code maintenability 115 ISTQB
116. ISTQB® Static Analysis  Tools features – Coding standards  Programing rules (warnings for unused variables, unreachable code)  Naming conventions  Adhering to coding standard saves effort and makes it easier to maintain – Code metrics  Calculate structural attributes of code (depth, complexity, # of line of code)  Helps highlight if software is becoming bigger and complex  Helps decide design alternative when redesigning the code – Cyclomatic complexity  Number of decision in the program 116  It gives information on the complexity of the code and how much ISTQB testing is required
117. ISTQB® Static Analysis  Tools features – Cyclomatic complexity  Two main ways of calculating it: – Number of binary decisions (If, while, for, when, etc) + 1 – Number of edges – numer of nodes + 2 – Code structure  Control flow structure – Sequence on which instructions are executed – Identifies dead code – No. of nested levels, cyclomatic complexity, etc. relate to control flow 117 ISTQB
118. ISTQB® Static Analysis  Tools features – Code structure  Data flow structure – Trail of data as it moves through the program and how the program alters it – Common defects found » Referencing a variable with not value in it » Unused variables  Data structure – Refers to data independent of the program – Refers to algorithms for creating, modifying and deleting data – Sometimes program is complex because of data structure only 118 ISTQB
119. ISTQB® Test design tecniques  Test development process – Design techniques  Test development process  Categories of test design techniques  Black box techniques  White box techniques  Experienced based techniques  Choosing the right technique 119 ISTQB
120. ISTQB® Test design tecniques  Test development process – Design techniques  Test development process – Important to know what you are testing (context) – Know inputs and its expected outputs – Includes » Test conditions (Documented in test design specifications) » Test cases (Documented in test case specifications) » Test procedures (Documented in test procedure documents) – 120 ISTQB Formality of documents could varied from very informal (no documents) to very formal (extensive documentation) depending on the criticality of the application
121. ISTQB® Test design tecniques  Test development process – Design techniques  Test development process – It consists of three main phases » Test analysis » Test designs » Test implementation 121 ISTQB
122. ISTQB® Categories of test design techniques  Specification based (black box) – This is a dynamic testing technique – Input-output driven without concern for the internal structure  If Output= Expected output test passes – Tester is concerned on what the software does instead of how he does it – You can test functional and non-functional aspects  Structured base (white box) – Also a dynamic testing technique – Uses the internal structure of the code to design test cases – Requires knowledge of the internal code – It test the flow of decisions and how those decision are made 122 ISTQB
123. ISTQB® Categories of test design techniques  Experience based – Collective knowledge of developers and testers are used to design testing cases – Both technical and business experienced is used – It uses that experienced to know where issues/defects might arise  Where/When to use each technique – Black box  Component testing through acceptance testing  Requirement docs/ design docs – White box  Component testing through acceptance testing – Experience based 123 ISTQB  Complement white/black box testing
124. ISTQB® Categories of test design techniques – Experience based  Useful when there is no documentation  If there are extreme time constraints  Used for less risky applications 124 ISTQB
125. ISTQB® Specification based testing techniques (black box) – Equivalence partitioning  Can be used on all levels of testing  Consists on grouping test cases together into partitions treated the same by the software package  A value is tested in each partition, if the values passes the test, the entire partition passed the test – The law of ones in process auditing world  This might not always be true. It is recommended that testers randomly test more cases inside a partition to ensure the partion was defined properly.  Also known as Equivalence Class 125 ISTQB
126. ISTQB® Specification based testing techniques (black box) – Equivalence partitioning example  A store offers 3 levels of discount: – > $20 to $50 => 5% discount – >$50 to $100 => 10% discount – > $100 => 15% discount  How do we test this? – We either test multiple values from $0 to $101 – Or we select values that fit the criteria (partition) -1.35 126 ISTQB 20.01 55 115 12.20
127. ISTQB® Specification based testing techniques (black box) – Boundary value analysis  Testing values around the edges/boundary between the partitions  Black box testing technique  To apply it we must get the value of the edges of the partition and use the next one as a value to test  Testing only boundaries is not enough. Values inside the boundaries must also be done  Partitions should be tested separately from BVA 127 ISTQB
128. ISTQB® Decision table testing (Black box) – Different combinations of input and corresponding outputs – Very efficient when testing complex business rules – To create a good decision table, first identify the section of code that reacts according to the combinations of input – Do not deal with a large number of combinations/outputs at once, break them up – Once all conditions defined, create a table to map them out 128 ISTQB
129. ISTQB® Decision table testing (Black box) 129 ISTQB
130. ISTQB® State transition testing (Black box) – What is state  Position or situation a system is at a particular time – What is transition  The process in which a system moves from one state to another – Systems move from one state to the next based on inputs – Do not deal with a large number of combinations/outputs at once, break them up – Mapping changes in state and their transitions is the basis of state transition testing 130 ISTQB
131. ISTQB® State transition testing (Black box) – Example  Let’s say you have $600 in your bank account  You go to an ATM and withdraw $500  Later in the day you go to another ATM and try to withdraw $500 again  You get an error because of insufficient funds  The state of the system went from dispensing money to not having sufficient funds 131 ISTQB
132. ISTQB® State transition testing (Black box) – Main parts of a transition model  State the software occupies (having/not having funds)  Transitions from one state to another  Events that cause the transition (withdrawing money)  The action that results from a transition (either giving out money or giving an error message because of insufficient funds) – It is important to note that each even CAN ONLY cause one action  The same event in a different state can cause a different action – Even t=> withdrawal of $500 <> State => $600 in account <> action => money – Event => withdrawal of $500 <> State => $100 in account <> action => error 132 ISTQB
133. ISTQB® Use case testing (Black box) – Use case is the description of a system by the end user of that system – Use cases are a sequence of steps that describes the interaction between the user and the system  It describes the interaction of the end user with the system to achieve an specific task – This technique helps us exercise the system on a transaction by transaction basis from start to finish – Use cases describe what the user does and sees rather than what the system does and what input it takes – Use cases need to have preconditions necessary for them to work as well as observable results and a description of the final state of the system 133 ISTQB
134. ISTQB® Use case testing (Black box) – Benefits  Capture functional requirements from the perspective of the user  It requires involvement from end users and stakeholders early in the SDLC  Serves as the foundation to develop system test cases 134 ISTQB
135. ISTQB® Structured based (White box) – Test coverage  Test coverage is the degree expressed as percentage to which a specified coverage item has been exercised by test suite  Coverage = (Number of coverage items exercised/Total number of coverage items)*100  100% coverage does not mean 100% tested because coverage techniques measure only one dimension of multiple dimensions 135 ISTQB
136. ISTQB® Structured based (White box) – Test coverage  Type of coverage – EP: Percentage of Equivalence partitions exercised – BVA: Percentage of boundaries exercised – Decision tables: Percentage of business rules exercised – State transition table: Percentage of states visited, percentage of valid and invalid transitions exercised 136 ISTQB
137. ISTQB® Structured based (White box) – Test coverage  How to measure? – Decide item to be counted – Count the structural elements – Instrument the code – Run the test for which coverage measure is required – Using the output determine the percentage of items exercise 137 ISTQB
138. ISTQB® Structured based (White box) – Statement coverage  Also known as line coverage  Statement Coverage=(Number of statements exercised/Total number of statements)*100  Black box testing only achieves a coverage of up to 75%  Let’s design a test with 100% statement coverage for this routine: READ X READ Y IF X>Y PRINT “X is greater than Y” ENDIF 138 ISTQB
139. ISTQB® Structured based (White box) – Statement coverage  100% coverage can be achieved by only one test. – Having the value of X be greater than the value of Y READ X READ Y IF X>Y PRINT “X is greater than Y” ENDIF 139 ISTQB
140. ISTQB® Structured based (White box) – Statement coverage  100% coverage can be achieved by only one test. – Having the value of X be greater than the value of Y READ X READ Y IF X>Y PRINT “X is greater than Y” ENDIF 140 ISTQB
141. ISTQB® Structured based (White box) – Decision coverage  Whenever there are two or more possible exits from the statement like an IF statement, a DO-WHILE or a CASE statement it is known as decision because in all these statements there are two outcomes, either TRUE or FALSE.  Both outcomes must be exercise  Decision Coverage=(Number of decision outcomes executed/Total number of decision outcomes)*100%  Functional testing only covers 40% to 60% of decision coverage  Decision coverage is a stronger type of test (compare to statement coverage) and requires additional test cases  Also known as branch coverage  Decision coverage can’t test 100% of the code 141 ISTQB
142. ISTQB® Structured based (White box) – Decision coverage READ X READ Y IF “X > Y” PRINT X is greater that Y ENDIF  X > Y gives you 100% statement coverage but not 100% decision coverage  To obtain 100% decision coverage, the false condition of the if has to be tested 142 ISTQB
143. ISTQB® Experienced based (White box) – Testing should be rigorous but experience should not be ignored – A good “bug hunter” can find defects based on his/her experience that are hard to find using systematic testing – Types of experience based testing:  Error guessing – Technique where tester relies on previous experience to find defects based solely on patters, techniques, tech stacks seem before – Not a replacement for systematic testing techniques – There are no rules or methodology, just skills and intuition – Success of technique depends on previous tester experience 143 ISTQB
144. ISTQB® Experienced based (White box)  Error guessing – Examples » Division by 0 » Submitting an empty form » Entering wrong data in input fields » Null handling » Entering reserved (&@) characters in web forms » Entering quotes (‘ , “) in input fields » DOB in the future – 144 ISTQB Rule of thumb: if developer says “it will never happen” it should be tested using experienced based techniques
145. ISTQB® Experienced based (White box)  Exploratory testing – Done by very skilled testers – Little documentation and requirement gathering and a lot more code execution and testing – Tester gets very familiar on how the software code works and starts running it under different scenarios without actually creating much documentation – Use if requirements are incomplete or timelines are very short – It helps stablished more confidence in software – Good at getting rapid feedback – It is not scripted or structure – Relies heavily on tester skills and experienced 145 ISTQB
146. ISTQB® Choosing a technique  There is not best or worse – Some might be better fit for a particular software package than others  Always choose multiple techniques  Choice depends on many factors: – Type of system – Regulatory standards – Customer requirements – Level and type of risks – Test objective – Knowledge of testers – Documentation available – Time and budget 146 ISTQB – Previous experience of types of defects found
147. ISTQB® Choosing a technique  Structure based techniques can find issues with software code  If problems with specifications only black box techniques will find them  If issues with code and specifications exists, only experience will find them  Internal factors to choose technique – Models used – Testers knowledge/experience – Likely defects – Test objective – Documentation – Life cycle model 147 ISTQB
148. ISTQB® Choosing a technique • How to organize testers and the testing Test Organisation Test Planning and Estimation • How to do test estimation, planning and strategy for test effort Test Progress Monitoring and Control • This addresses the testing progress, reporting and control Configuration Management • Relationship of configuration management with testing Risk and Testing • How testing is affected by product and project risks Incident Management • Defect management and other incident management which require further investigation 148 ISTQB
149. ISTQB® Test organization is about organizing the test team and the testing Independence is not a condition, its a continuum. At one end of continuum lies no independence where developers themselves perform testing As you move towards independence, a group of testers work alongside with developers and report to development manager Another team of testers can be more independent and outside development team which reports to project management Near the other end of continuum lies complete independence, test team reports to a point equal to development team Independent test team typically comprises of test manager, test lead and testers and brings great value to testing 149 ISTQB
150. ISTQB®Different Levels of Test Independenc Developers doing testing themselves Less Independence Testers working alongside with developers and report development manager Test team outside the development team and reporting to project manager Test teams with Specialist Skills like business domain, database, performance testers, automation testers etc. Test teams from an external organization 150 ISTQB More Independence
151. ISTQB®Advantages of Test Independence It is seen that if you are reviewing your own work its difficult to find defects in your own work Person other than developer will be able to find more defects Independent tester brings a skeptical attitude of professional pessimism, if they have doubt in system behavior they ask, Is it a defect? Independent testers provide unbiased view on the software issues and so find more defects Independent testing is very important for testing complex and safety critical applications 151 ISTQB
152. Disadvantages of Test Independence ISTQB® Testers and test team could be isolated from the developers, designers and project team Leads to communication problems, feeling of alienation and antipathy Blame games and political backstabbing can start Due to independence developers may loose the sense of responsibility for quality 152 ISTQB
153. Working ISTQB® Tasks perform ed by Test Lead 153 ISTQB as a Test Leader • Involved in planning, monitoring and control of testing activities • Formulate test strategy and test plan in collaboration with stakeholders • Estimate the testing required for the project and negotiate for resources with management • Lead, guide, monitor the analysis, design, implementation and execution of the test cases, test suites • Schedule the test execution and monitor the test execution progress and reporting • During test execution test lead makes sure test environment is in place and continuously managed during execution • They adapt test planning based on test results and progress and take control measures in case of any issues
154. Working as a Test Leader cont. ISTQB® Tasks perform ed by Test Lead 154 ISTQB • Ensure proper testware produced and traceability of test case with test basis • Test lead introduces suitable metrics for measuring progress & evaluating the quality of the testing • Recognize when automation is appropriate to start • If automation needs to be done, they select automation tools and organize any training in that tool if required • Decide about the implementation of the automation test environment • Prepare test status and summary reports
155. Working as a Tester ISTQB® Task s of a Test er 155 ISTQB • Testers review and contribute to test planning during test planning and preparation phases • Analyse, review and assess software requirements specifications and design documents • Identify test conditions, create test cases, test data and may also automate test cases • Testers set up the test environment or help system admin to prepare test environment • Testers execute and log tests, evaluate the results and document any test failures • Testers use defect management, test management and test monitoring tools as required • Testers log defects in defect management tool for any test failures during test execution • Testers also measure performance of component or system if required(Performance testing) • Testers do peer review of tests cases, defect reports, test results developed by other testers
156. ISTQB® Skills needed by Testers Good test teams should have the right mix of skills based on the tasks and activities they need to perform Ability to prepare and deliver written and verbal reports Ability to communicate effectively Application or business domain • Tester should understand the intended behaviour of the application • The problem that the software will solve and process it will automate • Above business domain understanding helps tester to figure out any incorrect behaviour of software Technology • Tester must be aware of issues, limitations and capabilities of chosen technology • Technical understanding helps tester to figure out any problems with Testing system • Should have good understanding of testing concepts discussed in this course 156 ISTQB
157. ISTQB®Test Planning and Estimation • Test Planning • Test Estimation • Test Approaches or Strategies 157 ISTQB
158. ISTQB® Purpose of Test Planning Test plan is the project plan for testing work to be done in project Test plan guides our thinking Test plan forces us to confront the challenges that await us and focus our thinking on important topics Test plan serves as the vehicle for communication with other team members and stakeholders Test plan helps to manage change 158 ISTQB
159. ISTQB®IEEE 829 Standard Test Plan Templa • Test-plan identifier • Test deliverables • Introduction • Testing tasks • Test items • Environmental needs • Features to be tested • Responsibilities • Features not to be tested • Staffing and training needs • Approach • Schedule • Item pass/fail criteria • Risks and contingencies • Suspension criteria and resumption requirements 159 ISTQB • Approvals
160. ISTQB® Test Planning Hierarchy • Master Test Plan – High level plan for the project Master Test Plan Functional Test Plan 160 ISTQB System Test Plan UAT Test Plan • Phase Test Plan – Individual Test Plans for each phase of testing
161. ISTQB® Activities of test Test planning • Determine what is in scope and out of plannin testing scope the test objectives g tasks •• Determine Determining project and product risks that you • Constraints which may affect testing (Resources, budget, time etc.) need to • Most critical things to consider for the product or project carry • Overall testing Approach • Integration and coordination of testing out activities during • Assigning resources and Test Scheduling test • Test deliverables to be produced logging, Change and plannin • Defect Configuration Processes g are as • Determining entry and exit criteria follows: 161 ISTQB
162. Factors ISTQB® for determining entry/exit criteria Acquisition and supply • Availability of resources (Testers, software, hardware) Test items • The state in which test item should be before starting/ending test execution Defects/ Bugs 162 ISTQB • Total defects found/remaining/defect detection rate/defects resolved
163. ISTQB®Factors for determining entry/exit criteria Test Cases • Total test cases executed, total passed/failed/blocked/skipp ed etc. Covera ge • Percentage of test basis covered by testing/code coverage etc. Quality • Status of important quality characteristics of software 163 ISTQB
164. Factors ISTQB® for determining entry/exit criteria cont. Money/ Budget • Cost of finding defects in current execution or after in production Risks • Any undesirable outcomes – shipped with some untested features or loss in market share if shipped too late 164 ISTQB
165. Entry and Exit Criteria The entry criteria helps you to decide when can you start the testing for a particular testing phase. Functional Testing The exit criteria helps you decide when to stop the testing for a particular phase The Exit Criteria from one stage forms part of the Entry Criteria into the next testing phase Entry/exit criteria are the true Quality Checks of the actual software testing System Testing User Acceptance Testing
166. Entry Criteria Typical Entry Criteria for a testing phase may consist of: www.softwaretestingmentor.com • Build verification test passed – Stable build • Availability of required test data and test environment, resources etc. • All required test documents completed and signed off
167. Exit Criteria Typical exit criteria for a test phase may include factors like: • Test coverage has been attained • No outstanding defects (Severity 1 & Severity 2) • Cost and time (Time to market) constraints • No critical residual risks
168. Test Estimation Testing is often a subproject within the large project You should start with work breakdown structure that identifies stages, activities and tasks First breakdown the testing project into phases using the fundamental test process Planning and control Analysis and design Implementation and execution Evaluating exit criteria and reporting Test closure Identify activities within each phase and then identify tasks and subtasks Now estimate how long these tasks and subtasks will take to finish • • • • •
169. Estimation Techniques There are 2 • Consultative estimati approach – Taking on inputs from people techniqu who will do task and domain experts es covered • Metrics Based Analyzing metrics in ISTQB from the past foundati on level www.softwaretestingmentor.com
170. Consultative approach Individual contributors and experts prepare the work breakdown structure for the project After that team works together to understand effort, duration, dependencies and resource requirement This is a bottom up approach because you start with lowest of work breakdown structure - Task This is mostly followed previous metrics about project are not available Disadvantage is that you have to rely on estimation done by the task owner or an expert www.softwaretestingmentor.com
171. Metrics based approach In this approach metric from similar previous projects are used for estimation The simplest approach for this approach is to take developer – tester ratio as we had in similar past projects More reliable approach is classify the project in terms of size and complexity and then compare how long similar project took in past Average time required to execute 1 test case in past and estimating the total effort Other sophisticated approaches can also be applied • Build mathematical models to compare key parameters from past projects and then estimating effort for current tasks
172. Factors affecting test effort Product • Sufficient product documentation • Complexity of the project • Size of the project Process • Availability of test tools • Availability of test and development environment • Process maturity in organization • People factors : Team skills, relationships • Time Pressures Test Results • Defects found during test execution • Defects failing re-testing • Rework required due to changing requirements
173. Test Approaches or Strategies Choosing the right test strategy is very important for success of the test project Major types of test strategies that are commonl y used are: • • • • • • • Analytical Model Based Methodical Process or Standard Compliant Dynamic Consultative or Directed Regression Averse
174. Test Approaches or Strategies Cont. Analyti cal • In analytical approach analysis of the risk or specification documents form the basis for test design • Risk based test strategy • Requirements based test strategy Model Based • Test is based on some defined model for example mathematical model to upload data on servers • If the system conforms the defined model then system is assumed to be working
175. Test Approaches or Strategies Cont. Methodi cal • Adhere to pre planned and systemized approach that have been defined in house based on prior experience of testing the application • Uses checklists which suggests major areas for testing • Might also follow industry standards Process or Standard Complia nt • Follow the standard for your testing for example IEEE 829 standard • Rely on the externally developed standard approach of testing • Can follow well defined standards such as V-Model or Agile development
176. Test Approaches or Strategies Cont. Dynamic Consultat ive or Directed • Uses lightweight set of testing guidelines which address weaknesses in software • Focus is to find as many defects as you can in test cycle • Exploratory testing technique is one technique used in Dynamic approach • In this approach testing is based on the guidance from developers/technology experts and domain experts
177. Test Approaches or Strategies Cont. Regress ion Averse • Regression averse strategy have the automated set of regression tests which find any regression defects • Tester tries to automate most of the tests of system functionality to ensure nothing has broken with any changes in software
178. Selecting the Right Test Strategy Some of the factors to consider while selecting Test Approach are: Risk Skills Objectives • For established software which is evolving slowly regression averse strategy is right approach • For new software risk based approach is best fit • Skills available in test team • Cannot pick regression averse if no automation skillset is present in team • Testing must satisfy the needs of stakeholders • If focus is to find more and more defects then dynamic strategy makes sense
179. Selecting the Right Test Strategy Cont. Regulatio ns • If Regulatory requirements need to be met then methodical test strategy that satisfies the regulations is fit Product • If good and extensive product documentation is available then requirements based analytical strategy is good fit Business • Business consideration are also important in choosing test strategy • If an existing system can be used to model new system then model based approach should be used
180. Test Progress Monitoring and Control Learn about techniques and metrics commonly used for monitoring test preparation and execution We will also learn about test reporting using test metrics The main topics covered in this session are: • Monitoring the progress of test activities • Reporting test status • Test Control
181. Monitoring the progress of test activities After defining test strategy and plan, once we start the test execution we should track our testing work Test Monitoring is a test management task which tracks the test progress and keeps an eye on how testing is progressing. Reports are periodically prepared that compare the actual result with the planned Test progress monitoring can be done based on different metrics like tests executed/pass/fail, defects opened/closed/in progress etc. Test progress monitoring technique varies depending on the preferences of tester and stakeholders, needs and goals of project, regulatory requirements etc.
182. Purpose of Test Monitoring Provide feedback to test team and test manager Provide visibility to project team about test results Measure the status of test execution against the exit criteria defined in test plan Gathering data for use in future test estimations
183. Test Progress Monitoring Metrics Commo n metrics used for Test progress monitori ng are: • • • • • • • • • • Total test cases prepared How many tests have been run? Number of tests passed or failed Total number of incidents raised in test cycle Total number of incidents fixed Planned and actual effort Percentage of Test environment completed The extent of Test Coverage achieved in terms of requirements, risks, code etc. Status of testing (Test Analysis, Test Design and Test Implementation) Subjective level of Confidence testers have on the product
184. Reporting test status Reporting test status is about effectively communicating test monitoring findings to other project stakeholders Test status reports help project stakeholders to understand results of test cycle and ensure if exit criteria was met It also helps stakeholders to decide the project release decisions IEEE 829 standard Test Summary Report Template includes: • • • • • • • • Test summary report identifier Summary Variances Comprehensive assessment Summary of results Evaluation Summary of activities Approval
185. Example: Risk coverage by defects and tests In case of risk based testing major criteria for test reporting is to subject the important product risks with appropriate extent of testing Tests to be run Outstanding defects Product Risk Areas Planne Actual d % Number % Functionality 220 150 32 45 24 Performance 12 12 0 5 34 Security 22 15 13 7 12 Interfaces 23 16 30 12 43 Compatibility 34 18 47 12 50
186. Test Control Test control is about bringing the project under control in case of any diversions It is a test management task in which you apply corrective actions to get the test project on track Examples of test control activities: • Rescheduling testing to some other time slot (Performance testing during low peak time) • In case lot of fixed defects fail re-testing in test environment, taking measures so that developers test their fixes thoroughly before releasing defect in test • Re-prioritising test execution of features which are available in case expected software feature for current cycle is delivered late • In case release date cannot be moved and lot of tests need to be executed then getting more resources to get testing done
187. Configuration Management Software Configuration Management(SCM) is the discipline for systematically controlling the changes in software and supporting documents during SDLC • For Example: Test Cases, Test Plan, Design Documents, SRS etc.) As per • SCM is the process of identifying and IEEE defining the items in the system, controlling Software the changes of these items throughout their Configura life cycle, recording and reporting the status tion of items and change requests, and verifying Managem the completeness and correctness of items. ent is:
188. Features of SCM Tools Software Configuration Management is the process of tracking and controlling the software changes. The basic features provided by any SCM t ools are: • Concurrency Management • Version Control • Synchronization
189. Concurrency Management When two or more tasks are happening at same time it is known as concurrent operation. Concurrency in context to SCM means that the same file being edited by multiple persons at the same time. If concurrency is not managed properly with SCM tools then it may lead to very severe problems Let us take an example to explain this: • Suppose you have a central repository to store development resources and multiple developers are working on same features, so there might be a possibility that 2 or more developers are modifying the same file at same time. The scenario in this condition will be something like this. 1. User 1 opens a file test.java from common repository 2. User 2 also opens a file test.java from common repository 3. User 1 does some changes and saves the file in common repository 4. User 2 does some changes and saves the file in common repository which overwrites the previous changes by user1. So, to avoid this situation concurrency management is needed in which allows multiple users to checkout the files and make changes. After doing changes when user again checks in the file the SCM system runs the algorithm to merge changes of multiple users.
190. Version Control SCM tool uses archiving method or saves every change made to file Because of archiving or save feature it is possible for use to roll back to previous version in case of any problems
191. Synchronization User is allowed to checkout more than one files or entire copy of repository. User then works on the required files and checks in the changes back to repository They can update/synchronize there local copy periodically to stay updated with the changes made by other team members Besides these features SCM tools provide lot more functionality like build management, auditing, reporting system etc.
192. Implications of SCM for Testing It allows testers to manage testware and test results using same configuration management mechanism as used for source code Build process supported by configuration management is a reliable way of delivering builds in test environment It also helps us to map what is tested against which build
193. Risks and levels of risk Risk is the possibility of a negative or undesirable outcome Risk has the likelihood between 0% and 100%, it is something which may happen in future The likelihood of risk becoming an outcome is one factor to consider when prioritizing the risk. More likely the outcome, the worse the risk Risks can be classified as product risks and project risks
194. Product risks Possibility that the system/software might fail to satisfy the users expectation is known as product risk Product risks are sometimes also referred as quality risks as they are the risks related to quality of the software or product Unsatisfactory software might not fulfill end user needs Non functional product risks can be like security, reliability, usability maintainability or performance of software
195. Risk Based Testing In risk based testing we organize our testing efforts in such fashion that it reduces the level of product risk at the time of shipment Risk based testing uses risk to prioritize the appropriate test cases during the project It starts early in the project cycle The risks to system quality are identified and that knowledge is used in the test planning, preparation and execution Risk based testing involves both mitigation and contingency
196. Mitigation and Contingency Mitigation is done to reduce the likelihood of defects Contingency: In case if the risk becomes an outcome there should be a plan to reduce the risk impact
197. Techniques for Risk Based Testing Risk based testing starts with product risk analysis, some techniques for risk analysis are: • Reading the requirements, design docs thoroughly and closely • Brainstorming with many project stakeholders • Small group or one-on-one sessions with business and technology experts in organization In order to avoid the missing things its always a good idea to have a checklist of functional/Non-functional areas which you should consider for risk analysis. • Some of them can be like functionality, localization, usability, reliability, performance and supportability.
198. Risk Analysis Template Product Risk Category 1 Risk 1 Risk 2 Category 2 Risk 1 Risk 2 Likelihood Impact Priority Mitigation
199. Project Risks Some common project risks for testing are as follows Test items not getting installed in test environment • Mitigated through smoke testing prior to starting testing phase Incomplete or unrealistic test environment • This can lead to misleading test results • Outsourcing can be done, for example performance testing Major change in the software • Mitigated by good change control process, robust test design and light weight test documentation Organisational issues • Shortage of staff • Shortage of skills/training • Problems with communicating and responding test results Technical problems Ambiguous or unprioritized requirements Excessive requirements High system complexity Quality problem with design, code or tests
200. Risk Management The process of identifying the risk (Product risk or Project risk), analyzing the risk and then mitigating the risk or controlling the risk is known as Risk Management. Risk managem • Risk Identification ent • Risk Analysis includes three • Risk Mitigation or Risk Control main activities. Risk Managem • Assess what can go wrong in system ent or software activities • Which risks are important to deal with provide a disciplined • Implement action plan to deal with approach those risks to:
201. Risk Identification Risk identification is the first step in risk management. We need to identify both project and product risk by using certain techniques. Some of the most common techniques which can be applied to identify different risks are using risk templates, interviewing the stakeholders, project retrospectives etc.
202. Risk Analysis Risk analysis is the next step of risk management. In risk analysis you study the risks identified is the identification phase and assign the level of risk to each item. You first need to categorize the risks and then need to determine the level of risk by specifying likelihood and impact of the risk.
203. Risk Mitigation or Risk Control The third step in the risk management is risk mitigation or risk control. After assessing the risk in your project you must control them. You can use options like mitigation, contingency to control the risks. • Mitigate: Take steps in advance to reduce the likelihood and impact of risk. • Contingency: Prepare a plan to reduce the impact should the risk become an outcome. • Transfer: Transfer risk to other member of the team or project stakeholder to reduce the likelihood or accept the impact of the risk. • Ignore: Do nothing about the risk, only advisable if the likelihood and impact are low
204. What are Incidents? An incident is any situation where the system exhibits questionable behavior An incident is any event occurring where actual results vary from expected results Any inconsistency between the Actual and Expected results caused by: • Test environment issue • Issue with developer code • Issues with test data • Issues with hardware • Invalid expected results • Tester mistakes An incident is a defect/bug only when the root cause of that incident is some problem with the item being tested
205. What are Incident Reports? Incident report contains a description of the questionable behavior It helps to have clear goals in mind when writing It provides information about the incidents to team members It helps in analysis of the incident data Incident report analysis data eventually helps to improve the test process
206. How to write good Incident Reports? Always be attentive while running the tests so that you do not miss any incident Try to reproduce intermittent issues and add as much information as you can related to intermittent issues Try to isolate the issue by changing the steps used to reproduce Mention the impact of issues in the incident report Use clear and unambiguous, neutral language Keep the reports concise It is recommended that all reports are reviewed by lead tester or experienced tester
207. Defect Detection Percentage (DDP) Defect detection percentage compares field defects with test defects It is very helpful metric to find the effectiveness of test process DDP formula • DDP=defect(testers)/defect(testers) +defect(field)
208. What goes in Incident Report? An incident report may include: • • • • • • • • Summary of the incident Steps to reproduce Expected and Actual results Software version in which incident was found Phase of the project where incident was found Test case that produced incident Reference to other documents Impact of incident
209. IEEE 829 STANDARD: TEST INCIDENT REPORT TEMPLATE Test incident report identifier Summary Incident description (inputs, expected, results, actual results, anomalies, date and time, procedure step, environment, attempts to repeat, testers and observers) Impact
210. Incident/Defect Lifecycle
211. Why tool support is required in Testing? Software testing is time consuming and tedious activity Many time you might need to do repetitive tests (Same tests executed for future builds) Tools help to Automate repetitive tasks and make regression testing easier Tools help to do Test and Defect management which in turn helps to measure software quality
212. Test Tool Classification Tools are grouped by the testing activities or areas that are supported by a set of tools Test tools can be classifie d in 4 major types • Single Activity Tools which provide very specific and limited functionality are called point solution or Single Activity tool like Defect tracking tools, Configuration Management tool • Multi Activity Tools which provide multiple functionality are known as Multi Activity tools like Test Management Tools (Contains built in defect management) • Intrusive The tools which can affect the test outcome like Automation Tools, Performance Tools, Code coverage tools • Non Intrusive The tools which do not affect the outcome of testing like Test management, defect management tools.
213. Types of Test Tools Tools for Management of testing and tests • • • • Test management tools Requirements management tools Incident management tools Configuration management tools Tool support for static testing • Review process support tools • Static analysis tools (D) • Modeling tools (D) Tool support for test specification • Test design tools • Test data preparation tools
214. Types of Test Tools Cont. Tool support for test execution and logging • • • • • Test execution tools Test harness/unit test framework tools (D) Test comparators Coverage measurement tools (D) Security tools Tool support for performance and monitoring • Dynamic analysis tools (D) • Monitoring tools Tools support for specific application areas Tool support using other tools
215. Tools for Management of Test management is either “Management of tests” or “Management of and tests testtesting process” The tools which provide support to one or both features above fall in this category Management tools are used throughout the testing lifecycle. Management tools are most often used by specialist testers or test managers. Some tools in this category are: • • • • Test Management Tools Requirements Management Tools Incident Management Tools Configuration Management Tools
216. Test Management Tools Features • Management of tests (i.e. Number of tests planned, keeping track of Test Data, number of tests run, passed, failed etc.) • Test scheduling • Management of test activities (Time spent on planning, design, execution etc.) • Interfaces to other tools like defect tracking tools, requirement management tools, configuration management tools etc. • Support for traceability of test cases, test results and defect to source documents, such as requirement specifications. • Logging of test results • preparation of progress reports and doing quantitative analysis such as “Test run and tests passed”, defects raised, fixed and outstanding When used most • Test management tools are used throughout the software testing life cycle Who uses most • Testers • Test Lead • Test Manager
217. Requirements Management Tools Features • Storing requirements statements • Checking consistency of requirements • Identifying the missing, undefined or ambiguous requirements • Providing traceability of requirements to test cases • Functionality to prioritize the requirements • Providing Coverage of Requirements by documented test casesused most When • During requirements gathering phase Who uses most • Business analysts • Testers
218. Incident Management Tools Incident management tool are also known as defect management, bug tracking or bug management tool Better name among these is “incident management tool” as not all incidents raised for software under test are defects(Can be environment issue, failure due to incorrect data setup, enhancements etc.) Features • Storing information about incident(defect, failures etc.) attributes(e.g. priority, severity) • Provide ability to attach files • Providing ability to assign incidents to people • Ability to change the incident status (Open, In development, Ready for test, deferred etc.) • Provide audit trail for incidents When used statistics/metrics most • Provide about incidents • Used throughout the SDLC Who uses most • Testers • Business analysts • Developers • Managers and other stakeholders
219. Configuration Management Tools Features • It stores information about build and testware versions • Provide traceability between software and testware • Keeps track of different configurations(OS, Backend software versions, browsers etc.) for different software versions • Enable traceability between testware and software work products and product variants • Build and release management • Access control (Checking in and Checking out) • Provide audit trail • This is not Strictly a testing tool but is very critical for controlled testing When used most • Used throughout the SDLC Who uses most • Developers • Testers • Project Managers
220. Tools support for Static Testing Some tools for supporti ng static testing are: • Review process support tools • Static Analysis Tools(D) • Modelling Tools(D)
221. Review process support tools Features • A common reference for the review process • Storing and sorting review comments • Communicating comments to relevant people • Coordinating online reviews • Tracking review comments, defects found and providing reports about them • Providing traceability between comments and documents reviewed and related documents • Monitoring the review status (Passed, requires changes etc.) • Provide reporting functionality on key factors When used most • During requirements gathering, HLD, LLD, Test Design phase, Project planning Who uses most • Developers • Testers • Business Analysts • Managers
222. Static Analysis Tools(D) The developer code is input data for static analysis tool Static analysis tools are extension of compiler technology Static analysis tools help developers to understand the structure of code They enforce coding standards and best practices Features • • • • • To enforce coding standards. To analyze code structure and dependencies Identify defects in code Helps to understand the code. Calculate metrics(Cyclomatic complexity, nesting levels etc.) which help to identify where more testing is required due to complex code and increased risk When used • During unit/component testing Who uses most • Developers
223. Modelling Tools(D) Modeling tools help to validate models of the system or software Modeling tools capture and translate complex system designs into easily understood representations of the data flows and processes Modeling tools create a blueprint for construction and/or re-engineering. Modelling tools are typically used by developers Features • Modeling tools identify any inconsistencies or defects in the model • Modeling tool helps to predict system response and behavior under different conditions like load and stress • Modeling tools help to understand the system functions and identify test conditions using modeling language like UML • Modeling tools aid in generating test cases based on the model When used • During unit/component testing Who uses most • Developers
224. Modelling Tool(D) UI
225. Tools support for Test Specification Some tools to support test specificat ion are: • Test Design Tools • Test Data Preparation Tools
226. Test Design Tools Test design tools help to construct test cases and test inputs Test design tool can easily and quickly identify the tests (or test inputs) that will exercise all of elements, e.g. input fields, buttons, branches Test design tools also help to identify possible combinations for test execution like OS and browser combinations Test design tool embedded with code coverage tools help to identify functionality which is still not being tested by current set of tests and where new tests need to added Features • Test design tools generate test input values from following: • Requirements • Design models (state, data or object) • GUI • Software Code • Test conditions • If test oracle is available then it also generates the expected result When used most • Throughout the SDLC Who uses most • Testers
227. Test Data Preparation Tools Test data preparation tools help to prepare test data Mostly used for performance and reliability testing as large amount of data is required for performance and reliability testing Features • Extract data from different databases or files • Extract data from existing production environment and push it into the test environment • Construct large number of records from template for performance tests • Provides data masking feature for data protection and privacy • Modify data records and order When used most • System, End-to-end, Performance Testing Who uses most • Testers • Developers
228. Effective Use of Tools Benefits & Risks Potential benefits of using tools Risks of using tools Special considera tions for some types of tools • • • • Test Execution Tools Performance Testing Tools Static Analysis Tools Test Management Tools
229. Potential Benefits of using Tools Reduction of repetitive work • Repetitive work is very difficult to do manually • People become bored if they have to perform same task again and again • Regression testing is repetitive work • Setting up same test data in test environment Greater consistency and repeatability • Even if people think they are doing same task with exact same steps but they tend to do it slightly differently every time • Tool can automate exactly same steps every time • Beneficial to do test environment setup Objective Assessment • While reporting person can make errors in test or defect reports • Tool removes the subjective bias • Tool helps to do calculation and assessment consistently like code coverage, incident reports etc. Testing information is easily accessible • Large information is hard to understand if not presented in correct format • Tool help to present information in visual manner like charts and graphs which is easy to understand
230. Potential Risks of using Tools Unrealistic expectations from tools • Before introducing the tool it is very important to do assessment and make sure it fulfils the project needs • As tools are also software you should not expect that just buying and introducing tool will solve all the testing problems Underestimating the initial implementation time, cost and effort • Introducing new tool is not straightforward and proper planning, time and cost considerations should be done for successful implementation Underestimating the effort required for tool maintenance • Tool requires time and effort to maintain so proper time and budget should be allocated for it Over reliance on the tool • There are situations where manual testing is more efficient than relying on tool • Relying on tool for every project need is not good Missing skills to use the tools • Skills required for using the tool might be missing from team • Need to scope for training required to build the skills for tool usage
231. Considerations for Test Execution Tool Test execution tool requires good knowledge of programming skills You should not rely completely on capture/playback feature of test execution tool, it is used very minimal Capture/Playback feature is useful only for few number of test cases Capture/playback can also be used if exploratory testing is being done – Captured inputs are only useful for short term Do not plan to execute regression testing using capture/playback feature Test execution tools are not script free, the different levels of scripting are: • Linear scripts - Can be created manually or by recording a manual test • Structured scripts - Created by using programming structures • Shared scripts - Scripts can be called by other scripts and can be re-used • Data-driven scripts • Test data is in file or spreadsheet • Control script read data from the file • Keyword-driven scripts • All information about tests is stored in the file or spreadsheet • Multiple control scripts describe the test cases described in the spreadsheet
232. Considerations for Performance Testing Tool Performance testing tools provide inputs about the non-functional quality characteristics of software The aim of using performance testing tool is to find the characteristics like throughput, system resources being used, time taken for certain transactions etc. Before finalizing any performance testing tools for testing it is important to know what a tool can do for you and what it cannot Important considerations for performance testing tools are: • • • • How How How How load is generated by the tool delay are inserted to make load data more realistic to report the performance data to narrow down the performance bottleneck
233. Considerations for Static Analysis Tool Static analysis tools identify code issues and coding standards well in advance before code execution Should not be stringently used on old code written years ago as that might not meet the new standards and produce lot of errors/warnings It’s good to used static analysis tool on new code as it will find any code issues early and your code will be more maintainable
234. Considerations for Test Management Tool You may need to interface test management tool with other tools to make it more useful and fulfil you requirements Test reports produced by test management tools may not fulfil all your requirements so you may need to export it into Excel format and make it as per your needs If it does not have built in incident management, project management and requirements management so, you may need to integrate it with existing incident management, project management and requirement management tools It’s good to introduce test management tool once you have defined test process If you don’t have defined test process best approach is to define your process first taking into account the test management tool you will be using which will give you maximum benefits of tool
235. Introducing a Tool into an Organisation Main principles of introducing the tool Goals of Pilot Project or Proof-ofConcept for tool evaluations Success factors
236. Main principles of introducing the tool Tool will provide benefit to organization when it meets the organizations need Tool should help to build strengths and address the organizations weakness If the organizations testing practices are not mature, you should first work on improving testing practices rather than introducing new tool Factors important for tools selection • Assess the organizations maturity (i.e. readiness to change) • Identification of areas where introduction of tools support will be helpful • Do proper evaluation of tool against clearly defined tool requirements(Evaluate most of the available tools) • Do a proof-of-concept for some existing project to see if the tool works as desired and meets the defined objectives • Evaluate how the training, support and reputation of organization is which is providing tools • Identify the internal implementation (Deployment resources, hardware, software etc.) and training needs (Training will be required for people who are new to tool)
237. Pilot Project Pilot project is a way to do proof-of-concept effectively Introducing a tool in pilot project ensures that it is explored properly and meets the project needs Main objective of pilot project should be to use tool in different ways and find out how the tool handles different conditions Pilot project should not be business critical and not very large project Objectives of the Pilot Project for new tool are: • • • • • Learn how to use tool in more detail To evaluate how the tool fits in your existing process To evaluate how to use tool to streamline existing process Determine what needs to change with tool implementation Determine ROI on tool if it is implemented on a larger scale
238. Success Factors Success is not guaranteed by just implementing the testing tool in organization Some factors contributing to success are: • Incremental roll out of tool to the rest of organization • Adapt to the process and continuous improvement of process after tool is launched • Providing adequate training to new users • Defining and communicating usage guidelines based on learning from pilot project • Monitor the use of tool and benefits achieved by tool usage
239. Testing time!
240. 1. ___________ Testing will be performed by the people at client own locations A. Alpha testing B. Field testing C. Performance testing D. System testing
241. 1. ___________ Testing will be performed by the people at client own locations A. Alpha testing B. Field testing C. Performance testing D. System testing B. Field testing
242. 2. System testing should investigate A. Non-functional requirements only not Functional requirements B. Functional requirements only not non-functional requirements C. Non-functional requirements and Functional requirements D. Nonfunctional requirements or Functional requirements
243. 2. System testing should investigate A. Non-functional requirements only not Functional requirements B. Functional requirements only not non-functional requirements C. Non-functional requirements and Functional requirements D. Nonfunctional requirements or Functional requirements C. Non-functional requirements and Functional requirements
244. 3. Which is the nonfunctional testing A. Performance testing B. Unit testing C. Regression testing D. Sanity testing
245. 3. Which is the nonfunctional testing A. Performance testing B. Unit testing C. Regression testing D. Sanity testing A. Performance testing
246. 4. Who is responsible for document all the issues, problems and open point that were identified during the review meeting A. Moderator B. Scribe C. Reviewers D. Author
247. 4. Who is responsible for document all the issues, problems and open point that were identified during the review meeting A. Moderator B. Scribe C. Reviewers D. Author B. Scribe
248. 5. What is the main purpose of Informal review A. Inexpensive way to get some benefit B. Find defects C. Learning, gaining understanding, deffect finding D. Discuss, make decisions, solve technical problems
249. 5. What is the main purpose of Informal review A. Inexpensive way to get some benefit B. Find defects C. Learning, gaining understanding, effect finding D. Discuss, make decisions, solve technical problems A. Inexpensive way to get some benefit
250. 6. Purpose of test design technique is A. Identifying test conditions only, not Identifying test cases B. Not Identifying test conditions, Identifying test cases only C. Identifying test conditions and Identifying test cases D. Identifying test conditions or Identifying test cases
251. 6. Purpose of test design technique is A. Identifying test conditions only, not Identifying test cases B. Not Identifying test conditions, Identifying test cases only C. Identifying test conditions and Identifying test cases D. Identifying test conditions or Identifying test cases C. Identifying test conditions and Identifying test cases
252. 7. ___________ technique can be used to achieve input and output coverage A. Boundary value analysis B. Equivalence partitioning C. Decision table testing D. State transition testing
253. 7. ___________ technique can be used to achieve input and output coverage A. Boundary value analysis B. Equivalence partitioning C. Decision table testing D. State transition testing B. Equivalence partitioning
254. 8. Use cases can be performed to test A. Performance testing B. Unit testing C. Business scenarios D. Static testing
255. 8. Use cases can be performed to test A. Performance testing B. Unit testing C. Business scenarios D. Static testing C. Business scenarios
256. 9. ________________ testing is performed at the developing organization’s site (1M) A. Unit testing B. Regression testing C. Alpha testing D. Integration testing
257. 9. ________________ testing is performed at the developing organization’s site A. Unit testing B. Regression testing C. Alpha testing D. Integration testing C. Alpha testing
258. 10. The purpose of exit criteria is A. Define when to stop testing B. End of test level C. When a set of tests has achieved a specific pre condition D. All of the above
259. 10. The purpose of exit criteria is A. Define when to stop testing B. End of test level C. When a set of tests has achieved a specific pre condition D. All of the above D. All of the above
No comments...
none