DOCSLIB.ORG

Embedded Software Testing 18-649 Distributed Embedded Systems Philip Koopman September 30, 2015

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Embedded Software Testing 18-649 Distributed Embedded Systems Philip Koopman September 30, 2015 10 Embedded Software Testing 18-649 Distributed Embedded Systems Philip Koopman September 30, 2015 © Copyright 2000-2015, Philip Koopman Overview Testing is an attempt to find bugs • The reasons for finding bugs vary • Finding all bugs is impossible Various types of testing for various situations • Exploratory testing – guided by experience • White Box testing – guided by software structure • Black Box testing – guided by functional specifications Various types of testing throughout development cycle • Unit test • Subsystem test • System integration test • Regression test • Acceptance test • Beta test 2 Definition Of Testing Testing is performing all of the following: • Providing software with inputs (a “workload”) • Executing a piece of software • Monitoring software state and/or outputs for expected properties, such as: – Conformance to requirements – Preservation of invariants (e.g., never applies brakes and throttle together) – Match to expected output values – Lack of “surprises” such as system crashes or unspecified behaviors General idea is attempting to find “bugs” by executing a program The following are potentially useful techniques, but are not testing: • Model checking • Static analysis (lint; compiler error checking) • Design reviews of code • Traceability analysis 3 Testing Terminology Workload: • “Inputs applied to software under test” • Each test is performed with a specific workload Behavior: • “Observed outputs of software under test” • Sometimes special outputs are added to improve observability of software (e.g., “test points” added to see internal states) Oracle: • “A model that perfectly predicts correct behavior” • Matching behavior with oracle output tells if test passed or failed • Oracles come in many forms: – Human observer – Different version of same program – Hand-created script of predicted values based on workload – List of invariants that should hold true over behavior 4 What’s A Bug? Simplistic answer: • A “bug” is a software defect = incorrect software • A software defect is an instance in which the software violates the specification More realistic answer – a “bug” can be one or more of the following: • Failure to provide required behavior • Providing an incorrect behavior • Providing an undocumented behavior or behavior that is not required • Failure to conform to a design constraint (e.g., timing, safety invariant) • Omission or defect in requirements/specification • Instance in which software performs as designed, but it’s the “wrong” outcome • Any “reasonable” complaint from a customer • … other variations on this theme … The goal of most testing is to attempt to find bugs in this expanded sense 5 Types Of Testing – Outline For Following Slides Testing styles: • Smoke testing • Exploratory testing • Black box testing • White box testing Testing situations: • Unit test • Subsystem test • System integration test • Regression test • Acceptance test • Beta test Most testing styles have some role to play in each testing situation 6 Smoke Testing Quick test to see if software is operational • Idea comes from hardware realm – turn power on and see if smoke pours out • Generally simple and easy to administer • Makes no attempt or claim of completeness • Smoke test for car: turn on ignition and check: – Engine idles without stalling – Can put into forward gear and move 5 feet, then brake to a stop – Wheels turn left and right while stopped Good for catching catastrophic errors • Especially after a new build or major change • Exercises any built-in internal diagnosis mechanisms But, not usually a thorough test • More a check that many software components are “alive” 7 Exploratory Testing A person exercises the system, looking for unexpected results • Might or might not be using documented system behavior as a guide • Is especially looking for “strange” behaviors that are not specifically required nor prohibited by the requirements Advantages • An experienced, thoughtful tester can find many defects this way • Often, the defects found are ones that would have been missed by more rigid testing methods Disadvantages • Usually no documented measurement of coverage • Can leave big holes in coverage due to tester bias/blind spots • An inexperienced, non-thoughtful tester probably won’t find the important bugs 8 Black Box Testing Tests designed with knowledge of behavior • But without knowledge of implementation • Often called “functional” testing Idea is to test what software does, but not how function is implemented • Example: cruise control black box test – Test operation at various speeds – Test operation at various underspeed/overspeed amounts – BUT, no knowledge of whether lookup table or control equation is used Advantages: • Tests the final behavior of the software • Can be written independent of software design – Less likely to overlook same problems as design • Can be used to test different implementations with minimal changes Disadvantages: • Doesn’t necessarily know the boundary cases – For example, won’t know to exercise every lookup table entry • Can be difficult to cover all portions of software implementation 9 Examples of Black Box Testing Assume you want to test a floating point square root function: sqrt(x) • sqrt(0) = 0 (boundary condition) • sqrt(1) = 1 (behavior changes between <1 and >1 • sqrt(9) = 3 (test some number greater than 1) • sqrt(.25) = .5 (test some number less than 1) • sqrt(-1) => error (test an out of range input) • sqrt(FLT_MAX) => … (test maximum numeric range) • sqrt(FLT_EPSILON) => … (test smallest positive number) • sqrt(NaN) => NaN (test for Not a Number input values) • Pick random positive numbers and confirm that: sqrt(x) * sqrt(x) = x – Note that the oracle here is an invariant, not a specific result • Other types of possible results to monitor: – Monitor numerical accuracy/stability for floating point math – Check to see if software crashes on some inputs 10 White Box Testing Tests designed with knowledge of software design • Often called “structural” testing Idea is to exercise software, knowing how it is designed • Example: cruise control white box test – Test operation at every point in control loop lookup table – Tests that exercise both paths of every conditional branch statement Advantages: • Usually helps getting good coverage (tests are specifically designed for coverage) • Good for ensuring boundary cases and special cases get tested Disadvantages: • 100% coverage tests might not be good at assessing functionality for “surprise” behaviors and other testing goals • Tests based on design might miss bigger picture system problems • Tests need to be changed if implementation/algorithm changes • Hard to test code that isn’t there (missing functionality) with white box testing 11 Examples of White Box Testing Assume you want to test a floating point square root function: sqrt(x) • Uses lookup table spaced at every 0.1 between zero and 10 • Uses iterative algorithm at and above value of 10 • Test sqrt(x) for negative numbers (expect error) • Test sqrt(x) for every value of x in middle of lookup table: 0.05, 0.15, … 9.95 • Test sqrt(x) exactly at every lookup table entry: 0, 0.1, 0.2, … 10.0 • Test sqrt(x) at 10.0 + FLT_EPSILON • Test sqrt(x) for some numbers that exercise interpolation algorithm Main differences from Black Box Testing: • Tests exploit knowledge of software design & coding details • Usually strives for 100% coverage of known properties – e.g., lookup table entries • Digs deepest at algorithmic discontinuities & branches – e.g., lookup table boundaries and center values 12 Testing Coverage “Coverage” is a notion how completely testing has been done • Usually a percentage (e.g., “97% branch coverage”) White box testing coverage (this is the usual use of the word “coverage”): • Percent of conditional branches where both sides of branch have been tested • Percent of lookup table entries used in computations • Doesn’t test missing code (e.g., missing exception handlers) Black box testing coverage: • Percent of requirements tested • Percent of documented exceptions exercised by tests • But, must relate to externally visible behavior or environment, not code • Doesn’t test extra behavior that isn’t supposed to be there Important note: 100% coverage is not “100% tested” • Each coverage aspect is narrow; good coverage is necessary, but not sufficient to achieve good testing 13 System-Level Testing Can’t Be Complete • System level testing is useful and important – Can find unexpected component interactions • But, it is impracticable to test everything at the system level – Too many possible operating conditions, timing sequences, system states – Too many possible faults, which might be intermittent • Combinations of component failures + memory corruption patterns • Multiple software defects activated by a sequence of operations TOO MANY POSSIBLE NAL TESTS O I E AT UR R L AI S E F PE P TY SCENARIOS O TIMING AND SEQUENCING 14 Even Unit Testing Is Typically Incomplete How many test cases to completely test the following : myfunction(int a, int b, int c) Assume 32-bit integers: •232 * 232 * 232 = 296 = 7.92 * 1028 => at 1 billion tests/second • Testing all combinations takes 2,510,588,971,096 years • Takes longer for complete tests if there are any state variables inside function • Takes longer if there are environmental dependencies to test as well This is a fundamental problem with testing – you can’t test everything • Therefore, need some notion of how much is “enough” testing Even if you could test “everything,”
Load more

Recommended publications
  • Smoke Testing
    International Journal of Scientific and Research Publications, Volume 4, Issue 2, February 2014 1 ISSN 2250-3153 Smoke Testing Vinod Kumar Chauhan Quality Assurance (QA), Impetus InfoTech Pvt. Ltd. (India) Abstract- Smoke testing is an end-to-end testing which determine the stability of new build by checking the crucial functionality of the application under test and used as criteria of accepting the new build for detailed testing. Index Terms- Software testing, acceptance testing, agile, build, regression testing, sanity testing I. INTRODUCTION The purpose of this research paper is to give details of smoke testing from the industry practices. II. SMOKE TESTING The purpose of smoke testing is to determine whether the new software build is stable or not so that the build could be used for detailed testing by the QA team and further work by the development team. If the build is stable i.e. the smoke test passes then build could be used by the QA and development team. On the stable build QA team performs functional testing for the newly added features/functionality and then performs regression testing depending upon the situation. But if the build is not stable i.e. the smoke fails then the build is rejected to the development team to fix the build issues and create a new build. Smoke Testing is generally done by the QA team but in certain situations, can be done by the development team. In that case the development team checks the stability of the build and deploy to QA only if the build is stable. In other case, whenever there is new build deployment to the QA environment then the team first performs the smoke test on the build and depending upon the results of smoke the decision to accept or reject the build is taken.
    [Show full text]
  • Types of Software Testing
    Types of Software Testing We would be glad to have feedback from you. Drop us a line, whether it is a comment, a question, a work proposition or just a hello. You can use either the form below or the contact details on the rightt. Contact details [email protected] +91 811 386 5000 1 Software testing is the way of assessing a software product to distinguish contrasts between given information and expected result. Additionally, to evaluate the characteristic of a product. The testing process evaluates the quality of the software. You know what testing does. No need to explain further. But, are you aware of types of testing. It’s indeed a sea. But before we get to the types, let’s have a look at the standards that needs to be maintained. Standards of Testing The entire test should meet the user prerequisites. Exhaustive testing isn’t conceivable. As we require the ideal quantity of testing in view of the risk evaluation of the application. The entire test to be directed ought to be arranged before executing it. It follows 80/20 rule which expresses that 80% of defects originates from 20% of program parts. Start testing with little parts and extend it to broad components. Software testers know about the different sorts of Software Testing. In this article, we have incorporated majorly all types of software testing which testers, developers, and QA reams more often use in their everyday testing life. Let’s understand them!!! Black box Testing The black box testing is a category of strategy that disregards the interior component of the framework and spotlights on the output created against any input and performance of the system.
    [Show full text]
  • Smoke Testing What Is Smoke Testing?
    Smoke Testing What is Smoke Testing? Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing. The term ‘Smoke Testing’ is came from the hardware testing, in the hardware testing initial pass is done to check if it did not catch the fire or smoked in the initial switch on.Prior to start Smoke testing few test cases need to created once to use for smoke testing. These test cases are executed prior to start actual testing to checkcritical functionalities of the program is working fine. This set of test cases written such a way that all functionality is verified but not in deep. The objective is not to perform exhaustive testing, the tester need check the navigation’s & adding simple things, tester needs to ask simple questions “Can tester able to access software application?”, “Does user navigates from one window to other?”, “Check that the GUI is responsive” etc. Here are graphical representation of Smoke testing & Sanity testing in software testing: Smoke Sanity Testing Diagram The test cases can be executed manually or automated; this depends upon the project requirements. In this types of testing mainly focus on the important functionality of application, tester do not care about detailed testing of each software component, this can be cover in the further testing of application. The Smoke testing is typically executed by testers after every build is received for checking the build is in testable condition. This type of testing is applicable in the Integration Testing, System Testing and Acceptance Testing levels.
    [Show full text]
  • Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK
    1 From Start-ups to Scale-ups: Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK Abstract—This paper1 describes some of the challenges and research questions that target the most productive intersection opportunities when deploying static and dynamic analysis at we have yet witnessed: that between exciting, intellectually scale, drawing on the authors’ experience with the Infer and challenging science, and real-world deployment impact. Sapienz Technologies at Facebook, each of which started life as a research-led start-up that was subsequently deployed at scale, Many industrialists have perhaps tended to regard it unlikely impacting billions of people worldwide. that much academic work will prove relevant to their most The paper identifies open problems that have yet to receive pressing industrial concerns. On the other hand, it is not significant attention from the scientific community, yet which uncommon for academic and scientific researchers to believe have potential for profound real world impact, formulating these that most of the problems faced by industrialists are either as research questions that, we believe, are ripe for exploration and that would make excellent topics for research projects. boring, tedious or scientifically uninteresting. This sociological phenomenon has led to a great deal of miscommunication between the academic and industrial sectors. I. INTRODUCTION We hope that we can make a small contribution by focusing on the intersection of challenging and interesting scientific How do we transition research on static and dynamic problems with pressing industrial deployment needs. Our aim analysis techniques from the testing and verification research is to move the debate beyond relatively unhelpful observations communities to industrial practice? Many have asked this we have typically encountered in, for example, conference question, and others related to it.
    [Show full text]
  • Michael Bolton in NZ Pinheads, from the Testtoolbox, Kiwi Test Teams & More!
    NZTester The Quarterly Magazine for the New Zealand Software Testing Community and Supporters ISSUE 4 JUL - SEP 2013 FREE In this issue: Interview with Bryce Day of Catch Testing at ikeGPS Five Behaviours of a Highly Effective Time Lord Tester On the Road Again Hiring Testers Michael Bolton in NZ Pinheads, From the TestToolbox, Kiwi Test Teams & more! NZTester Magazine Editor: Geoff Horne [email protected] [email protected] ph. 021 634 900 P O Box 48-018 Blockhouse Bay Auckland 0600 New Zealand www.nztester.co.nz Advertising Enquiries: [email protected] Disclaimer: Articles and advertisements contained in NZTester Magazine are published in good faith and although provided by people who are experts in their fields, NZTester make no guarantees or representations of any kind concerning the accuracy or suitability of the information contained within or the suitability of products and services advertised for any and all specific applications and uses. All such information is provided “as is” and with specific disclaimer of any warranties of merchantability, fitness for purpose, title and/or non-infringement. The opinions and writings of all authors and contributors to NZTester are merely an expression of the author’s own thoughts, knowledge or information that they have gathered for publication. NZTester does not endorse such authors, necessarily agree with opinions and views expressed nor represents that writings are accurate or suitable for any purpose whatsoever. As a reader of this magazine you disclaim and hold NZTester, its employees and agents and Geoff Horne, its owner, editor and publisher, harmless of all content contained in this magazine as to its warranty of merchantability, fitness for purpose, title and/or non-infringement.
    [Show full text]
  • Exploring Languages with Interpreters and Functional Programming Chapter 11
    Exploring Languages with Interpreters and Functional Programming Chapter 11 H. Conrad Cunningham 24 January 2019 Contents 11 Software Testing Concepts 2 11.1 Chapter Introduction . .2 11.2 Software Requirements Specification . .2 11.3 What is Software Testing? . .3 11.4 Goals of Testing . .3 11.5 Dimensions of Testing . .3 11.5.1 Testing levels . .4 11.5.2 Testing methods . .6 11.5.2.1 Black-box testing . .6 11.5.2.2 White-box testing . .8 11.5.2.3 Gray-box testing . .9 11.5.2.4 Ad hoc testing . .9 11.5.3 Testing types . .9 11.5.4 Combining levels, methods, and types . 10 11.6 Aside: Test-Driven Development . 10 11.7 Principles for Test Automation . 12 11.8 What Next? . 15 11.9 Exercises . 15 11.10Acknowledgements . 15 11.11References . 16 11.12Terms and Concepts . 17 Copyright (C) 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 1 (662) 915-5358 Browser Advisory: The HTML version of this textbook requires a browser that supports the display of MathML. A good choice as of October 2018 is a recent version of Firefox from Mozilla. 2 11 Software Testing Concepts 11.1 Chapter Introduction The goal of this chapter is to survey the important concepts, terminology, and techniques of software testing in general. The next chapter illustrates these techniques by manually constructing test scripts for Haskell functions and modules. 11.2 Software Requirements Specification The purpose of a software development project is to meet particular needs and expectations of the project’s stakeholders.
    [Show full text]
  • Experience and Exploring in Software Testing
    Ohjelmistotestauksen Teemapäivä, TTY, 8.6.2010 How Do Testers Do It? Exploratory and Experience Based Testing Juha Itkonen Software Business and Engineering Institute (SoberIT) [email protected] +358 50 5771688 Contents • Introduction to experience based and exploratory testing – Intelligent manual testing • Overall strategies and detailed techniques • Selection of exploratory tester’s pitfalls Juha Itkonen - SoberIT 2010 2 Manual Testing • Testing that is performed by human testers Research has shown: 1. Individual differences in • Stereotype of manual testing testing are high 2. Test case design – Executing detailed pre-designed test cases techniques alone do not – Mechanical step-by-step following the explain the results instructions – Treated as work that anybody can do In practice, it’s clear that some testers are better than others in manual testing and more effective at revealing defects... Juha Itkonen - SoberIT 2010 3 My viewpoint: Experience Based – Intelligent – Manual Testing • Manual testing that builds on the tester’s experience – knowledge and skills • Some aspects of testing rely on tester’s skills – during testing – e.g., input values, expected results, or interactions • Testers are assumed to know what they are doing – Testing does not mean executing detailed scripts • Focus on the actual testing work in practice – What happens during testing activities? – How are defects actually found? – Experience-based and exploratory aspects of software testing Juha Itkonen - SoberIT 2010 4 Exploratory Testing is creative testing without predefined test cases Based on knowledge and skills of the tester 1. Tests are not defined in advance – Exploring with a general mission – without specific step-by-step instructions on how to accomplish the mission 2.
    [Show full text]
  • Information Systems Project Management
    SUBJECT INFORMATION SYSTEMS PROJECT MANAGEMENT TOPIC: SESSION 10: CASE STUDY My Hands-On Experience Software Testing CASE STUDY:My Hands-On Experience Software Testing SESSION 10 CASE STUDY My Hands-On Experience Software Testing Well-versed with formal and exploratory software testing approaches in traditional and iterative software development models. Formal and exploratory testing of web applications, local desktop applications, SDK packages Used various software test design techniques which are traditionally called as black-box/white-box, static/dynamic testing techniques Known in the testing industry for challenging some well established thoughts from the renowned experts like Schools of Testing, Testing vs Checking, Formal vs Exploratory testing etc. Developed an improved parser-friendly text session report format for exploratory testing using Session based test management. Developed Python code to parse all session reports periodically to generate consolidated PDF reports for the team. Introduced Test Doubles concept to system testing to increase test coverage Employed All-pairs technique to API testing and event capturing testing Worked on Database migration testing from hierarchial (IMSDB) to RDBMS ( DB2 ). Was chosen by management to take up training for the complete development team on testing of the integrated system. White box testing using code coverage tools Security Testing His experiments with Python and fuzzing made him the first to present on the subject of fuzzing at any software testing conference, voted as the Best Innovative Paper Award by audience. He moved on to present extended tutorials on the subject with demonstrations of exploits using Python. Conducted web security testing for multiple clients and reported critical security bugs not found by automated scanners.
    [Show full text]
  • Is White Box Testing Manual Or Automated
    Is White Box Testing Manual Or Automated Sometimes disillusioned Sid hopple her imprinters east, but continent Ajai atomises discommodiously or franchised invariably. How grasping is Georgie when spondylitic and unimpregnated Guy pistol-whip some lameness? Peccant Seth demit unintentionally while Wildon always bolshevises his blackcurrants yokes uneasily, he presages so raucously. The above preparations and black box testing process from regular security is manual testing or a resource for the customer requirements, regardless of the What Are Benefits of Smoke Testing? Conducted for automated or major is beneficial to. Responsible for creating test cases in quality grade in such arrogant way almost all best business requirements cover. Term strategic choice of internal structure and other related to check the black box testing based on manual is testing or white box. Software testing can mine continuously for white testing is that bottle neck open. There is manual or minor refactoring to manually in automating the. There are became different types of testing. Automated testing, as opposed to manual testing, allows time and resources to be freed up dump the testing process, stream that testing can be performed at higher speed, with higher accuracy and carefully lower costs. This advocate is ugly by Facebook to deliver advertisement when customer are on Facebook or a digital platform powered by Facebook advertising after visiting this website. Test cases are hear with and intended requirements and specifications of the application in mind. You please guide with manual or twice, manual and white box method that are other software development life cycle in white box. User acceptance form of possible to examine if necessary part of software continue to go through a newly added or wrong.
    [Show full text]
  • Getting to Continuous Testing
    T2 Continuous Testing Thursday, October 3rd, 2019 9:45 AM Getting to Continuous Testing Presented by: Max Saperstone Coveros Brought to you by: 888---268---8770 ·· 904---278---0524 - [email protected] - http://www.starwest.techwell.com/ Max Saperstone Max Saperstone has been working as a software and test engineer for over a decade, with a focus on test automation within the CI/CD process. He specializes in open source tools, including the Selenium tool suite, JMeter, AutoIT, Cucumber, and Chef. Max has led several test automation efforts, including developing an automated suite focusing on web-based software to operate over several applications for Kronos Federal. He also headed a project with Delta Dental, developing an automated testing structure to run Cucumber tests over multiple test interfaces and environments, while also developing a system to keep test data "ageless." He currently heads up the development of Selenified, an open source testing framework to allow for testing of multiple interfaces, custom reporting, and minimal test upkeep. Getting to Continuous Testing A Greenfield Test Automation Story [email protected] maxsaperstone @Automate_Tests Max Saperstone @Automate_Tests 1 Max Saperstone @Automate_Tests Max Saperstone • Director of Testing and Automation at Coveros • Over a decade of test automation experience • Often Test Architect on consulting projects • Helped transform multiple organizations to test effectively within sprints • Mainly focuses on open source tools • Lover of the outdoors and cheap beer Max
    [Show full text]
  • The Nature of Exploratory Testing
    The Nature of Exploratory Testing by Cem Kaner, J.D., Ph.D. Professor of Software Engineering Florida Institute of Technology and James Bach Principal, Satisfice Inc. These notes are partially based on research that was supported by NSF Grant EIA-0113539 ITR/SY+PE: "Improving the Education of Software Testers." Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. Kaner & Bach grant permission to make digital or hard copies of this work for personal or classroom use, including use in commercial courses, provided that (a) Copies are not made or distributed outside of classroom use for profit or commercial advantage, (b) Copies bear this notice and full citation on the front page, and if you distribute the work in portions, the notice and citation must appear on the first page of each portion. Abstracting with credit is permitted. The proper citation for this work is ”Exploratory & Risk-Based Testing (2004) www.testingeducation.org", (c) Each page that you use from this work must bear the notice "Copyright (c) Cem Kaner and James Bach", or if you modify the page, "Modified slide, originally from Cem Kaner and James Bach", and (d) If a substantial portion of a course that you teach is derived from these notes, advertisements of that course should include the statement, "Partially based on materials provided by Cem Kaner and James Bach." To copy otherwise, to republish or post on servers, or to distribute to lists requires prior specific permission and a fee.
    [Show full text]
  • Tapir: Automation Support of Exploratory Testing Using Model Reconstruction of the System Under Test Miroslav Bures, Karel Frajtak, and Bestoun S
    1 Tapir: Automation Support of Exploratory Testing Using Model Reconstruction of the System Under Test Miroslav Bures, Karel Frajtak, and Bestoun S. Ahmed Abstract—For a considerable number of software projects, To overcome these limitations, we explore possible the creation of effective test cases is hindered by design doc- crossover between common MBT techniques and the ex- umentation that is either lacking, incomplete or obsolete. The ploratory testing approach. Exploratory testing is defined as the exploratory testing approach can serve as a sound method in such situations. However, the efficiency of this testing approach simultaneous testing, learning, documentation of the System strongly depends on the method, the documentation of explored Under Test (SUT) and creation of the test cases [3]. The parts of a system, the organization and distribution of work exploratory testing approach is a logical choice for testing among individual testers on a team, and the minimization of systems for which a suitable test basis is not available. Even potential (very probable) duplicities in performed tests. In this when the test basis is available, and the test cases are created, paper, we present a framework for replacing and automating a portion of these tasks. A screen-flow-based model of the tested they can be either obsolete or inconsistent and structured at an system is incrementally reconstructed during the exploratory excessively high level [4]. Thus, testers employ the exploratory testing process by tracking testers’ activities. With additional testing technique as a solution for overcoming these obstacles. metadata, the model serves for an automated navigation process The key factors for the efficiency of exploratory testing are for a tester.
    [Show full text]