фабпждфуквп. Савин Тестирование dot-com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
party bug, и вы в обоих случаях спокойно его закроете. Жизнь замечательных багов 245 Важно: в обоих случаях (когда мы не можем/можем повлиять на производителя не нашего ПО) наш программист может ошибочно допустить, что проблема в не нашем ПО, хотя на самом деле это наш баг. В этом случае тестировщик делает: Resolution — Assigned Assigned to — имя программиста. No longer applicable (поезд ушел) Такое значение резолюции присваивается багу, который раньше действительно был багом, но теперь по какой-то причине тако- вым не является. Например мы исполняем тест-кейс по проверке одного из флоу функционально- сти "Оплата" и видим, что отсутствует поле для ввода номера CW2. Мы заносим баг и получаем его обратно с резолюцией No Longer Applicable и комментарием программиста, что согласно багу #7723 с типом "Fea- ture Request" мы больше не должны спрашивать CW2 у пользователя. Таким образом, до занесения продюсером бага #7723 ситуация с от- сутствующим CW2 была бы багом, а теперь это не баг. Баги, возвращенные с резолюцией No longer applicable, как пра- вило, возникают из-за отсутствия информации. В моей практике, если фактический результат после исполнения тест-кейса расходится с ожидаемым результатом по этому тест-кей- су, я пытаюсь воспроизвести баг заново, и если он воспроизводится, то я сразу же заношу его в СТБ. Если же я вижу проблему, которая не связана с моим ожидаемым результатом и/или функциональ- ностью, о которой я имею полную информацию, то обычно контак- тирую с коллегами-тестировщиками, которые владеют вопросом о функциональности, в которой, как мне кажется, есть баг. Резолюция No longer applicable позволяет закрыть баг, если он на самом деле больше не баг. Процесс трэкинга багов Теперь, после того как мы поговорили об атрибутах СТБ, посмот- рим на блок-схему. На ней мы воочию видим основу процесса трэкинга багов. Эта основа сама по себе является стандартной версией процесса, и интернет-компании используют ее в таком либо измененном виде. 246 Тестирование Дот Ком. Часть 3 Процесс трэкинга багов Жизнь замечательных багов 247 Кстати, для упрощения допустим, что баг заносится тестиров- щиком (хотя мы знаем, что баг может заноситься кем угодно) и против кода программиста (хотя мы знаем, что существуют и баги спека, которые заносятся против продюсера). Давайте сделаем так: • сначала рассмотрим процесс концептуально, затем • привяжем к каждой его стадии наши атрибуты (детальное рассмотрение процесса), затем • приведем конкретный пример. Концептуальное рассмотрение процесса трэкинга багов Задача 1: После того как мы нашли проблему в ПО, заносим новый баг. Задача 2: Программист получает баг, старается понять, в чем про- блема, и если это действительно баг, то Задача 3: Программист начинает ремонт. Задача 4: После того как ремонт закончен, программист должен сделать checkin кода в CVS. Задача 5: Релиз-инженер запускает новый билд, чтобы от- ремонтированный код пришел из CVS на тест-ма- шину. Задача 6: Тестировщик проводит регрессивное тестирова- ние, и если починка НЕ удалась, то Задача 7: Баг возвращается программисту на но- вый ремонт. Если же починка удалась, то Задача 8: Баг закрывается. Goodbye my love, Goodbye. Идем обратно к развилке после задачи 2. Допустим, программист не считает, что зарапортованная ситуация является багом. Тогда он: Задача 9: Возвращает баг. Задача 10: Тестировщик старается понять свою ошибку, и если ошибка имела место и баг соответственно места не имел, то Задача 8: Баг закрывается. Если же тестировщик считает, что это все-таки баг, то баг отправляется обратно программисту. Задача 2: Программист снова пытается понять, баг ли это. И т.д. 248 Тестирование Дот Ком. Часть 3 Детальное рассмотрение процесса Давайте вольем в рассмотренную форму содержимое, состоящее из атрибутов и их значений, как мы хотим это нашей компании www.testshop.rs. Задача 1: Атрибут Комментарий по заполнению либо конкретное(ые) значение(я) атрибута Summary Краткое описание Description and Steps to Reproduce Описание и шаги... Attachment Используем это поле, если нужна дополнительная иллюстрация Assigned to Имя программиста Component Название компонента Found on Где был найден баг Version Found Номер версии Build Found Номер билда Severity Значение серьезности Priority Значение приоритета Notify list По минимуму — имя продюсера Type "Bug" Resolution "Assigned" Задача 2: Программист признает, что это баг: Задача 3: Resolution "Fix in Progress" Задача 4: Resolution "Fixed" Version Fixed Номер версии Build Fixed Номер билда Assigned to Имя релиз-инженера Задача 5: Resolution "Build in Progress" Жизнь замечательных багов 249 и после того, как новый билд появился на тест-машине: Resolution "Verify" Assigned to Имя лица из Verifier Задача 6: Баг НЕ починен: Задача 7: Resolution "Verification Failed" Assigned to Имя программиста Баг починен: Задача 8: Resolution "Fix is Verified" Status "Closed" Обратно к задаче 2: Программист НЕ признает, что это баг: Задача 9: Resolution "Can't Reproduce", либо "Duplicate", либо "Not a bug", либо "3rd party bug", либо "No longer applicable" Assigned to Имя тестировщика Задача 10: Баг: Resolution "Assigned" Assigned to Имя программиста HE баг: Status "Closed" Конкретный пример Тестировщик Антон Никонов при исполнении тест-кейса #NBST0001 обнаружил новый баг. Он открывает СТБ и заносит в нее нового жителя: 250 Тестирование Дот Ком. Часть 3 Атрибут: Summary. Значение: "Спек. 1211: неверное значение колонки result таблицы cc_transaction для VISA ". Атрибут: Description and steps to reproduce. Значение: "Description: При оплате картой VISA в колонке result таблицы cc_transaction в базе данных записывается неверное значение. Используйте следующую информацию для воспроизведения проблемы: Эккаунт: testuser1/pa$$wOrd Наименование товара: book117 Данные карты: Номер: 9999-5148-2222-1277 Окончание действия: 12/07 CVV2: 778 SQL1: select result from cc_transaction where id — <номер заказа>; Steps to reproduce: 1. Открой www.main.testshop.rs. 2. Введи имя пользователя. 3. Введи пароль. 4. Нажми кнопку "Войти ". 5. Введи наименование товара в поле поиска. 6. Нажми кнопку "Найти ". 7. Кликни линк "Добавить в корзину ". 8. Кликни линк "Корзина". 9. Кликни линк "Оплатить". 10. Выбери вид карты. 11. Введи номер карты. 12. Введи срок окончания действия. 13. Введи CVV2. 14. Нажми кнопку "Завершить заказ". 15. Запиши номер заказа. 16. Запроси базу данных с SQL1. Bug: 20. Expected: 10". Жизнь замечательных багов 251 Атрибут: Assigned to. Мистер Никонофф идет на страничку в интранете "Кто ответст- вен за что" и видит, что программистом Оплаты в настоящее время является О. Столяров. Так и запишем. Значение: "О. Столяров". Атрибут: Component Значение: "Оплата ". Атрибут: Found on. Баг был найден при тестировании на www.main.testshop.rs. Значение: "www.main.testshop.rs". Атрибут: Version Found. Антон знает, что номер версии и номер билда видны в коммента- риях HTML-кода на всех страницах нашего веб-сайта. Поэтому он открывает в окне браузера www.main.testshop.rs, делает клик пра- вой кнопкой мышки и выбирает View Page Source (посмотреть код страницы). Запускается текстовый редактор, например Note- pad (Блокнот), в котором виден HTML-код страницы, и в коммен- тариях Антон находит номер версии и номер билда, например 7.0-58. Значение: "7.0". Атрибут: Build Found. Значение: "55". Атрибут: Severity. Это обычный функциональный баг, четко подходящий под СЗ. Значение: "С5 ". Атрибут: Priority. Мы должны понять, какие будут последствия в случае если зна- чение колонки result таблицы cc_transaction не равно 10 при оп- лате карточкой VISA. Мы задаем вопрос программисту, и выясня- ется, что в этом случае на машине для пользователей транзакция будет считаться недействительной, даже если деньги с карточ- ку будут сняты и соответственно пользователь не получит своего 252 Тестирование Дот Ком. Часть 3 заказа. Довольно серьезный баг, если учесть, что VISA — это наи- более широко используемая платежная система. Исходя из вышесказанного, мы должны дать багу приоритет П1. Значение: "Я7 ". Атрибут: Notify list. Согласно странице интранета "Кто ответствен за что", оплата ку- рируется продюсером В. Новоселовым. Значение: "5. Новоселов". Атрибут: Туре. Значение: "Bug". Атрибут: Resolution. Мы знаем имя программиста, который должен заняться багом, и поэтому ставим резолюцию как "Assigned". Значение: "Assigned". СТБ присвоила багу номер 3221. После того как баг был занесен, е-мейлы летят к • А. Никонову (Submitted by — автор бага), • О. Столярову (Assigned to — держатель бага) и • В.Новоселову (лицо из Notify list). Поскольку держателем бага стал Олег Столяров, то за ним и сле- дующее действие, а именно рассмотрение проблемы. Проблема рассмотрена, и баг найден в коде Python файла create_payment.py: ifcredit card== "VISA": update _db(" update cc transaction set result = 20 where exter- nal id = " + transaction id). Этот код, переведенный на язык Пушкина и Булгакова, означает: Если используется кредитная карта VISA, сделай значение колонки result таблицы cc_transaction рав- ным 20 в строке, где значение колонки externalid равно значению переменной transactionid. Жизнь замечательных багов 253 Как видим, это простой в починке баг, который исправляется из- менением цифры 2 на цифру 1: if credit card == "VISA ": update_db("update cc transaction set result — 10 where exter- nal id - " + trans action id). Олежек входит в СТБ: Атрибут: Resolution. Значение: "Fix in Progress ". Олежек исправляет баг на своем плэйграунде, делает скоренький юнит-тест и сохраняет баг в бранче CVS для релиза 7.0 и в стволе. Затем он снова входит в СТБ и передает баг дальше: Атрибут: Resolution. Значение: "Fixed". Атрибут: Version Fixed. Значение: "7.0". Атрибут: Build Fixed. Значение: "59". Сегодня вторник, а значит, согласно страничке в интранете "Рас- писание релиз-инженеров", новый билд может запустить для нас релиз-инженер С. Щетинин, который сегодня находится на де- журстве по всем вопросам, связанным с багами. Атрибут: Assigned to. Значение: "С. Щетинин". С. Щетинин, только что вернувшийся с обильного обеда, про- шедшего в ресторане "Mayflower" в окружении институтских дружков, таких же, как он, тунеядцев и игроков в покер, получает от СТБ е-мейл о том, что он стал новым держателем бага #3221. С. Щетинин является держателем и множества других багов, ждущих своего регрессивного тестирования. Согласно распи- санию билдов в компании www.testshop.rs, у нас есть 3 билда 254 Тестирование Дот Ком. Часть 3 в день: в 12:00, 15:00, 18:00 по московскому времени. Сейчас 14:45, и через 15 минут Станислав должен запустить новый очередной билд (59) для версии 7.0. Запустив билд-скрипт для версии 7.0, он входит в СТБ и среди прочих меняет и #3221: Атрибут: Resolution. Значение: "Build in Progress ". После того как билд-тест сайта www.main.testshop.rs завершен и не было никаких ошибок (например, проблем с интеграцией кода одного программиста с кодом другого), сеньор Щетинин снова идет в СТБ: Атрибут: Resolution. Значение: "Verify". Атрибут: Assigned to. Значение: "А. Никонов". Если ошибки поломали билд, то начинается выяснение и устра- нение. Ошибка может быть допущена как релиз-инженером, так и программистом. В последнем случае срочно посылают е-мейлы программистам с целью выяснить, чем код поломал билд, чтобы те немедленно разобрались, в чем дело. Если проблема сломан- ного билда (broken build) не решается в течение, скажем, 60 ми- нут, то, согласно правилам нашей компании, С. Щетинин воз- вращает на www.main.testshop.rs предыдущий билд, т.е. 58. Тестировщик Антон Никонов получает радостное известие, что баг #3221 был зафиксирован и отремонтированный код ждет его на www.main.testshop.rs. Удостоверившись, что www.main.testshop.rs имеет версию и билд 7.0-59, он исполняет шаги, указанные в "Описании и шагах..." бага, и, удостоверившись, что значение result стало равным 10, закрывает баг: Атрибут: Resolution. Значение: "Fix is Verified". Атрибут: Status. Значение: "Closed". Жизнь замечательных багов 255 А затем в качестве второй части регрессивного тестирования ис- полняет, например, тест-кейс с картой MasterCard. Флоу с MasterCard — это приоритетное флоу функциональности Оплата, и неплохая идея проверить, что ремонт ситуации с VISA не сломал флоу с MasterCard. Краткое подведение итогов 1. СТБ —это • с одной стороны, хранилище багов, а • с другой — средство коммуникации. 2. Баг — это в зависимости от контекста • расхождение между фактическим и ожидаемым результатами и/или • запись (виртуальная карточка) в СТБ. 3. Настройки СТБ определяются процессом, а не наоборот. 4. Настройками СТБ и созданием эккаунтов ведает администратор СТБ. 5. Занести баг может любой, у кого есть счет в СТБ и соответст- вующая привилегия. 6. У бага в СТБ есть атрибуты, значения которых позволяют судить о состоянии и истории бага. 7. Значения некоторых атрибутов присваиваются автоматически (номер бага). 8. Мы никогда не заносим баг с кратким описанием "Ничего не работает". 9. Приложение (attachment) — это суперполезная вещь, так как служит графической (как правило) иллюстрацией бага. 10. У каждого открытого бага всегда есть держатель. 11. На интранете обязательно должна быть страничка "Кто ответ- ственен за что". 12. Серьезность бага —это техническая категория. 13. Приоритет бага — категория, связанная с бизнесом. 14. Нет ни одного изменения бага, которое бы не стало достоянием гласности. 15. Функциональность — это только одно из значений емкого тер- мина фича. 16. Значения резолюции — это этапы жизни бага. Вопросы и задания для самопроверки 1. Могут ли простые бумажные карточки или текстовый файл слу- жить в качестве СТБ? 2. Приведите пример формата значения атрибута "Шаги и ожи- даемый результат". 256 Тестирование Дот Ком. Часть 3 3. Чем били по голове тех, кто заносил баг с кратким описанием "Ничего не работает"? 4. Перечислите элементы веб-страницы и проблемы, с ними свя- занные. 5. Как сделать графический файл с тем, что мы видим на экране монитора? 6. Основная обязанность держателя бага. 7. Что должен проверить Verifier перед началом регрессивного тестирования? 8. Приведите две части регрессивного тестирования. Нужно ли проводить вторую часть, если первая не работает? Можно ли закрыть баг уже после первой части, если ремонт был успешен? 9. В чем концептуальное различие серьезности и приоритета? 10. Кого мы обычно включаем в Notify list? 11. Дайте определение фича. 12. Почему возникают ситуации, когда баги приходится открывать заново? 13. Что нужно делать для того, чтобы программисты не возвращали вам баги как "Not Reproducible'"? 14. Почему возникают ситуации, когда баг возвращается с резо- люцией "Not a bug"? 15. Нарисуйте блок-схему процесса трэкинга багов. ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 1: ТЕСТИРОВАНИЕ НОВЫХ ФИЧА • TEST ESTIMATION (ТЕСТ-СМЕТА) • ENTRY/EXIT CRITERIA (КРИТЕРИЙ НАЧАЛА/ЗАВЕРШЕНИЯ) • TEST PLAN (ТЕСТ-ПЛАН) отя при разговоре о процессе разработки ПО мы перевели "New Feature Testing" как "Тестирование новых компонен- тов", я предлагаю немедленно заменить "компонентов" на "фича", так как это более точный перевод и мы уже знаем, что такое фича. Исполнение тестирования состоит из двух стадий, идущих в сле- дующей очередности: 1. Тестирование новых фича (new feature testing); 2. Регрессивное тестирование (regression testing). Сначала о стадии 1. После того как код проинтегрирован, тест приемки пройден и код заморожен, мы начинаем тестирование новых фича. Кстати, тест приемки — это, как правило, эд хок-тестирование, при ко- тором мы проверяем, работают ли самые базовые вещи, как, например, создание нового эккаунта. Я рекомендую составить список с такими базовыми вещами, например: Создай новый эккаунт Войди в систему Добавь книгу в корзину... и во время теста приемки мы просто идем от строчки к строчке и делаем проверку. Тест приемки считается пройденным, когда каждый из наших мини-тестов имеет положительный исход. 257 Х |