DOCSLIB.ORG

Fall 2020 Active Learning Project: Automated Testing Using Scripting

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fall 2020 Active Learning Project: Automated Testing Using Scripting 1 CEN 4072 Software Testing Team Essay: Fall 2020 Active learning project: automated testing using scripting ABSTRACT Debugging can be an extremely labor-intensive activity involving many repetitive and common operations. The ability to step through these recurring, often mundane, tasks is perfect for scripting programs. In order to fully leverage the debugging capability of scripts, computer science professionals should first understand the benefits of using scripts for that purpose. Also, they need to appreciate the features of the different scripting languages and be familiar with different tools to aid in debugging activities using scripts. This paper presents a basic understanding of these benefits and examines a few key features and tools. It also highlights a simple example of how a script might be used to debug a program. Specifically, this paper’s example looks at Selenium as a front-end web development testing framework. KEYWORDS Automation, Debugging, Scripts, Testing, Selenium INTRODUCTION Scripts play a key role in automation. Essentially, scripts are simply programming languages that execute tasks one after another. As a result, the nature of scripts has led it to become the most important tool for a programmer that seeks automating parts of their workflow. Similarly, a programmer’s job involves testing their creations extensively, so programmers will commonly use scripts to automate the debugging process. By using a testing suite, a programmer can execute hundreds of tests with one command, allowing for a much more efficient workflow. Benefits of Using Scripts in Debugging Fundamentally, script-based testing and debugging tackles the general resource intensiveness of software testing. This aim should not be undervalued, as software testing is CEN 4072 – Software Testing: Essay 2 perhaps the single most important sub-activity of the software development lifecycle. The advent of automated testing was a significant breakthrough in the field. It greatly reduced the effort involved by streamlining the test creation process (via frameworks like JUnit) and making large scale regression testing viable (Sommerville). The introduction of scripts has continued that evolution. The added benefits of scripts vary depending on the technique, language, and application used; these separate topics will be discussed later. For this section, we will outline the benefits of using scripts in the broadest sense of debugging and software testing. What follows is a non-exhaustive list of those benefits: Presentation Layer Scripting: Scripting languages can simulate human behavior at both low and high levels of abstraction (mouse button clicks and GUI component events, respectively). As a result, it is always feasible to test a program at the presentation layer (Zeller). This is a great advantage under certain circumstances. For example, for software that is designed such that there is no separation between the presentation and functionality, there may be no other option for automating testing. Flexibility in Test Design: The ability to simulate behavior at different abstraction levels already offers flexibility in test design at the presentation layer, but scripts can also automate the testing process at the functionality and unit program layers. This is accomplished at the functionality layer via interfaces (e.g., SOAP for web services) that enable communication between programs and scripting languages. And there is good reason to opt for this form of test script—it is more resilient to change. That is, changes to the user interface will not affect the script (Zeller). As for the unit layer, scripts typically cannot control unit tests directly. However, as scripts are tools of automation, they can execute the test suite and process its output. All these options allow the programmer to create test scripts that both suit their needs and the needs of the program. Functional and Non-Functional Testing: Scripting languages are uniquely suited for both functional and non-functional testing. The explanation for this is twofold. For one, as previously stated, scripts can interact with functionality layer of a software—invoking actions and observing results—to determine if exhibited behavior fulfills the software requirements. This is functional testing, and scripts can perform this process as well as any other method. The second part of the explanation, however, is where testing can be taken a step further. Scripts can also interact with software at the system-level. Using a virtual machine, they can simulate hardware, send inputs, and inject faults (Zeller). This virtual test environment is ideal for testing a multitude of non-functional requirements (e.g., performance, compatibility, reliability). Quick Test Creation (Record/Playback): Many scripting languages are compatible with tools that “record” interaction with software—that is, these tools automatically generate scripts that correspond to the user’s actions. These scripts can then be “played back” in the same way any other script is run. This is helpful tool for testing as it “enables users to start automating quickly as no planning is required, tester can just simply record any manual test case” (Hanna et al.). For example, imagine a programmer has identified an action sequence CEN 4072 – Software Testing: Essay 3 that results in some error. They can quickly generate a test script by recording the sequence. While debugging, this script will quickly verify whether the problem remains. Cumulative Effects: This section began by stating that the use of scripts in software testing targets the activity’s high resource requirements. Ultimately, that is what these benefits add up to. They limit monetary costs, reduce time spent on testing, help increase test coverage, and more. Features of the Script Language With scripting established as an effective way of testing software, there are many practices that must be followed to maximize the effectiveness of automatic testing. Having failsafe protocols when testing software can save time and false failed tests. An easy failsafe protocol to follow would be to sync the software and the testing tool (Khalid). This ensures that previous tests do not have an impact on the newer tests. Another recommended practice that should be followed is into implement event handlers. Event handlers can reduce the number of troubleshooting problems, sync the software and testing tool, act as a failsafe and control the execution. An example of an event handler would be a try and catch statement. This allows a user to execute a block of code and if an error occurs in the try block, catch will return any errors that happen in the try block. Sometimes, software works perfectly in one environment and not others, so an easy way to combat this is to test in multiple environments as well as write down variables so that patterns and permutations can be easily identified. A checklist to follow every testing session is to specify the purpose of the software, test early, create test cases before implementing code, test often, test enough so that everything is covered and have other people test (Zeller). Developing scripts which are efficient and effective at testing all aspects of the software can be a difficult task. In order to develop test scripts, having clear and simple to read scripts are essential. Testers must be able to easily understand the scripts. Documentation of the script and having clear code helps tremendously in optimizing the CEN 4072 – Software Testing: Essay 4 testing process. To simplify the scripts, it is recommended to have smaller scripts, each with one specific purpose. All scripts should be maintainable, meaning they should be able to be updated even if there are changes in the software. The most important part of writing test scripts is to make sure they are well thought out. The script must cover every single potential path the user may take. This ensures that there are absolutely no errors within the software and checks even the most remote options. An easy way to test all paths is to draw out every single path in a diagram and check off each path after a test script is written (StarDust). Essential Tools and Functions Writing test scripts is very similar to writing programs themselves. They need to be debugged and tested themselves before they are put into practice. Due to the similarities of processes of writing in programs and scripts, a lot of the same principles are followed. When we write any code, it needs to have a specific purpose, and that purpose should be clear and documented. It’s often better to have a few specific scripts then to have only one script that potentially covers all the matters of an entire program. This is like writing functions. The more focused a function, the more flexible and reusable it becomes (Zeller). Scripts should also be tested early and often. It’s important to start running test cases as soon as one unit is implemented. The system should be assembled from those tested units. Also, tests should be run after any change has taken place on the system and certainly with each new system release. Test cases can even be written prior to a unit being implemented. That can help keep the unit focused and act as the unit’s specifications. There is no such thing as testing too much, but there is such a thing as not testing enough. Test cases should sufficiently cover all the code written with a multitude of a variety of inputs. And when you feel that the script (or scripts) you have written are complete, invite other testers to try and uncover any defects or weaknesses that you may have missed (Zeller). Scripting itself doesn’t come with just one way to accomplish the task. There are several different techniques that have different properties. Scripting can be linear, structured, shared, data-driven and keyword-driven. The linear technique records a series of testing instructions with manual user interaction and then saving the actions as a test script.
Load more

