Сторінка 2 з 2
- ЩО ТАКЕ БАГ
- МЕТА ТЕСТУВАННЯ DECODED
- МИСТЕЦТВО СТВОРЕННЯ ТЕСТКЕЙСОВ
- ЦИКЛ РОЗРОБКИ ПО
- визначення Бага
- Три умови життя і процвітання Бага
- Що таке тестування
- Джерела очікуваного результату
- Функціональні баги і Баги Спека
Логічний закон виключеного третього говорить, що будь-яка річ - це або А, або не-А. Третього не дано, тобто якщо у вас є годинник «Брегет» за номером 5, то будь-яка річ у цьому світі буде або вашими годинами «Брегет» за номером 5, або чимось іншим.
Уявімо собі конвеєр, в кінці якого стоїмо ми. Стрічка конвеєра рухається, і перед нами по черзі з'являється по одному предмету. Завдання просте - очікувати появи ваших годин «Брегет» за номером 5 і говорити «баг» при появі будь-якого предмета, відмінного від них.
Неважко здогадатися, що такі предмети, як пакет кефіру, будильник «Слава», буклет з передвиборними обіцянками кандидата в президенти Н. будуть для нас багами.
Далі. Розглянемо, що об'єднує такі ситуації.
Якщо піднятися над яєчнею, яка фігурує в кожному з трьох пунктів, і абстрагуватися від жінок, карт і вина, то ми побачимо, що загальне - це відхилення фактичного від очікуваного.
- Очікуваний результат - дівчина вміє готувати.
Фактичний результат - ранок без сніданку. - Очікуваний результат - знання з тестування.
Фактичний результат - знання з кулінарії. - Очікуваний результат - яєчня буде приготовлена.
Фактичний результат - ще один ранок без сніданку.
визначення бага
Отже, баг (bug) - це відхилення фактичного результату (actual result) від очікуваного результату (expected result).
Відповідно до закону виключеного третього у нас є баг при наявності будь-якого фактичного результату, відмінного від очікуваного.
Три умови життя і процвітання бага
Конкретний баг живе і процвітає лише при одночасному виконанні всіх трьох умов:
- Відомий фактичний результат;
- Відомий очікуваний результат;
- Відомо, що результат з пункту 1 цієї статті не дорівнює результату з пункту 2.
Рада дня: кожен раз, коли виникає ситуація, в якій не збігаються фактичне і очікуване, - подумки штампів фактичне словом «баг». Поступово це увійде в звичку і стане рефлексом. Для ментальної тренування не має значення, наскільки дріб'язкові, низькі і сьогохвилинних ваші очікування, головне - придбання автоматизму.
Приклади багів з життя:
- Бутерброд падає маслом вниз.
- Підлабузники і балакуни мають набагато більше шансів на підвищення, ніж скромні чесні трудівники.
- Невідповідність миловидної зовнішності і зміїної суті.
- Папуга відтворює на людях найгірше з словникового запасу господаря.
- Автомобілі російського виробництва.
- Кот Бегемот в фільмі В. Бортко «Майстер і Маргарита».
Що таке тестування
Будь-яке тестування - це пошук багів. Відчуваємо ми нову соковижималку, спостерігаємо за поведінкою подруги або займаємося самокопанням - ми шукаємо баги. Баги знаходяться наступним чином:
- Ми дізнаємося (або вже знаємо) очікуваний результат;
- Ми дізнаємося (або вже знаємо) фактичний результат;
- Ми порівнюємо пункт 1 і пункт 2.
Як видно, кожен з нас вже є тестувальником, так як різного роду усвідомлені і неусвідомлені перевірки, здійснювані нами і щодо нас, є невід'ємною частиною життя, просто раніше ми непрофесійно хитали головою і видавали тиради про несправедливість світу, але зате тепер у разі неспівпадання фактичного та очікуваного ми будемо з посмішкою мудреця дивитися на дилетантів, хлюпають носами на московському вітрі, і тихо, але вагомо (як дон Карлеоне) говорити: «та-а-к, ще один баг».
Для ілюстрації правильного підходу приведу в приклад одного мого друга, який вибудував цілу систему доказів тези, що люди і комп'ютери створені по одному зразку. Основою його аргументації є той факт, що і ті й інші мають фізичну оболонку (тіло / залізо) і невловиме становить, котра управляє нею (душа / ПО). Відповідно хвороби тіла він називав багами в залозі, а проблеми з головою - багами в ПО і дуже шкодував, що ПО людей, які керують цим світом, складається в основному з багів.
Тепер згадаємо про те, що є комп'ютерне програмне забезпечення та що нам потрібно навчитися його тестувати.
З фактичним результатом тут більш-менш зрозуміло: потрібно змусити систему проявити себе і подивитися, що станеться.
Складніша справа з очікуваним результатом.
Джерела очікуваного результату
Основними джерелами очікуваного результату є:
Специфікація на першій-четвертій ролях - це не помилка, а наголос на те, що специфікація для тестувальника - це:
Специфікація важлива для програміста і тестувальника так само, як постанова пленуму ЦК для комуніста.
Специфікація - це інструмент, за допомогою якого ви зможете випустити якісний продукт і прикрити свою спину (в оригіналі звучить як CYA або cover your ass).
Отже, що ж це за звір?
Специфікація (або spec - читається «спік». Далі вживається в чоловічому роді) - це детальний опис того, як має працювати ПО. Ось так, ні багато ні мало.
У більшості випадків баг - це відхилення від специфікації (я говорю про компанії, в яких спеки в принципі існують і ними користуються).
Пункт 19.а спека # 8724 «Про реєстрацію нового користувача» встановлює: «Поле« Ім'я »має бути обов'язковим. Сторінка з помилкою повинна бути показана, якщо користувач посилає реєстраційну форму без заповнення зазначеного поля ».
Загалом все просто:
- тестувальник йде на сторінку з реєстраційною формою;
- клікає лінк «Реєстрація»;
- заповнює всі обов'язкові поля, крім поля «Ім'я»;
- натискає на кнопку «Зареєструватися».
Якщо помилка не відображено і реєстрація підтверджується, то це є момент істини і потрібно рапортувати баг (file a bug).
Якщо помилка показана, то щодо пункту 19.а на деякий час можна заспокоїтися. Ми зрозуміємо, чому можна заспокоїтися лише на деякий час при розмові про регрессионном тестуванні.
Функціональні баги і баги спека
Припустимо, що помилка була показана і ми маємо класичний випадок функціонального бага (functional bug, або баг звичайний), тобто бага, породженому на невідповідність фактичної роботи коду і функціонального спека.
Якщо ви уважно читали пункт 19.а, то не могли не помітити (жарт), що незрозуміло, яке повинно бути повідомлення про помилку (error message), тобто фактично рішення віддано на відкуп про-граммісту і він може передбачити, що при відповідній ситуації код видасть:
- Чи не інформативне повідомлення «Помилка» і залишить користувача ламати голову над тим, що він зробив неправильно, або
- інформативне повідомлення «PIN-ваше ім'я і натисніть кнопку« Реєстрація »»
і в будь-якому випадку формально буде прав, так як специфікація НЕ деталізує тексту помилки.
До речі, кілька років тому був випадок, коли програмісти в спеціальному ПО, розробленому для американських в'язниць, залишили «робоче» назву кнопки, причому тюремникам ідея так сподобалася, що вони просили нічого не виправляти. Напис на кнопці була: «Звільнити покидька».
Загалом склалася ситуація, коли сама специфікація має проблему, так як ми очікуємо (або принаймні повинні очікувати), що в спікся будуть подробиці про текст помилки, а в реальності їх там немає. Так і запишемо - «баг в специфікації» (spec bug).
До речі, ось варіанти розвитку ситуації з проблемним спеком:
- Швидше за все програміст все ж напише нформатівное повідомлення про помилку. Ваша справа послати емейл продюсеру (продюсером в інтернет компанії називають товариша, що створює спеки), щоб той вніс текст, вже написаний програмістом, в пункт 19.а.
- Якщо програміст написав щось таке, що суперечить здоровому глузду або стандарту, прийнятому у вашій компанії, рапорт баг.
- Може трапитися так, що ви не помітили проблеми в спікся і не помітили, як програміст написав повідомлення про помилку, яке суперечить здоровому глузду або стандарту, прийнятому у вашій компанії.
До речі, ось дві релевантні політично важливі речі:
- Як правило, робота в стартапі - це унікальний досвід, коли важка праця поєднується з радістю творення, розслабленої обстановкою (я, наприклад, вже багато років ходжу на роботу в шортах) і оточуючими вас милими, веселими людьми. Але бувають позаштатні ситуації (наприклад, робота не зроблена в термін або зроблена не якісно), і, коли справа дійде до з'ясування «хто винен» і «що з ним зробити», багато хто з ваших колег перестануть бути милими, веселими людьми і активно почнуть вішати собак один на одного. Так ось, щоб одну з цих собак не повісили на вас, надсилайте емейли, зберігайте їх і відповіді на них і при нагоді надсилайте їх зацікавленим сторонам. Стануть в нагоді ті емейли надалі - добре, не знадобляться - ще краще, тим більше що каші вони не просять, а сидять собі тихо і малодушно в своїх Фолдер і нічого не чекають від цього життя.
- Кожен повинен займатися своєю справою і відповідати за свою ділянку роботи. У разі якщо спік зроблений неякісно, то краще підняти тривогу з розсилкою емейлів, ніж робити припущення щодо того, як має працювати ваше ПО.
Перед завершенням теми про очікуване і фактичне результатах розглянемо приклади інших джерел очікуваного результату, крім спеков.
ЖИТТЄВИЙ ДОСВІД
Як справедливо зазначив Борис Слуцький: «Не тільки пиво-раки ми їли і хлебтали». Ми також вчилися і працювали, любили і ненавиділи, вірили політикам і не слухалися батьків, в загальному набували життєвий досвід (включаючи досвід роботи). Так ось цей досвід настільки корисний в нашому чорному справі, що для демонстрації поваги до ідеї про його корисності (разом з логікою і здоровим глуздом) я виніс її як епіграф у Вступі. Справа в тому, що тестування ПО - це те саме тестування (яке ми робимо постійно), але тільки щодо ПО. І моє завдання полягає лише в тому, щоб дати вам основні концепції та практичний інструментарій по інтернет-тестування і допомогти їх інтеграції з тим, що у вас вже є, - з життєвим досвідом.
ЗДОРОВИЙ СЕНС (дитя життєвого досвіду і відповідно внук «помилок важких»)
Це один з наших головних союзників, часом навіть і при наявності спека. Наприклад, ви тестируете веб-сайт, де користувач може завантажити (upload) свої цифрові фотографії. Спік каже, що користувач може завантажити лише одну фотографію за раз. А що, якщо у нього таких фотографій 200? Буде він щасливий? Що робимо? Правильно: пишемо е-мейл до [email protected] з пропозицією про включення в спік функціональності, що дозволяє користувачеві завантажувати цифрові фотографії оптом. До речі, баг такого раціоналізаторської плану лицемірно називається не багом, а Feature Request ( «запит про поліпшення» - поки зупинимося на такому перекладі).
Навіть найкращий спік може викликати необхідність уточнень. А що, якщо спека немає взагалі? Наша відповідь: спілкування. Радьтеся з колегами. Уточнюйте і обговорюйте. Одна голова добре а дві краще.
усталеного стандарту
Як правило, після реєстрації, користувач повинен отримати е-мейл з підтвердженням. Якщо спік не згадує про такий е-мейлі, ви можете зажадати доповнити його на підставі сформованої практики.
СТАТИСТИЧНІ ДАННІ
Було встановлено, що середній користувач втрачає терпіння, якщо web page (веб-сторінка) не завантажується в протягом 5 секунд. Ці дані можна використовувати, проводячи performance testing (тестування швидкості роботи всієї системи або її компонента). Як кажуть американці: «Your user is just one click away from your competitor» ( «Ваш користувач знаходиться на відстані в один клік від вашого конкурента»). Успіх вашого проекту - це щасливі користувачі. Перевищення 5 секунд - це перетворення веб-сайту в зал очікувань, в якому навряд чи хто захоче перебувати.
Це може бути, наприклад, думка вашого начальника.
Відзначимо, що баг (bug) буквально перекладається як «жук» або «комашка».
Тепер, як я і обіцяв, трохи історії.