book

Lessons Learned in Software Testing: A Context-Driven Approach

Name: Lessons Learned in Software Testing: A Context-Driven Approach
ISBN: 9780471081128

by Cem Kaner, James Bach, Bret Pettichord

December 2001

Beginner

352 pages

7h 27m

English

Wiley

Read now

Unlock full access

Copyright
FOREWORD
PREFACE
Welcome to Lessons Learned in Software TestingWho This Book Is ForWhat This Book Is AboutWhat This Book Is NotHow to Use This BookWe Hope This Book Stimulates Conversations and DebatesA Few Notes on Vocabulary
ACKNOWLEDGMENTS
1. The Role of the Tester
1.1. Lesson 1: You are the headlights of the project.1.2. Lesson 2: Your mission drives everything you do.1.3. Lesson 3: You serve many clients.1.4. Lesson 4: You discover things that will "bug" I someone whose opinion matters.1.5. Lesson 5: Find important bugs fast.1.6. Lesson 6: Run with the programmers.1.7. Lesson 7: Question everything, but not necessarily out loud.1.8. Lesson 8: You focus on failure, so your clients can focus on success.1.9. Lesson 9: You will not find all the bugs.1.10. Lesson 10: Beware of testing completely.1.11. Lesson 11: You don't assure quality by testing.1.12. Lesson 12: Never be the gatekeeper!1.13. Lesson 13: Beware of the not-my-job theory of testing.1.14. Lesson 14: Beware of becoming a process improvement group.1.15. Lesson 15: Don't expect anyone to understand testing, or what you need to do it well.
2. Thinking Like a Tester
2.1. Lesson 16: Testing is applied epistemology.2.2. Lesson 17: Studying epistemology helps you test better.2.3. Lesson 18: Testing is grounded in cognitive psychology.2.4. Lesson 19: Testing is in your head.2.5. Lesson 20: Testing requires inference, not just comparison of output to expected results.2.6. Lesson 21: Good testers think technically, creatively, critically, and practically.2.7. Lesson 22: Black box testing is not ignorance-based testing.2.8. Lesson 23: A tester is more than a tourist.2.9. Lesson 24: All tests are an attempt to answer some question.2.10. Lesson 25: All testing is based on models.2.11. Lesson 26: Intuition is a fine beginning, but a lousy conclusion.2.12. Lesson 27: To test, you must explore.2.13. Lesson 28: Exploring involves a lot of thinking.2.14. Lesson 29: Use the logic of abductive inference to discover conjectures.2.15. Lesson 30: Use the logic of conjecture and refutation to evaluate a product.2.16. Lesson 31: A requirement is a quality or condition that matters to someone who matters.2.17. Lesson 32: You discover requirements by conference, inference, and reference.2.18. Lesson 33: Use implicit as well as explicit specifications.2.19. Lesson 34: "It works" really means it appears to meet some requirement to some degree.2.20. Lesson 35: In the end, all you have is an impression of the product.2.21. Lesson 36: Don't confuse the test with the testing.2.22. Lesson 37: When testing a complex product: plunge in and quit.2.23. Lesson 38: Use heuristics to quickly generate ideas for tests.2.24. Lesson 39: You can't avoid bias, but you can manage it.2.25. Lesson 40: You're harder to fool if you know you're a fool.2.26. Lesson 41: When you miss a bug, check whether the miss is surprising or just the natural outcome of your strategy.2.27. Lesson 42: Confusion is a test tool.2.28. Lesson 43: Fresh eyes find failure.2.29. Lesson 44: Avoid following procedures unless they followed you first.2.30. Lesson 45: When you do create test procedures, avoid "1287."2.31. Lesson 46: One important outcome of a test process is a better, smarter tester.2.32. Lesson 47: You can't master testing unless you reinvent it.
3. Testing Techniques
3.1. Lesson 48: Testing combines techniques that focus on testers, coverage, potential problems, activities, and evaluation.3.2. Lesson 49: People-based techniques focus on who does the testing.3.3. Lesson 50: Coverage-based techniques focus on what gets tested.3.4. Lesson 51: Problems-based techniques focus on why you're testing (the risks you're testing for).3.5. Lesson 52: Activity-based techniques focus on how you test.3.6. Lesson 53: Evaluation-based techniques focus on how to tell whether the test passed or failed.3.7. Lesson 54: The classification of a technique depends on how you think about it.3.7.1. Addendum to Techniques3.7.2. How to Create a Test Matrix for an Input Field3.7.3. How to Create a Test Matrix for Repeating Issues3.7.4. How to Create a Traceability Matrix for Specification-Based Testing3.7.5. How to Do Combination Testing Using the All-Pairs Technique3.7.5.1. Start with Domain Partitioning3.7.5.2. Achieving All Singles3.7.5.3. Achieving All Pairs3.7.5.4. A Step-By-Step Example3.7.6. How to Analyze the Risks Associated with Some Item or Aspect of the Program3.7.6.1. Quality Attributes3.7.6.2. Problem Drivers3.7.6.3. Use Error Catalogs3.7.6.4. Use Up-to-Date Sources to Add to Your Error Catalogs
4. Bug Advocacy
4.1. Lesson 55: You are what you write.4.2. Lesson 56: Your advocacy drives the repair of the bugs you report.4.3. Lesson 57: Make your bug report an effective sales tool.4.4. Lesson 58: Your bug report is your representative.4.5. Lesson 59: Take the time to make your bug reports valuable.4.6. Lesson 60: Any stakeholder should be able to report a bug.4.7. Lesson 61: Be careful about rewording other people's bug reports.4.8. Lesson 62: Report perceived quality gaps as bugs.4.9. Lesson 63: Some stakeholders cannot report bugs-you're their proxy.4.10. Lesson 64: Draw the affected stakeholder's attention to controversial bugs.4.11. Lesson 65: Never use the bug-tracking system to monitor programmers' performance.4.12. Lesson 66: Never use the bug-tracking system to monitor testers' performance.4.13. Lesson 67: Report defects promptly.4.14. Lesson 68: Never assume that an obvious bug has already been filed.4.15. Lesson 69: Report design errors.4.16. Lesson 70: Extreme-looking bugs are potential security flaws.4.17. Lesson 71: Uncorner your corner cases.4.18. Lesson 72: Minor bugs are worth reporting and fixing.4.19. Lesson 73: Keep clear the difference between severity and priority.4.20. Lesson 74: A failure is a symptom of an error, not the error itself.4.21. Lesson 75: Do follow-up testing on seemingly minor coding errors.4.22. Lesson 76: Always report nonreproducible errors; they may be time bombs.4.23. Lesson 77: Nonreproducible bugs are reproducible.4.24. Lesson 78: Be conscious of the processing cost of your bug reports.4.25. Lesson 79: Give special handling to bugs related to the tools or environment.4.26. Lesson 80: Ask before reporting bugs against prototypes or early private versions.4.27. Lesson 81: Duplicate bug reports are a self-correcting problem.4.28. Lesson 82: Every bug deserves its own report.4.29. Lesson 83: The summary line is the most important line in the bug report.4.30. Lesson 84: Never exaggerate your bugs.4.31. Lesson 85: Report the problem clearly, but don't try to solve it.4.32. Lesson 86: Be careful of your tone. Every person you criticize will see the report.4.33. Lesson 87: Make your reports readable, even to people who are exhausted and cranky.4.34. Lesson 88: Improve your reporting skills.4.35. Lesson 89: Use market or support data when appropriate.4.36. Lesson 90: Review each other's bug reports.4.37. Lesson 91: Meet the programmers who will read your reports.4.38. Lesson 92: The best approach may be to demonstrate your bugs to the programmers.4.39. Lesson 93: When the programmer says it' s fixed, make sure it isn't still broken.4.40. Lesson 94: Verify bug fixes promptly.4.41. Lesson 95: When fixes fail, talk with the programmer.4.42. Lesson 96: Bug reports should be closed by testers.4.43. Lesson 97: Don't insist that every bug be fixed. Pick I your battles.4.44. Lesson 98: Don't let deferred bugs disappear.4.45. Lesson 99: Testing inertia should never be the cause of bug deferral.4.46. Lesson 100: Appeal bug deferrals immediately.4.47. Lesson 101: When you decide to fight, decide to win!
5. Automating Testing
5.1. Lesson 102: Speed the development process instead of trying to save a few dollars on testing.5.2. Lesson 103: Expand your reach instead of trying to repeat the same tests over and over.5.3. Lesson 104: Select your automation strategy based on your context.5.4. Lesson 105: Don't mandate 100 percent automation.5.5. Lesson 106: A test tool is not a strategy.5.6. Lesson 107: Don't automate a mess.5.7. Lesson 108: Don't equate manual testing to automated testing.5.8. Lesson 109: Don't estimate the value of a test in terms of how often you run it.5.9. Lesson 110: Automated regression tests find a minority of the bugs5.10. Lesson 111: Consider what bugs you aren't finding while you automate tests.5.11. Lesson 112: The problem with bad automation is that no one may notice.5.12. Lesson 113: Capture replay fails.5.13. Lesson 114: Test tools are buggy.5.14. Lesson 115: User interfaces change.5.15. Lesson 116: Select GUI test tools based on compatibility, familiarity, and service.5.16. Lesson 117: Automated regression tests die.5.17. Lesson 118: Test automation is a software development process.5.18. Lesson 119: Test automation is a significant investment.5.19. Lesson 120: Test automation projects require skills in programming, testing, and project management.5.20. Lesson 121: Use pilot projects to prove feasibility.5.21. Lesson 122: Have testers and programmers charter automation projects.5.22. Lesson 123: Design automated tests to facilitate review.5.23. Lesson 124: Don't skimp on automated test design.5.24. Lesson 125: Avoid complex logic in your test scripts.5.25. Lesson 126: Don't build test libraries simply to avoid repeating code.5.26. Lesson 127: Data-driven test automation makes it easy to run lots of test variants.5.27. Lesson 128: Keyword-driven test automation makes it easy for nonprogrammers to create tests.5.28. Lesson 129: Use automated techniques to generate test inputs.5.29. Lesson 130: Separate test generation from test execution.5.30. Lesson 131: Use standard scripting languages.5.31. Lesson 132: Automate tests using programming interfaces.5.32. Lesson 133: Encourage the development of unit test suites.5.33. Lesson 134: Beware of using automators who don't understand testing.5.34. Lesson 135: Avoid automators who don't respect testing.5.35. Lesson 136: Testability is often a better investment than automation.5.36. Lesson 137: Testability is visibility and control.5.37. Lesson 138: Start test automation early.5.38. Lesson 139: Give centralized automation teams clear charters.5.39. Lesson 140: Automate for immediate impact.5.40. Lesson 141: You may have more test tools than you realize.
6. Documenting Testing
6.1. Lesson 142: To apply a solution effectively, you need to understand the problem clearly.6.2. Lesson 143: Don't use test documentation templates: A template won't help unless you don't need it.6.3. Lesson 144: Use test documentation templates: They foster consistent communication.6.4. Lesson 145: Use the IEEE Standard 829 for test documentation.6.5. Lesson 146: Don't use the IEEE Standard 829.6.6. Lesson 147: Analyze your requirements before deciding what products to build; this applies as much to your documentation as to your software.6.7. Lesson 148: To analyze your test documentation requirements, ask questions like the ones in this list.6.8. Lesson 149: Summarize your core documentation requirements in one sentence with no more than three components.