Recommended publications
  • A Framework for Evaluating Performance of Software Testing Tools
    INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH VOLUME 9, ISSUE 02, FEBRUARY 2020 ISSN 2277-8616 A Framework For Evaluating Performance Of Software Testing Tools Pramod Mathew Jacob, Prasanna Mani Abstract: Software plays a pivotal role in this technology era. Due to its increased applicable domains, quality of the software being developed is to be monitored and controlled. Software organization follows many testing methodologies to perform quality management. Testing methodologies can be either manual or automated. Automated testing tools got massive acceptability among software professionals due to its enhanced features and functionalities than that of manual testing. There are hundreds of test automation tools available, among which some perform exceptionally well. Due to the availability of large set of tools, it is a herculean task for the project manager to choose the appropriate automation tool, which is suitable for their project domain. In this paper, we derive a software testing tool selection model which evaluates the performance aspects of a script-based testing tool. Experimental evaluation proves that, it can be used to compare and evaluate various performance characteristics of commercially accepted test automation tools based on user experience as well as system performance. Index Terms: Automated testing, Software testing, Test script, Testing Tool, Test bed, Verification and Validation. —————————— ◆ —————————— 1 INTRODUCTION S OFTWARE is advanced in recent days by enhancing its applicable domains. Software is embedded in almost all electronic gadgets and systems. In this scenario the quality of the software plays a significant role. The customer or end – user should be satisfied which is primarily depended on quality and capability of the software being developed.
    [Show full text]
  • Agile Test Automation Strategy for Anyone and Everyone!
    Agile Test Automation Strategy For Anyone and Everyone! Gerard Meszaros [email protected] Much Ado About Agile 2011 1 Copyright 2011 Gerard Meszaros My Background •Software developer 80’s •Development manager Embedded •Project Manager ----- Telecom •Software architect 90’s •OOA/OOD Mentor •Requirements (Use Case) Mentor ----- I.T. •XP/TDD Mentor •Agile PM Mentor 00’s •Test Automation Consultant & Trainer Gerard Meszaros •Lean/Agile Coach/Consultant [email protected] Product & I.T. Much Ado About Agile 2011 2 Copyright 2011 Gerard Meszaros Agenda • Motivation – The Agile Test Problem – The Fragile Test Problem • Approaches to Test AutomationRough timings for Agile Test Automation Strategy Time per slide: 1.4 # of Slide # • Test Automation Strategy # Topic Time Slides Start End Motivation 11.2 8 2 9 Exercise 1 - Automation Motivation 10 1 10 10 Intro to Automation 7 5 11 15 Exercise 2 - Why not Record & Playback? 10 1 16 16 Why Automated Tests are Fragile 8.4 6 17 22 How Agile Automation Changes Things 9.8 7 24 30 Intro to Example-Driven Development 7 5 32 36 Managing Scope vs Detail in Examples 15.4 11 38 48 How to specify workflows 8.4 6 50 55 Exercise 3 - Workflow Tests (Keyword-Driven) 15 1 56 56 Using Data-Driven Tests to specify business rules 8.4 6 55 60 Exercise 4 - Business Rules Test (Data-Driven) 15 1 61 61 How Tests Interact With the SUT 7 5 62 66 Test-Driven Architecture 5.6 4 67 70 Legacy Systems (if time permits) 19.6 14 71 84 The Role of Unit Tests 8.4 6 85 90 Test Automation Strategy 14 10 91 100 180.2 97 Much
    [Show full text]
  • Test Script Debugger CBTA 3.0 SP11 Document History
    Test Automation - User Guide PUBLIC SAP Solution Manager 7.2 2018-12-03 CBTA - Test Script Debugger CBTA 3.0 SP11 Document History Version Date Change 1.6 2018-12-03 CBTA 3.0 SP11 Update 1.5 2018-05-15 CBTA 3.0 SP10 Update 1.4 2017-09-30 CBTA 3.0 SP9 Update 1.3 2017-03-01 CBTA 3.0 SP8 Update 1.2 2014-05-27 CBTA 3.0 SP2 Update CBTA - Test Script Debugger 2 Document History Table of Contents 1 Running a CBTA Test Script in Debug Mode..........................................................................4 2 How-to start .............................................................................................................................5 2.1 Add or remove breakpoint..................................................................................................................................... 8 2.2 Step Over............................................................................................................................................................ 9 2.3 Run...................................................................................................................................................................... 9 2.4 Stop Debugger................................................................................................................................................... 9 2.5 Error Behavior .......................................................................................................................................................10 2.6 Dynamic Report...............................................................................................................................................
    [Show full text]
  • Automated Testing of Firmware Installation and Update Scenarios for Peripheral Devices
    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2019 Automated testing of firmware installation and update scenarios for peripheral devices DAG REUTERSKIÖLD KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Automated testing of firmware installation and update scenarios for peripheral devices DAG REUTERSKIÖLD Master in Computer Science Date: August 12, 2019 Supervisor: Hamid Faragardi Examiner: Elena Troubitsyna School of Electrical Engineering and Computer Science Host company: Tobii AB Swedish title: Automatisering av enhetsinstallation, uppdatering och testning med hjälp av virtuella maskiner iii Abstract This research presents an approach to transition from manual to automated testing of hardware specific firmware. The manual approach for firmware test- ing can be repetitive and time consuming. A significant proportion of the time is spent on cleaning and re-installing operating systems so that old firmware does not interfere with the newer firmware that is being tested. The approach in this research utilizes virtual machines and presents an automation framework. One component of the automation framework is an application to imitate con- nected peripheral devices to bypass hardware dependencies of firmware in- stallers. The framework also consists of automation and pipeline scripts with the objective to execute firmware installers and detect errors and abnormalities in the installation and updating processes. The framework can run on locally hosted virtual machines, but is most applicable using cloud hosted virtual ma- chines, where it is part of a continuous integration that builds, downloads, installs, updates and tests new firmware versions, in a completely automated manner. The framework is evaluated by measuring and comparing execution times with manually conducted installation and updating tests, and the result shows that the framework complete tests much faster than the manual approach.
    [Show full text]
  • This Document Explains the Various Benefits That Would Accrue to a User Or Client Who Subscribes to Autorabit
    ® Salesforce Release Automation BENEFITS DOCUMENT This document explains the Various Benefits that would accrue to a user or client who subscribes to AutoRABIT. [email protected] www.autorabit.com Copyright © 2016 AutoRABIT. AutoRABIT Table of Contents About AutoRABIT.............................................................................................................................................................3 AutoRABIT functionality..................................................................................................................................................3 Key Features of AutoRABIT............................................................................................................................................4 Metadata Deployment.....................................................................................................................................................4 Promotion of Builds .........................................................................................................................................................4 Full Deployment..........................................................................................................................................................4 Selective Deployment................................................................................................................................................4 Sandbox Back-up & Restore...........................................................................................................................................5
    [Show full text]
  • GUI-Guided Test Script Repair for Mobile Apps
    This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TSE.2020.3007664 1 GUI-Guided Test Script Repair for Mobile Apps Minxue Pan, Tongtong Xu, Yu Pei, Zhong Li, Tian Zhang, Xuandong Li Abstract—Graphical User Interface (GUI) testing is widely used to test mobile apps. As mobile apps are frequently updated and need repeated testing, to reduce the test cost, their test cases are often coded as scripts to enable automated execution using test harnesses/tools. When those mobile apps evolve, many of the test scripts, however, may become broken due to changes made to the app GUIs. While it is desirable that the broken scripts get repaired, doing it manually can be preventively expensive if the number of tests need repairing is large. We propose in this paper a novel approach named METER to repairing broken GUI test scripts automatically when mobile apps evolve. METER leverages computer vision techniques to infer GUI changes between two versions of a mobile app and uses the inferred changes to guide the repair of GUI test scripts. Since METER only relies on screenshots to repair GUI tests, it is applicable to apps targeting open or closed source mobile platforms. In experiments conducted on 22 Android apps and 6 iOS apps, repairs produced by METER helped preserve 63.7% and 38.8% of all the test actions broken by the GUI changes, respectively.
    [Show full text]
  • Marrying Devops and Test Automation
    ARTICLE Marrying DevOps and Test Automation - a t t e n t i o n. a l w a y s. Is It The Right Thing To Do? Practice Head: Author: Janaki Jayachandran Sharon Paul Independent Testing Services Research Analyst We are all aware of the indifferences among the IT operations and other software development communities that prevail right from the traditional IT era. When developers, operations and testing teams work on different independent silos, focus on individual objectives and performance indicators, they fail to understand the importance of being accountable for any unplanned outages that causes production deployment failure and heavy loss to the company. There had to be a methodology or a practice that facilitated continuous improvement of the delivery cycles by enabling members across the IT and operations feel responsible and accountable for quality of their work. This thought gave rise to the concept of DevOps that fosters cross functional collaboration in order to speed up the delivery cycles through regular customer feedback. How DevOps Culture Impacts Product Quality? DevOps is simply an extension of agile methodology which became quite popular since 2009. It was the solution that resulted due to a series brainstorming sessions by few agile experts who wanted to end the dysfunction in the IT industry. The key reason for the dysfunction was found to be a lack of accountability in terms of quality among the different operations and IT team. Aspire Systems - Marrying DevOps and Test Automation - Is It The Right Thing To Do? 1 Marrying DevOps and Test Automation - Is It The Right Thing To Do? Elisabeth Hendrickson, founder of Quality Tree Software, presented an interesting paper, where she clearly cites a real life scenario of how developers develop a sense of negligence towards quality and they focus more on pushing their features into ‘test’ without taking an effort to evaluate them.
    [Show full text]
  • API Testing Guide an Automated Approach to API Testing Transformation
    API Testing Guide An automated approach to API testing transformation. From Monolith to Microservice The consumerization of IT has changed the way we write applications today. Instead of building a single, monolithic system that is installed on a server in a back office or call center, modern When testing APIs, testers are faced with applications are scattered within mobile devices and web browsers numerous discrete units of work. Some so users can gain access to services at anytime from anywhere. of these APIs may have been created by a third party, while the possible And modern applications are no longer self-contained; they are ordering and combinations of different composed of multiple service components that are tied together versions of APIs can cause the number of at runtime. Therefore, the end-user experience is not powered by combinations that need to be tested to the elegant UIs we all use, but by APIs that facilitate interactions skyrocket to an impossible number. between code modules, applications and back-end IT systems. The ability to identify these combinations Because of this, the way we test must change. Quality assurance and then reduce them to a realistic (QA) and development teams must expand their capacity to test number without compromising quality each layer of the application, as well as the end-to-end business requires testers to adopt a transactions. Modern applications then require comprehensive API new model-based approach and invest in testing in addition to traditional UI testing. But API testing presents automation technologies. many challenges for testers. It requires a new approach—one that is automated wherever possible and inherently data-driven.
    [Show full text]
  • Agile Test Automation Strategy, V2.Pptx
    MJ Half-day Tutorials 10/3/16 13:00 Test Automation Strategies for the Agile World Presented by: Bob Galen Velocity Partners Brought to you by: 350 Corporate Way, Suite 400, Orange Park, FL 32073 888---268---8770 ·· 904---278---0524 - [email protected] - http://www.starwest.techwell.com/ Bob Galen Velocity Partners An agile methodologist, practitioner, and coach, Bob Galen ([email protected]) helps guide companies in their adoption of Scrum and other agile methodologies and practices. Bob is a principal agile evangelist at Velocity Partners; president of RGCG; and frequent speaker on software development, project management, software testing, and team leadership. He is a Certified Scrum Coach, Certified Scrum Product Owner, and an active member of the Agile and Scrum Alliances. Bob published Scrum Product Ownership–Balancing Value from the Inside Out. Test Automation Strategies for the Agile World Bob Galen President & Principal Consultant RGCG, LLC [email protected] Introduction Bob Galen n Independent Agile Coach (CEC) at RGCG, LLC n Director, Agile Practices at n Somewhere ‘north’ of 30 years overall experience J n Wide variety of technical stacks and business domains n Developer first, then Project Management / Leadership, then Testing n Senior/Executive software development leadership for 20+ years n Practicing formal agility since 2000 n XP, Lean, Scrum, and Kanban experience n From Cary, North Carolina Bias Disclaimer: Agile is THE BEST Methodology for Software Development… However, NOT a Silver Bullet! Copyright © 2016 RGCG, LLC 2 1 Outline n Traditional Automation – Business Case & ROI n 3-Pillars n Agile Test Automation Pyramid n Agile Automation – Business Case & ROI n Implementation Strategy n Communication n Wrap-up Copyright © 2016 RGCG, LLC 3 Let’s start with… Traditional Automation Strategy n What are your current strategies towards: q Test Automation q Frameworks q Tooling q Maintenance q ROI q Team structure n Get together in “pairs” and chat about this for 20 minutes.
    [Show full text]
  • A Rapid Introduction to Rapid Software Testing
    A Rapid Introduction to Rapid Software Testing James Bach, Satisfice, Inc. Michael Bolton, DevelopSense [email protected] [email protected] www.satisfice.com www.developsense.com +1 (360) 440‐1435 +1 (416) 656‐5160 Rapid Intro to Rapid Testing ‐ 1 Acknowledgements • James Bach, Michael Bolton, Huib Schoots, Paul Holland, and Griffin Jones co‐create and teach this class. • Some of this material was developed in collaboration with Cem Kaner. • Jon Bach has been a long‐term collaborator in developing ET management and training methods. • Lenore Bach (wife of James) maintains the emotional and home environment that motivated James and enabled him to create this. • Mary Alton, Michael’s wife does the same for him, while also contributing support for our Web sites and trying to lead us towards better visual design in our materials. If what you see doesn’t look good to you, it’s probably because Mary wasn’t involved. • Many of the ideas in this presentation were also inspired by or augmented by other colleagues including Doug Hoffman, Bret Pettichord, Brian Marick, Dave Gelperin, Elisabeth Hendrickson, Jerry Weinberg, Noel Nyman, and Mary Alton. • Some of our exercises were introduced to us by Payson Hall, Ross Collard, James Lyndsay, Dave Smith, Earl Everett, Brian Marick, and Joe McMahon. • Many ideas were improved by students who took earlier versions of the class going back to 1995. Rapid Intro to Rapid Testing ‐ 2 1 Assumptions About You • You test software, or any other complex human creation. • You have at least some control over the design of your tests and some time to create new tests.
    [Show full text]
  • Devops & Software Development Tools
    DevOps & Software Development Tools Competitive Landscape and Market Trends v2.3 – December 2018 Shea & Company DevOps & Software Development Tools Market Trends & Landscape The DevTools Market Has Reemerged ◼ Back in 2011, Marc Andreessen somewhat famously wrote “software is eating the world,” putting forward the belief we’re in the midst of a dramatic technological shift in which software-defined companies are poised to dominate large swathes of the economy. Over the intervening six years, accelerated by the cloud and a growing comfort with outsourcing human activates to machines, software has become ubiquitous. With examples like Amazon displacing traditional retailers or a proprietary “Today's large John Deere tractors have application for player evaluation named “Carmine” helping to lead the Boston Red Sox more lines of code than early space to three titles since 2004, the power of software cannot be understated. shuttles.” Samuel Allen (CEO, Deere & Company) ◼ Software is not only disrupting business models in place for centuries (or 86 years of baseball futility), but it also is enabling incumbent vendors across disparate industries to improve product offerings, drive deeper engagement with customers and optimize selling and marketing efforts. Most industries (financial services, retail, entertainment, healthcare) and large organizations now derive a great deal of their competitive differentiation from software. As Andreessen wrote, “the days when a car aficionado could repair his or her own car are long past, due primarily to the high software “Software is like entropy. It is difficult to content.” grasp, weighs nothing and obeys the second law of thermodynamics; i.e., it ◼ But as software has brought benefits, it has also brought increasing demands for always increases.” business agility – and the software industry itself has been changed.
    [Show full text]
  • Automated Software Reliability Services Using Reliability Tools Should Be As Easy As Webmail
    Automated Software Reliability Services Using Reliability Tools Should Be As Easy As Webmail George Candea, Stefan Bucur, Vitaly Chipounov, Vova Kuznetsov, Cristian Zamfir School of Computer and Communication Sciences École Polytechnique Fédérale de Lausanne (EPFL), Switzerland Software quality assurance (QA) is boring, resource- ware, without human involvement from the service user’s hungry, labor-intensive, takes a long time, and is prone to or provider’s side.1 AutoSRS combines the concept of re- human omission and error. While research has offered a liability tools as a competitive, simple web service, with wealth of new techniques, few made satisfactory progress doing automated testing and debugging in the cloud, thus in all these directions, so industry still relies on relatively harnessing vast, elastic resources toward making such au- primitive techniques for software testing and debugging. tomation practical for real software. AutoSRS consists of: Little has changed in QA practice over the last 20 years. 1. Programmer’s sidekick that continuously and thor- Studies have found bug density in production-ready oughly tests code as it is written, with no upfront in- software to be staying constant over time, while average vestment from the developer; code volume of software is increasing exponentially, with 2. Debugging service that turns bug reports into 100% the net effect that the number of bugs per product is in- deterministically replayable bug scenarios; creasing. It is therefore necessary to quickly find a “dis- 3. Home edition on-demand testing service for con- ruptive technology” to reduce bug density by at least 10×. sumers to verify the software they are about to install We see two key challenges: First, few of today’s tools on their PC, phone, TiVo, camera, etc.
    [Show full text]