Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Software Test Design

You're reading from   Software Test Design Write comprehensive test plans to uncover critical bugs in web, desktop, and mobile apps

Arrow left icon
Product type Paperback
Published in Dec 2022
Publisher Packt
ISBN-13 9781804612569
Length 426 pages
Edition 1st Edition
Concepts
Arrow right icon
Author (1):
Arrow left icon
Simon Amey Simon Amey
Author Profile Icon Simon Amey
Simon Amey
Arrow right icon
View More author details
Toc

Table of Contents (21) Chapters Close

Preface 1. Part 1 – Preparing to Test
2. Chapter 1: Making the Most of Exploratory Testing FREE CHAPTER 3. Chapter 2: Writing Great Feature Specifications 4. Chapter 3: How to Run Successful Specification Reviews 5. Chapter 4: Test Types, Cases, and Environments 6. Part 2 – Functional Testing
7. Chapter 5: Black-Box Functional Testing 8. Chapter 6: White-Box Functional Testing 9. Chapter 7: Testing of Error Cases 10. Chapter 8: User Experience Testing 11. Chapter 9: Security Testing 12. Chapter 10: Maintainability 13. Part 3 – Non-Functional Testing
14. Chapter 11: Destructive Testing 15. Chapter 12: Load Testing 16. Chapter 13: Stress Testing 17. Conclusion
18. Index 19. Other Books You May Enjoy Appendix – Example Feature Specification

Destructive Testing

"Is this a dagger which I see before me,

The handle toward my hand?"

- William Shakespeare, The Tragedy of Macbeth, Act 2, Scene 1

Destructive testing is a great way to find defects. By deliberately triggering specific errors, subsequent problems often occur. Even more so than error testing, as covered in Chapter 7, Testing of Error Cases, destructive testing gives you the chance to take the system out of its usual modes of operation to check its subsequent behavior.

These tests cover disabling communication with remote systems to check on retries and recovery. Your system cannot guarantee it will ever receive a reply to a message, so these scenarios need to be checked. Some subsystems are designed to be redundant, so we also consider testing that resilience. Disabling other subsystems will cause functional failures, so this measures their extent and recovery. Unfortunately, failures in remote systems will happen one day, so checking their...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime