В чём разница между Ad-hoc testing и Exploratory testing?

В чём разница между Ad-hoc testing и Exploratory testing

Это два часто путаемых подхода. За 10+ лет я использовал оба, и они имеют существенные различия.

Определения

Ad-hoc Testing

Определение: Неплановое, неструктурированное тестирование без предварительной подготовки.

Ad-hoc = "На лету"

Процесс:
1. Нет плана
2. Нет test cases
3. Просто тестирую что попало
4. Документирование минимальное
5. Часто случайные клики

Когда использую:

Если нужно быстро:
- Проверить critical issue
- Smoke test перед deployment
- Быстрая валидация
- Нет времени на подготовку

Exploratory Testing

Определение: Намеренное, творческое тестирование с целью найти неожиданные баги.

Exploratory = "Исследовательское"

Процесс:
1. Есть общая цель (но не детальный план)
2. Test cases создаются на лету
3. Тестирование направлено на discovery
4. Хорошее документирование
5. Много аналитического мышления

Когда использую:

Если нужно:
- Найти баги которые автомат пропустил
- Понять user experience
- Проверить edge cases
- Тестировать новую feature
- Выяснить что может пойти не так

Сравнительная таблица

Ad-hoc Testing

Характеристики

Процесс:
1. "Hey, can you quickly test this?"
2. I open app
3. Click random buttons
4. Scroll around
5. Enter random data
6. See if something breaks
7. Report if found

Документирование:
- Usually minimal
- Just "X is broken"
- No detailed steps

Плюсы

+ Very quick
+ No preparation needed
+ Good for emergency situations
+ Can catch obvious issues
+ No overhead

Минусы

- Hard to reproduce bugs
- Miss edge cases
- Inconsistent
- Bad documentation
- Not repeatable
- "I think something was wrong..."
- Time-wasting (inefficient)

Примеры Ad-hoc

Сценарий 1: Fire drill
PM: "We have to release in 30 minutes!"
QA: "Let me quickly test..."
- Open app
- Click main features
- "Looks ok, go ahead"

Сценарий 2: "Can you verify this quick fix?"
Developer: "Fixed payment button"
QA: "Ok, let me test"
- Click payment button
- Works
- "Good to go"

Exploratory Testing

Характеристики

Процесс:
1. Understand goal: "Test payment flow"
2. Test: Happy path
   - Add item
   - Go to checkout
   - Fill form
   - Submit
   - Verify confirmation

3. Test: Error cases
   - Invalid card
   - Insufficient funds
   - Network timeout

4. Test: Edge cases
   - Very large amount
   - Special characters in address
   - Rapid clicks

5. Document everything
   - What I tested
   - What I found
   - How to reproduce

6. Find: Rate limiting not applied
   - Created detailed bug report
   - Steps to reproduce
   - Severity: High

Плюсы

+ Find interesting bugs
+ Good bug documentation
+ Reproducible
+ Systematic approach
+ Can be repeated
+ Tests edge cases
+ Discovers user experience issues
+ Builds knowledge

Минусы

- Takes time
- Needs expertise
- Requires creativity
- Can be time-consuming
- Not everything documented (scope creep)

Примеры Exploratory

Сценарий 1: New feature testing
Developer finished: "New comment feature"
QA: "Let me explore this..."

1. Read feature description
2. Create comments
3. Edit comments
4. Delete comments
5. Reply to comments
6. Mention users (@john)
7. Use markdown in comment
8. Upload image in comment
9. Comment on someone else's post
10. Comment when not logged in
11. Test with XSS payload: <script>alert('xss')</script>
12. Test very long comment
13. Test unicode: 你好世界
14. Report findings: 3 bugs found

Сценарий 2: E-commerce explore
Goal: "Test user experience of checkout"

1. Browse products
2. Read reviews
3. Add to cart
4. Continue shopping
5. Modify quantity
6. Remove item
7. Apply coupon
8. Estimate shipping
9. Fill address
10. Select payment
11. Review order
12. Submit

Finding: Address form is confusing
- State dropdown doesn't work for all states
- Zip code doesn't validate correctly
- International addresses not supported

Document: Create detailed bug report with suggestions

Мой подход на практике

Когда использую Ad-hoc

