Michael Bolton in NZ Pinheads, from the Testtoolbox, Kiwi Test Teams & More!

Total Page:16

File Type:pdf, Size:1020Kb

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. No part of this magazine may be reproduced in whole or in part without the express written permission of the publisher . © Copyright 2013 - NZ Tester Magazine, all rights reserved. 2 IN THIS ISSUE… Click on title... 30 On the Road Again Geoff Horne, NZTester Magazine 6 Interview With Bryce Day, Founder & CEO, Catch Software 34 Hiring Student Testers, Ian Wells, Telogis 14 Testing at ikeGPS Jeremy Gold, ikeGPS REGULAR FEATURES 18 Five Behaviours of a Highly 4 NZTester Magazine Effective Time Lord Tester Announcements Richard Boustead, Statistics NZ 11 Testing Events 20 The Pinheads 22 Michael Bolton in New Zealand 21 From the TestToolBox Adam Howard with Katrina Edgar & Aaron Hodder 29 Kiwi Test Teams 28 When John Was a Tester Great Bugs takes a break this issue. The Journal For New Zealand Test Professionals Welcome to Issue 4 of NZTester Magazine. Richard Boustead on the perils of being a Time Lord Tester! A lot has been happening since our last issue, mainly in the form of conferences, summits and In May, Colin and I put out a combined Newsletter meetups. After the launch of of OZTester in April, in which we wrote about our personal experiences editor Colin Cherry & myself embarked upon a with the various schools of software testing. Our conglomeration of conference attendances which initial idea was that this was to be a "taster" for a encompassed the Cognizant Test Summits, STPCon, more detailed analysis of the subject in the next StarEast, ANZTB 2013 and will also take in KWST, (current) issues of OZTester and NZTester. OZWST, Let’s Test Taster, STANZ, StarWest and However, at this point in time we’re still gathering ignite over the next few months. These “road information and comment and therefore the full trips”enable us to keep abreast with the very latest article is still a work-in-progress. in testing trends and ensures that we continue to Anyway, happy reading and as always, we do establish and maintain a healthy wordwide appreciate any feedback you may have around our network of testing experts and personalities as publications. well as with professional testing practitioners from all over. In this issue we welcome Ian Wells, Adam Howard, Katrina Edgar, Aaron Hodder and Jeremy Gold to the NZTester writers fold plus we hear again from 3 NZTester Announcements NZTester Survey NZTester Auckland Meetup We’d still like to know a bit more about your The inaugural NZTester Auckland Meetup will be thoughts on NZTester Magazine so we can held in August. Details are as follows: continue to shape it according to what you would like to see. Wed, August 14 2013, 4:00pm—6:00pm Our survey with SurveyMonkey is still active. It’s Venue: mostly multiple choice questions which should Catch Software take no more than 4-5 minutes to complete. Level 3, 300 Queen St Auckland We’d certainly appreciate you taking the time out to complete this survey, we’ll hold the results over Agenda: until the next edition of NZTester (October). 4:00pm Meet and greet 4:30pm Presentation: Geoff Horne, QA Click on the logo below to go straight to the Transformation - the Journey Continues survey. 5:30pm NZTester Magazine discussion To sign up to the NZTester Meetup Group and register, click on the logo above. To register for the session without signing up through Meetup, click here. VOTE…. for your favourite article in this edition of NZTester Magazine. Next issue……! Send in your vote for the article you think is the best in this issue and the winning author will receive a $100 JBHiFi voucher. Send to [email protected] Last issue winner was Nele Nikovic of TradeMe for his Project vs Product Testing article. Well done Nele, a $100 JBHiFi voucher will be on its way to you shortly. 4 Announcements cont. Over the Tazzie, in the latest issue of…. NZTester Directories Later in the year, we will be looking to publish three testing industry directories: Interview with Brendan Fitzgerald of TestIT 1) Testing Companies - New Zealand The Joolery Diaries: An Aussie Abroad 2) Testing Companies - Australia ANZTB Conference & SIG reviews 3) Testing Tools - management, automation, Confessions of a Test Strategist code coverage etc. Starting a New Role as a Test Manager We encourage companies wishing to appear Authority Bias: The Bane of Testing in either of the Testing Companies directories to register interest with us below. Click on the cover to download. There will be no charge for placing an entry and full advertising opportunities will be available at our standard advertising rates. The Tools directory will be product-based and researched by NZTester personnel. Planit TestingI ndex Now in its seventh year, the Planit Testing Index is an industry-wide benchmark for software development projects from across Australia and New Zealand. It provides a solid foundation for strategic planning, budgeting and execution of quality assurance activities in IT. Our commentary for last year’s Index can be found in NZTester 2. The 2013 Index will represent over 10,000 software development projects from Australia and New Zealand. To participate, click on the graphic 5 This issue’s interview is: Bryce Day Founder & CEO, Catch Software, Auckland Our interview this issue is with Bryce Day, Founder The first with Atlassian, has developed numerous and CEO of Catch Software. Catch is one of New tools including JIRA (defect management) and Zealand’s success stories with its flagship product, Confluence (enterprise wiki). Secondly with Sparx Enterprise Tester, being used by such organisations Systems, creators of Enterprise Architect (CASE as PayPal, US Navy and eBay among others. tool for analysis, design, and architecture). We have partnered with both companies for about seven years and run Sparx Systems New Zealand, which NZTester: Can you please describe Catch? gives us responsibility for Enterprise Architect in New Zealand and global responsibility as one of Catch is a Kiwi software company, that has been in seven sister companies. We are also one of twenty- operation for nine years. Our aim is to develop the five global Atlassian Enterprise Experts that work world's best test management platform and for us with customers to train, consult, and implement that's not just about the software, but the services Atlassian products globally and are recognised to and support that wrap around it. We have an have the expertise to do this at an enterprise level. extremely high-performing team, that is passionate about delivering better software for test teams globally, and a solutions team that provides training, NZTester: What product and services does consulting services, and support to our customers Catch offer? to ensure that they have everything they need to be Our product offerings centre around Enterprise successful. While we're based in New Zealand, over Tester, but we also sell Enterprise Architect and 90% of our software sales occur overseas, with the associated plugins, Atlassian software (JIRA, majority being in North America to the likes of the Confluence, Team Calendars, etc.), and numerous Intel, PayPal, US Navy, LG, eBay, Stanford University, plugins for these products. On the solutions side of Scotiabank and Philips. Closer to home organisations the business, we offer training, mentoring, and like Air New Zealand, Orion Health, eRoad, consulting around our core products; Enterprise University of Auckland, Navman, and APN are using Tester, Enterprise Architect, and the Atlassian our test management software, Enterprise Tester, software. This includes both small pieces of work to ensure they are producing high quality products. around the software and end-to-end Enterprise Tester is not only a great test implementations across an organisation using both management tool, but also allows organisations traditional waterfall approaches and agile practices. to create an end-to-end integrated tool chain by integrating with our partner products; Atlassian NZTester: What do you believe makes JIRA, Rally, Sparx Systems Enterprise Architect, Catch different? and Microsoft TFS. With this in mind we aim to provide a total product experience for our customers From a soft skills point of view we are passionate and as such provide training, mentoring, consulting, about what we do, have worked hard to put in place support along with the product to ensure they have a great culture, are globally focused, and we care everything they need to be successful.
Recommended publications
  • 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]
  • 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]
  • Continuous Testing
    BROUGHT TO YOU IN PARTNERSHIP WITH CONTENTS ö Continuous Testing vs. Test Continuous Testing: Automation ö Continuous Testing and Agile Transforming Testing for Agile + DevOps Success ö The Top Continuous Testing Roadblocks and DevOps ö The Path to Continuous Testing ö Conclusion WRITTEN BY CHRISTOPHER SPRINGSTEAD, PRODUCT MARKETING MANAGER, CA TECHNOLOGIES UPDATED BY WAYNE ARIOLA, CMO, TRICENTIS Let's face it. Businesses don't want — or need — perfect software. Continuous Testing vs. Test Automation They want to deliver new, business-differentiating software as Like Lucy and Ethel struggling to keep pace at the chocolate soon as possible. To enable this, we need fast feedback on whether factory, many software testers have been scrambling to keep pace the latest innovations will work as expected or crash and burn with accelerated processes — then along comes the supervisor in production. We also need to know if these changes somehow proclaiming, "You're doing splendidly! Speed it up!" broke the core functionality that the customer base — and thus the As expectations associated with testing are changing, legacy testing business — depends upon. platforms aren't keeping up. Legacy testing platforms take a "heavy" This is where continuous testing comes in. Continuous testing is approach to testing. They rely on brittle scripts, deliver slow end- the process of executing automated tests as part of the software to-end regression test execution, and produce an overwhelming delivery pipeline in order to obtain feedback on the business risks level of false positives. As a result, they've achieved limited success associated with a software release as rapidly as possible.
    [Show full text]
  • Software Testing
    Software Testing Software testing can be stated as the process of verifying and validating that a software or application is bug free, meets the technical requirements as guided by it’s design and development and meets the user requirements effectively and efficiently with handling all the exceptional and boundary cases. The process of software testing aims not only at finding faults in the existing software but also at finding measures to improve the software in terms of efficiency, accuracy and usability. It mainly aims at measuring specification, functionality and performance of a software program or application. Software testing can be divided into two steps: 1. Verification: it refers to the set of tasks that ensure that software correctly implements a specific function. 2. Validation: it refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements. 3. Verification: “Are we building the product right?” 4. Validation: “Are we building the right product?” What are different types of software testing? Software Testing can be broadly classified into two types: 1. Manual Testing: Manual testing includes testing a software manually, i.e., without using any automated tool or any script. In this type, the tester takes over the role of an end-user and tests the software to identify any unexpected behavior or bug. There are different stages for manual testing such as unit testing, integration testing, system testing, and user acceptance testing. Testers use test plans, test cases, or test scenarios to test a software to ensure the completeness of testing.
    [Show full text]
  • Fuzzing for Software Security Testing and Quality Assurance Ch00fm 5053.Qxp 5/19/08 12:45 PM Page Ii
    ch00fm_5053.qxp 5/19/08 12:45 PM Page i Fuzzing for Software Security Testing and Quality Assurance ch00fm_5053.qxp 5/19/08 12:45 PM Page ii For a list of related Artech House titles, please turn to the back of this book. ch00fm_5053.qxp 5/19/08 12:45 PM Page iii Fuzzing for Software Security Testing and Quality Assurance Ari Takanen Jared DeMott Charlie Miller artechhouse.com ch00fm_5053.qxp 5/19/08 12:45 PM Page iv Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the U.S. Library of Congress. British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library. ISBN 13: 978-1-59693-214-2 Cover design by Igor Valdman © 2008 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. 10987654321 ch00fm_5053.qxp 5/19/08 12:45 PM Page v This book is dedicated to our families and friends .
    [Show full text]
  • Integrating Exploratory Testing in Software Testing Life Cycle, a Controlled Experiment
    Master Thesis Software Engineering September 2012 Integrating Exploratory Testing In Software Testing Life Cycle A Controlled Experiment Firstname Lastname Address: If applicable Tanveer Ahmed E-mail: If applicableChejerla a long-term e -Madhusudhanamail (not your student e- mail)Raju School of Computing Internet : www.bth.se/com School of Computing Blekinge Institute of Technology Phone : +46 455 38 50 00 Blekinge Institute of Technology SE-371 79 Karlskrona Fax : +46 455 38 50 57 SE-371 79 Karlskrona Sweden Sweden This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 30 weeks of full time studies. Authors: Tanveer Ahmed Address: Karlskrona,Sweden Email: [email protected]. MadhuSudhanaRaju.Chejerla Address: Karlskrona,Sweden Email: [email protected] University advisor: Dr. Wasif Afzal School of Computing Blekinge Tekniksa Hogskola,Sweden 1 ABSTRACT Context. Software testing is one of the crucial phases in software development life cycle (SDLC). Among the different manual testing methods in software testing, Exploratory testing (ET) uses no predefined test cases to detect defects. Objectives. The main objective of this study is to test the effectiveness of ET in detecting defects at different software test levels. The objective is achieved by formulating hypotheses, which are later tested for acceptance or rejection. Methods. Methods used in this thesis are literature review and experiment. Literature review is conducted to get in-depth knowledge on the topic of ET and to collect data relevant to ET. Experiment was performed to test hypotheses specific to the three different testing levels : unit , integration and system.
    [Show full text]
  • Software Testing Concepts
    Software Testing M1: Introduction to Software Testing 1.1 What is Software Testing? 1.2 Need for Software Testing 1.3 Testing Fundamentals M2: Introduction to Testing Techniques 2.1 Static Testing 2.2 Dynamic Testing 2.2.1 WhiteBox Testing 2.2.2 BlackBox Testing 2.2.3 GreyBox Testing M3: Testing Levels 3.1 Functional Testing 3.2 Integration Testing 3.2.1 Incremental Integration Testing 3.2.2 Non-Incremental Integration Testing 3.3 System Testing 3.4 Acceptance Testing 3.4.1 Alpha and Beta Testing M4: Types of Testing 4.1 Smoke Testing 4.2 Compatibility Testing 4.3 Usability Testing 4.3.1 Accessibility Testing 4.4 Performance Testing 4.5 Exploratory Testing 4.6 Ad-hoc Testing 4.7 Recovery Testing 4.8 Globalization Testing 4.9 Regression Testing M5: Introduction to STLC 5.1 What is STLC? 5.2 Flow Diagram 5.3 Stages of STLC M6: Introduction to Test Plan 6.1 What is Test Plan? 6.2 Contents of Test Plan M7: Introduction to Test cases 7.1 What is a Test case? 7.2 Contents of Test case M8: Introduction to SBLC 8.1 What is SBLC? 8.2 Flow Diagram 8.3 Different status of Bug 8.4 Bug, Defect and Error M9: Verification vs. Validation 9.1 What are Verification and Validation? 9.2 Types of Verification M10: Activity 10.1 Writing Test cases Presentation: 1.1 Introduction to Software Testing Overview This presentation gives the introduction of Software Testing, common software problems, best practices to be followed during testing, objectives of a tester and categories of defects, etc.
    [Show full text]
  • Exploratory Testing Explained V.1.3 4/16/03
    Exploratory Testing Explained v.1.3 4/16/03 James Bach [email protected] copyright © 2002-2003, James Bach Exploratory software testing is a powerful approach, yet widely misunderstood. In some situations, it can be orders of magnitude more productive than scripted testing. All testers practice some form of exploratory testing, unless they simply don’t create tests at all. Yet few of us study this approach, and it doesn't get much respect in our field. This attitude is beginning to change as companies seek ever more agile and cost effective methods of developing software. Among the hardest things to explain is something that everyone already knows. We all know how to listen, how to read, how to think, and how to tell anecdotes about the events in our lives. As adults, we do these things everyday. Yet the level of any of these skills, possessed by the average person, may not be adequate for certain special situations. Psychotherapists must be expert listeners and lawyers expert readers; research scientists must scour their thinking for errors and journalists report stories that transcend parlor anecdote. So it is with exploratory testing (ET): simultaneous learning, test design and test execution. This is a simple concept. But the fact that it can be described in a sentence can make it seem like something not worth describing. Its highly situational structure can make it seem, to the casual observer, that it has no structure at all. That’s why textbooks on software testing, with few exceptions, either don’t discuss exploratory testing, or discuss it only to dismiss it as an unworthy practice.
    [Show full text]
  • An Experiment on the Effectiveness and Efficiency of Exploratory Testing
    Empir Software Eng DOI 10.1007/s10664-014-9301-4 An experiment on the effectiveness and efficiency of exploratory testing Wasif Afzal · Ahmad Nauman Ghazi · Juha Itkonen · Richard Torkar · Anneliese Andrews · Khurram Bhatti © Springer Science+Business Media New York 2014 Abstract The exploratory testing (ET) approach is commonly applied in industry, but lacks scientific research. The scientific community needs quantitative results on the performance of ET taken from realistic experimental settings. The objective of this paper is to quantify the effectiveness and efficiency of ET vs. testing with documented test cases (test case based testing, TCT). We performed four controlled experiments where a total of 24 practition- ers and 46 students performed manual functional testing using ET and TCT. We measured the number of identified defects in the 90-minute testing sessions, the detection difficulty, severity and types of the detected defects, and the number of false defect reports. The results show that ET found a significantly greater number of defects. ET also found significantly more defects of varying levels of difficulty, types and severity levels. However, the two test- ing approaches did not differ significantly in terms of the number of false defect reports Communicated by: Jos´e Carlos Maldonado W. Afzal () School of Innovation, Design and Engineering, M¨alardalen University, V¨aster˚as, Sweden e-mail: [email protected] A. N. Ghazi · K. Bhatti Blekinge Institute of Technology, SE-37179, Karlskrona, Sweden A. N. Ghazi e-mail: [email protected] J. Itkonen Department of Computer Science and Engineering, Aalto University, Espoo, Finland e-mail: [email protected] R.
    [Show full text]