The Domain Testing Workbook
Format: PDF / Kindle (mobi) / ePub
Domain testing is the most widely taught technique in software testing. However, many of the presentations stick with examples that are too simple to provide a strong basis for applying the technique. Others focus on mathematical models or analysis of the program’s source code. The Domain Testing Workbook will help you develop deep skill with this technique whether or not you have access to source code or an abiding interest in mathematics.
The Domain Testing Workbook provides a schema to organize domain testing and test design, with dozens of practical problems and sample analyses. Readers can try their hand at applying the schema and compare their analyses against over 200 pages of worked examples.
You will learn:
- when and how to use domain testing;
- how to apply a risk-focused approach with domain testing;
- how to use domain testing within a broader testing strategy; and
- how to use domain testing in an exploratory way.
This book is for:
- Software testers who want to develop expertise in the field’s most popular test technique
- Test managers who want to assess and improve their staff’s skills
- Trainers and professors interested in adding depth and skill-based learning to black box testing or test design classes.
Cem Kaner, J.D., Ph.D., is Professor of Software Engineering at the Florida Institute of Technology. Dr. Kaner is senior author of Testing Computer Software, Lessons Learned in Software Testing and Bad Software. The ACM’s Special Interest Group for Computers and Society presented him with the Making a Difference Award in 2009 and the Software Test Professionals presented him with the Software Test Luminary Award in 2012. Kaner was a founder of the Association for Software Testing. He is lead developer of the BBST™ (Black Box Software Testing) courses and courseware.
Sowmya Padmanabhan, M.Sc., currently works at Google as a Program Manager. Before that she worked in Program Management and Software Development/Test at Microsoft and at Texas Instruments. She has a Masters degree in Computer Sciences with a specialization in Software Testing. Sowmya’s thesis involved extensive research in training new testers to do skilled Domain Testing.
Douglas Hoffman, M.S.E.E., M.B.A, is an independent management consultant with Software Quality Methods, LLC. He is a Fellow of the American Society for Quality. He has authored numerous papers and is a contributing author of Experiences of Test Automation. He has taught several courses on software testing and test automation for the University of California’s Extension campuses. He has served as President of the Association for Software Testing and of the Silicon Valley Software Quality Association and as Section Chair of the Silicon Valley Section of ASQ.
inside the circle, plus the circle (Sets 1 and 2). At a minimum, include a point on the boundary (the circle is inside the input domain) and a point outside the circle. Normally, we include one On point for each quadrant and two Off points (points outside the circle are our Outer points), each in separate quadrants. (E) THE CIRCLE & POINTS OUTSIDE IT The input domain includes all the points outside the circle, plus the circle (Sets 1, 3 and 4). At a minimum, include a point on the
installs the driver for the printer you select. There are a few thousand Windows-compatible printers. In this dialog, selecting the manufacturer brings up a list of printers made by that manufacturer. OVERVIEW This shows a straightforward dialog. It shows two lists two lists, Manufacturers and Printers. • Select a Manufacturer to determine which printers (made by that manufacturer) show in the Printers list. • Select a Printer to install it. • Click Windows Update to update both lists.
http://mdh.diva-portal.org/smash/get/diva2:442409/FULLTEXT01 Elmendorf, W.R. (1967). Evaluation of the Functional Testing of Control Programs. Poughkeepsie, NY: IBM Systems Development Division. Retrieved from http://www.benderrbt.com/Evaluation%20of%20the%20Functional%20Testing%20of%20Control%20Programs%20-%201967.pdf Elmendorf, W. R. (1973), Cause-Effect graphs in functional testing, (Technical Report TR-00.2487). Poughkeepsie, NY: IBM Systems Development Division. Retrieved from
and Testing, that: “Output variables are not explicitly specified. But, we assume that there are ways to check if the expected output is obtained for any input” (p. 128) “Corresponding to these terms and definitions for the input, we can define output variable, space, vector, point, range (corresponding to input domain), etc. Since the output is only implicitly specified in most domain testing strategies, we omit the corresponding definitions.” (p. 129). We see this as a serious blind spot.
actually use the data that you entered. In this case, the input boundaries aren’t tightly enough coordinated to prevent a full-name string that is too long. Note how, in these cases, you delve into the underlying subject matter of the program. For example, you have to understand linear algebra to recognize that some equations pose more risk of error than others. You have to understand how the program uses the names to recognize the risk that the first-plus-middle-plus-last name can overflow a