1. Emergency (deployment in 1 hour)
   - Smoke test main features
   - Quick "does it work" check
   
2. Simple fixes
   - Bug fix: spelling error
   - Visual fix: button color
   - Quick validation
   
3. Developer testing request
   - Dev: "Can you verify this works?"
   - QA: "2-minute check"

Когда использую Exploratory

1. New feature testing
   - Feature just finished
   - 30-60 minutes exploration
   - Goal: Find issues before release
   
2. Critical functionality
   - Payment flow
   - Authentication
   - User profile
   - 60-120 minutes testing
   
3. After major refactor
   - Code changed significantly
   - Need to validate
   - 2-3 hours exploration
   
4. Pre-release testing
   - Before going to production
   - Thorough exploration
   - 4-8 hours testing

Фактические результаты

Ad-hoc Testing

Пример: Quick smoke test (5 minutes)
- Login works ✓
- Dashboard loads ✓
- Can create item ✓
- Result: "Looks OK"

Что я пропустил:
- Bulk operations
- Error handling
- Performance
- Security checks
- Edge cases

Exploratory Testing

Пример: Feature testing (60 minutes)
- Login works ✓
- Dashboard loads ✓
- Can create item ✓
- Can edit item ✓
- Can delete item ✓
- Bulk operations ✓
- Error handling:
  - Invalid input ✗ (found: no error message)
  - Network timeout ✗ (found: no retry)
  - Permission issue ✗ (found: wrong error)
- Performance ✓
- Security ✓
- Edge cases:
  - XSS test ✗ (found: potential vulnerability)
  - SQL injection ✗ (found: need validation)

Result: Found 5 bugs, documented all

Hybrid approach

Combined strategy

1. Ad-hoc smoke test (5 min)
   - Quick check if major features work
   - If something critical broken → stop
   - If OK → proceed

2. Exploratory testing (60 min)
   - Dive deeper
   - Find edge cases
   - Document findings
   - Create quality report

3. Regression tests (automated)
   - Run existing automation
   - Catch regressions
   - Quick feedback

Test case example

Ad-hoc approach

Test: Comment feature
Tester thinks:
"Let me just try adding a comment and see if it works"

Does:
1. Type comment
2. Click submit
3. "Yep, it worked"

Misses: Many edge cases

Exploratory approach

Test: Comment feature
Tester thinks:
"I need to understand this feature thoroughly"

Plans:
1. Comment lifecycle (create, read, update, delete)
2. Comments in different contexts
3. Permission scenarios
4. Input validation
5. Performance
6. Security

Executes:
1. Add comment ✓
2. Edit comment ✓
3. Delete own comment ✓
4. Try to delete others comment (should fail) ✓
5. Very long comment (10K chars)
   - Found: crashes UI
6. Special characters in comment
   - Found: breaks formatting
7. Comment when post deleted
   - Found: orphaned comments

Documents: 3 bugs, recommendations for improvement

Когда какой подход

Ad-hoc хороший для

✓ Emergency fixes
✓ Simple changes (spelling, colors)
✓ Quick validation
✓ Very tight deadline
✓ Developer sanity check

❌ Quality assurance
❌ Complex features
❌ Critical functionality
❌ Release validation

Exploratory хороший для

✓ New features
✓ Complex functionality  
✓ Critical paths
✓ Pre-release
✓ Quality focus
✓ Finding unexpected issues
✓ UX testing

❌ Time-critical situations
❌ Very simple changes
❌ When no time available

Заключение

Ad-hoc и Exploratory тестирование имеют разные цели.

Ad-hoc Testing:
- Быстро, неформально
- Когда срочно
- Поверхностная проверка
- Результат: "Работает" или "Не работает"

Exploratory Testing:
- Систематично, целенаправленно
- Когда есть время
- Глубокая проверка
- Результат: Полный отчет багов и наблюдений

Оба нужны:
- Ad-hoc для emergency
- Exploratory для quality

Мой рекомендация:
Используй exploratory testing везде где есть время.
Ad-hoc только когда срочно.

Идеальный workflow:
1. Smoke test (ad-hoc) - 5 минут
2. Exploratory testing - 60 минут  
3. Automated regression - непрерывно

С 10+ летами опыта я видел: exploratory testing находит баги которые плановое тестирование пропускает. Это инвестиция в качество.