Автор - Alan Page (його блоґ: angryweasel.com, твіттер: @alanpage), працює в Microsoft.
Книга невеличка, але чудова (коштує лише 2 бакси на leanpub), не така вже й нова (я її купив ще коли долар був по 8). Можливо, вона мені найбільше сподобалася через те, що думки автора щодо автоматизації збігаються з моїми:
Починається книга не автоматизацією, а розглядом тестування у розрізі "П’яти рівнів незнання":
0. Відсутність незнання. Я знаю щось. І можу це якось продемонструвати.
1. Відсутність знання. Я чогось не знаю. І можу чітко сформулювати питання, чого.
2. Відсутність розуміння. Я не знаю, чого не знаю.
3. Відсутність процесу. Я не знаю доступного способу дізнатися, що я не знаю, чого не знаю.
4. Ме́та-незнання. Я не знаю про п’ять рівнів незнання.
Алан стверджує, і я з ним погоджусь, що (дослідницьке) тестування направлене як раз на віднайдення способів дізнатися щось нове, тобто рівень 3. А повністю автоматизоване, чи scripted-підхід, може оперувати лише на рівні 1.
Це наче формальне пояснення, чому неможливо (принаймні поки що) усе автоматизувати. Бо без нових тестових ідей ми ніколи не дізнаємось, де у нас що могло б піти не так.
У книзі ви не знайдете відповіді на питання "Що ж автоматизувати?" чи "Як оце автоматизувати?" Натомість Алан хоче донести думку про те, що ці питання взагалі не треба ставити, що через ці питання слово на літеру "А" стало впливати на цілі організації, при тому що вплив "А" на якість продуктів зазвичай дуже опосередкований. І в багатьох організаціях "А" слугує головним чином лише одному - щоб відділ автоматизації був зайнятий.
Загалом, книга про те, що тестер має тестувати.
А як він це робить - клікаючи мишкою, чи написавши якийсь код, чи запустивши якусь тулзу для моніторингу стану речей - не важливо.
Що тестер має перш за все робити - це тренувати фантазію, вивчати продукт (реквайрменти, архітектуру, його код, його можливі інтерфейси і не тільки графічні) для однієї мети - для вироблення нових тестів.
Як каже Джеррі Вайнберг: Комп’ютер не помиляється, він просто дає вам можливість повторити вашу помилку мільйон разів.
Те саме і з автоматизацією. Вона найбільш корисна, коли збільшує можливості тестувальника заподіяти користь в рамках конкретної тестерської задачі. А вже як раз вигадати добру задачу, тобто тест, Алан у цій книзі називає однією з найважчих проблем у розробці ПЗ.
"Добрий тест-дизайн розглядає ручне та "із допомогою комп’ютера" як два види тестування, а не послідовні задачі... ідея такого підходу як: [пиши тести]->[запусти тести вручну]->[автоматизуй ці тести] - виглядає хибною від початку."
Багато написано щодо хибності підходу з інтенсивної автоматизації GUI, що 95% її - втрата часу. Дуже сподобалася фраза:
Ви маєте лише GUI, тільки коли ви тестите картинку.
Книга невеличка, але чудова (коштує лише 2 бакси на leanpub), не така вже й нова (я її купив ще коли долар був по 8). Можливо, вона мені найбільше сподобалася через те, що думки автора щодо автоматизації збігаються з моїми:
You should automate 100% of the tests that should be automated.
0. Відсутність незнання. Я знаю щось. І можу це якось продемонструвати.
1. Відсутність знання. Я чогось не знаю. І можу чітко сформулювати питання, чого.
2. Відсутність розуміння. Я не знаю, чого не знаю.
3. Відсутність процесу. Я не знаю доступного способу дізнатися, що я не знаю, чого не знаю.
4. Ме́та-незнання. Я не знаю про п’ять рівнів незнання.
Алан стверджує, і я з ним погоджусь, що (дослідницьке) тестування направлене як раз на віднайдення способів дізнатися щось нове, тобто рівень 3. А повністю автоматизоване, чи scripted-підхід, може оперувати лише на рівні 1.
Це наче формальне пояснення, чому неможливо (принаймні поки що) усе автоматизувати. Бо без нових тестових ідей ми ніколи не дізнаємось, де у нас що могло б піти не так.
У книзі ви не знайдете відповіді на питання "Що ж автоматизувати?" чи "Як оце автоматизувати?" Натомість Алан хоче донести думку про те, що ці питання взагалі не треба ставити, що через ці питання слово на літеру "А" стало впливати на цілі організації, при тому що вплив "А" на якість продуктів зазвичай дуже опосередкований. І в багатьох організаціях "А" слугує головним чином лише одному - щоб відділ автоматизації був зайнятий.
Загалом, книга про те, що тестер має тестувати.
А як він це робить - клікаючи мишкою, чи написавши якийсь код, чи запустивши якусь тулзу для моніторингу стану речей - не важливо.
Що тестер має перш за все робити - це тренувати фантазію, вивчати продукт (реквайрменти, архітектуру, його код, його можливі інтерфейси і не тільки графічні) для однієї мети - для вироблення нових тестів.
Як каже Джеррі Вайнберг: Комп’ютер не помиляється, він просто дає вам можливість повторити вашу помилку мільйон разів.
Те саме і з автоматизацією. Вона найбільш корисна, коли збільшує можливості тестувальника заподіяти користь в рамках конкретної тестерської задачі. А вже як раз вигадати добру задачу, тобто тест, Алан у цій книзі називає однією з найважчих проблем у розробці ПЗ.
"Добрий тест-дизайн розглядає ручне та "із допомогою комп’ютера" як два види тестування, а не послідовні задачі... ідея такого підходу як: [пиши тести]->[запусти тести вручну]->[автоматизуй ці тести] - виглядає хибною від початку."
Багато написано щодо хибності підходу з інтенсивної автоматизації GUI, що 95% її - втрата часу. Дуже сподобалася фраза:
Ви маєте лише GUI, тільки коли ви тестите картинку.
"The only time you only have a GUI is if you are testing a picture."
Також протягом усієї книжки Алан нагадує, що тест-дизайн - це не просто кілька наборів дій юзерів. Нові тести мають давати відповідь на питання "Що насправді тут діється?" та "Що насправді ми маємо взнати?" Автоматизовані дії кінцевих користувачів рідко дають такі відповіді. Тим більше, каже Алан в іншому розділі, Ви не є і ніколи не будете "кінцевим користувачем". В сенсі того, що Ви маєте вивчати, що вони роблять, така інформація дійсно дуже важлива, але це не має бути єдиним джерелом ідей для тестів.
Трапляються цікаві поради щодо тест-дизайну, ось деякі з них:
- "I'm bored!" heuristic. Автоматизуйте те, що вам набридло робити. Щойно ви кажете "Набридло!" - сідайте і автоматизуйте це!
- Автоматизація варта уваги, якщо вона використовує переваги комп’ютера - цикли, випадковість, змінні вхідні значення, великі навантаження.
- "A well-designed notepad test could just state File.Open(filename), and then use a randomly selected file open method. Too much UI automation doesn’t have this sort of abstraction and limits the effectiveness of the approach."
- Плануйте помилки! Усі зафейлені тести мають вам точно вказувати на те, що пішло не так!
- Пишіть інструменти, що дозволяють вам якнайшвидше знаходити важливі баги.
- Пишіть кілька високо-рівневих тестів, що показують, що користувацькі функції "працюють", але лишіть більшість на дослідження або юзер-тестінг (якщо у вас є засоби моніторингу).
- Якщо ви мусите писати GUI тести для вищезгаданого, пишіть їх менше. Так ви витратите менше часу на обстеження їхньої не певної поведінки.
Немає коментарів:
Дописати коментар