7. Interacting with Programmers
7.1. Lesson 150: Understand how programmers think.7.2. Lesson 151: Develop programmers' trust.7.3. Lesson 152: Provide service.7.4. Lesson 153: Your integrity and competence will demand respect.7.5. Lesson 154: Focus on the work, not the person.7.6. Lesson 155: Programmers like to talk about their work. Ask them questions.7.7. Lesson 156: Programmers like to help with testability.
8. Managing the Testing Project
8.1. Lesson 157: Create a service culture.8.2. Lesson 158: Don't try to create a control culture.8.3. Lesson 159: Develop the power of the king's ear.8.4. Lesson 160: You manage the subproject that provides testing services, not the development project.8.5. Lesson 161: All projects evolve. Well-run projects evolve well.8.6. Lesson 162: There are always late changes.8.7. Lesson 163: Projects involve a tradeoff among features, reliability, time, and money.8.8. Lesson 164: Let the project manager choose the project lifecycle.8.9. Lesson 165: Waterfall lifecycles pit reliability against time.8.10. Lesson 166: Evolutionary lifecycles pit features against time.8.11. Lesson 167: Be willing to allocate resources to the project early in development.8.12. Lesson 168: Contract-driven development is different from market-seeking development.8.13. Lesson 169: Ask for testability features.8.14. Lesson 170: Negotiate the schedules for builds.8.15. Lesson 171: Understand what programmers do (and don't do) before delivering builds.8.16. Lesson 172: Be prepared for the build.8.17. Lesson 173: Sometimes you should refuse to test a build.8.18. Lesson 174: Use smoke tests to qualify a build.8.19. Lesson 175: Sometimes, the right decision is to stop the test and fix cycle and redesign the software.8.20. Lesson 176: Adapt your processes to the development practices that are actually in use.8.21. Lesson 177: "Project documents are interesting fictions: Useful, but never sufficient."8.22. Lesson 178: Don't ask for items unless you will use them.8.23. Lesson 179: Take advantage of other sources of information.8.24. Lesson 180: Flag configuration management problems to the project manager.8.25. Lesson 181: Programmers are like tornadoes.8.26. Lesson 182: Great test planning makes late changes easy.8.27. Lesson 183: Test opportunities arise whenever one person hands off an artifact to another.8.28. Lesson 184: There is no universal formula for knowing how much testing is enough.8.29. Lesson 185: "Enough testing" means "enough information for my clients to make good decisions."8.30. Lesson 186: Never budget for just two testing cycles.8.31. Lesson 187: To create a schedule for a set of tasks, estimate the amount of time needed for each task.8.32. Lesson 188: The person who will do the work should tell you how long a task will take.8.33. Lesson 189: There is no right ratio of testers to other developers.8.34. Lesson 190: Trade tasks or transfer people from tasks that they are failing at.8.35. Lesson 191: Rotate testers across features.8.36. Lesson 192: Try testing in pairs.8.37. Lesson 193: Assign a bug hunter to the project.8.38. Lesson 194: Charter testing sessions, especially exploratory testing sessions.8.39. Lesson 195: Test in sessions.8.40. Lesson 196: Use activity logs to reveal the interruptions that plague testers' work.8.41. Lesson 197: Regular status reports are powerful tools.8.42. Lesson 198: There's nothing more dangerous than a vice president with statistics.8.43. Lesson 199: Be cautious about measuring the project's progress in terms of bug counts.8.44. Lesson 200: The more independent coverage measures you use, the more you know.8.45. Lesson 201: Use a balanced scorecard to report status on multiple dimensions.8.46. Lesson 202: Here's a suggested structure for a weekly status report.8.47. Lesson 203: A project dashboard is another useful way for showing status.8.48. Lesson 204: Milestone reports are useful when milestones are well defined.8.49. Lesson 205: Don't sign-off to approve the release of a product.8.50. Lesson 206: Do sign-off that you have tested a product to your satisfaction.8.51. Lesson 207: If you write a release report, describe your testing work and results, not your opinion of the product.8.52. Lesson 208: List unfixed bugs in the final release report.8.53. Lesson 209: A useful release report lists the 10 worst things critics might say.
9. Managing the Testing Group
9.1. Lesson 210: Mediocrity is a self-fulfilling prophecy.9.2. Lesson 211: Treat your staff as executives.9.3. Lesson 212: Read your staffs bug reports.9.4. Lesson 213: Evaluate your staff as executives.9.5. Lesson 214: If you really want to know what' s going on, test with your staff.9.6. Lesson 215: Don't expect people to handle multiple projects efficiently.9.7. Lesson 216: Build your testing staffs domain expertise.9.8. Lesson 217: Build your testing staffs expertise in the relevant technology.9.9. Lesson 218: Work actively on skills improvement.9.10. Lesson 219: Review technical support logs.9.11. Lesson 220: Help new testers succeed.9.12. Lesson 221: Have new testers check the documentation against the software.9.13. Lesson 222: Familiarize new testers with the product through positive testing.9.14. Lesson 223: Have novice testers edit old bug reports before writing new ones.9.15. Lesson 224: Have new testers retest old bugs before testing for new bugs.9.16. Lesson 225: Don't put novice testers on nearly finished projects.9.17. Lesson 226: The morale of your staff is an important asset.9.18. Lesson 227: Don't let yourself be abused.9.19. Lesson 228: Don't abuse your staff with overtime.9.20. Lesson 229: Don't let your staff be abused.9.21. Lesson 230: Create training opportunities.9.22. Lesson 231: Your hiring decisions are your most important decisions.9.23. Lesson 232: Hire contractors to give you breathing room during recruiting.9.24. Lesson 233: Rarely accept rejects from other groups into testing.9.25. Lesson 234: Plan in terms of the tasks you need to do in your group and the skills needed to do them.9.26. Lesson 235: Staff the testing team with diverse backgrounds.9.27. Lesson 236: Hire opportunity candidates.9.28. Lesson 237: Hire by consensus.9.29. Lesson 238: Hire people who love their work.9.30. Lesson 239: Hire integrity.9.31. Lesson 240: During the interview, have the tester demonstrate the skills you're hiring him for.9.32. Lesson 241: During the interview, have the tester demonstrate skills he'll actually use on the job over informal aptitude tests.9.33. Lesson 242: When recruiting, ask for work samples.9.34. Lesson 243: Hire quickly after you make up your mind.9.35. Lesson 244: Put your hiring promises in writing and keep them.
10. Your Career in Software Testing
10.1. Lesson 245: Choose a career track and pursue it.10.2. Lesson 246: Testers' incomes can be higher than programmers' incomes.10.3. Lesson 247: Feel free to change your track and pursue something else.10.4. Lesson 248: Whatever path you take, pursue it actively.10.5. Lesson 249: Extend your career beyond software testing.10.6. Lesson 250: Extend your career beyond your company.10.7. Lesson 251: Conferences are for conferring.10.8. Lesson 252: Lots of other companies are as screwed up as yours.10.9. Lesson 253: If you don't like your company, look for a different job.10.10. Lesson 254: Be prepared in case you have to bet your job (and lose).10.11. Lesson 255: Build and maintain a list of companies where you'd like to work.10.12. Lesson 256: Build a portfolio.10.13. Lesson 257: Use your resume as a sales tool.10.14. Lesson 258: Get an inside referral.10.15. Lesson 259: Research salary data.10.16. Lesson 260: If you're answering an advertisement, tailor your answer to the advertisement.10.17. Lesson 261: Take advantage of opportunities to interview.10.18. Lesson 262: Learn about companies when you apply for jobs with them.10.19. Lesson 263: Ask questions during job interviews.10.20. Lesson 264: Negotiate your position.10.21. Lesson 265: Be cautious about Human Resources.10.22. Lesson 266: Learn Perl.10.23. Lesson 267: Learn Java or C++.10.24. Lesson 268: Download demo copies of testing tools and try them out.10.25. Lesson 269: Improve your writing skills.10.26. Lesson 270: Improve your public speaking skills.10.27. Lesson 271: Think about getting certified.10.28. Lesson 272: If you can get a black belt in only two weeks, avoid fights.10.29. Lesson 273: A warning about the efforts to license software engineers.
11. Planning the Testing Strategy
11.1. Lesson 274: Three basic questions to ask about test strategy are "why bother?", "who cares?", and "how much?"11.2. Lesson 275: There are many possible test strategies.11.3. Lesson 276: The real test plan is the set of ideas that guides your test process.11.4. Lesson 277: Design your test plan to fit your context.11.5. Lesson 278: Use the test plan to express choices about strategy, logistics, and work products.11.6. Lesson 279: Don't let logistics and work products blind you to strategy.11.7. Lesson 280: How to lie with test cases.11.8. Lesson 281: Your test strategy is more than your tests.11.9. Lesson 282: Your test strategy explains your testing.11.10. Lesson 283: Apply diverse half-measures.11.11. Lesson 284: Cultivate the raw materials of powerful test strategies.11.12. Lesson 285: Your first strategy on a project is always wrong.11.13. Lesson 286: At every phase of the project, ask yourself "what can I test now and how can I test it?"11.14. Lesson 287: Test to the maturity of the product.11.15. Lesson 288: Use test levels to simplify discussions of test complexity.11.16. Lesson 289: Test the gray box.11.17. Lesson 290: Beware of ancestor worship when reusing test materials.11.18. Lesson 291: Two testers testing the same thing are probably not duplicating efforts.11.19. Lesson 292: Design your test strategy in response to project factors as well as product risks.11.20. Lesson 293: Treat test cycles as the heartbeat of the test process.11.21. How To Evolve a Context-Driven Test Plan11.21.1. 1. Monitor major test planning challenges.11.21.2. 2. Clarify your mission.11.21.2.1. MISSION ELEMENTS TO CONSIDER11.21.2.2. POSSIBLE WORK PRODUCTS11.21.3. 3. Analyze the product.11.21.3.1. WHAT TO ANALYZE11.21.3.2. WAYS TO ANALYZE11.21.3.3. POSSIBLE WORK PRODUCTS11.21.4. 4. Analyze product risk.11.21.4.1. WHAT TO ANALYZE11.21.4.2. WAYS TO ANALYZE11.21.4.3. POSSIBLE WORK PRODUCTS11.21.5. 5. Design the test strategy.11.21.5.1. CONSIDER TECHNIQUES FROM FIVE PERSPECTIVES11.21.5.2. WAYS TO PLAN11.21.5.3. POSSIBLE WORK PRODUCTS11.21.6. 6. Plan logistics.11.21.6.1. LOGISTICAL AREAS11.21.6.2. POSSIBLE WORK PRODUCTS11.21.7. 7. Share the plan.11.21.7.1. WAYS TO SHARE11.21.7.2. GOALS11.22. How Good Is This Test Plan?11.22.1. Terms and Concepts11.22.2. The Functions of a Test Plan11.22.3. Test Plan Quality Criteria11.22.4. Test Plan Heuristics
A. The Context-Driven Approach to Software Testing
A.1. The Seven Basic Principles of the Context-Driven SchoolA.2. Illustrations of the Principles in Action:A.3. An ExampleA.4. Members of the Context-Driven School
Bibliography
-A--B--C--D--E--F--G--H--I--J--K--L--M--N--O--P--R--S--T--W--Y--Z-

Content preview from Lessons Learned in Software Testing: A Context-Driven Approach

Bibliography

-A-

Phil. Agre, 2001. Networking on the Network. Available at dlis.gseis.ucla.edu/people/pagre/network.html.

Ståle. Amland, 1999. Risk Based Testing and Metrics. Available at www.amland.no/Word%20Documents/EuroSTAR%20'99%20Paper.doc.

Stefan. Asböck, 2000. load testing for eConfidence. Lexington, MA: Segue Software, Inc. Available via www.segue.com.

Association for Computing Machinery. 2000. A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession. Available at www.acm.org/serving/se_policy/selep_main.html.

Robert. Austin, 1996. Measuring and Managing Performance in Organizations. New York: Dorset House Publishing.

-B-

James Bach,, 1999a. Reframing Requirements Analysis. IEEE Computer 32:6. 113–114.

James Bach,, 1999b. A Low Tech Testing Dashboard. Available at /www.satisfice.com/presentations/dashboard.pdf.

James Bach,, 1999c. James Bach on Risk-Based Testing. STQE Magazine. vol. 1 #6.

Jonathan. Baron, 1994. Thinking and Deciding. Cambridge: Cambridge University Press.

Kent Beck,, 1999. Extreme Programming Explained. Reading, Massachusetts: Addison-Wesley.

Kent Beck,, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick. R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland, D. Thomas. 2001. Manifesto for Agile Software Development [online]. Available at www.agilealliance.org/.

Boris. Beizer, 1990. Software Testing Techniques, 2nd edition. Boston: International Thompson ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9780471081128Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Lessons Learned in Software Testing: A Context-Driven Approach

by Cem Kaner, James Bach, Bret Pettichord

Bibliography

-A-

-B-

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.