Большинство задач в релизе — небольшие улучшения или мелкие правки багов. В этом случае разработчик все быстренько делает и отдает в тестирование готовое приложение. А вот когда улучшение серьезное, одна задача разбивается на две — сделать на сервере и на клиенте. Появляется возможность поработать по TDD — сначала тесты, потом разработка.
Писать тесты без реализации тяжело. Привык, что написал и сразу отлаживаешь: запускаешь, смотришь на падение и думаешь, ты накосячил в тесте или в коде правда баг. Когда отладиться нельзя, нужно быть особо внимательным. Высший пилотаж — написать тесты так, что при первом прогоне они все пройдут. Или упадут, но из-за найденного бага в коде, а не потому, что вы накопипастили лишнего.
Я иногда забываю какую-нибудь мелочь при написании теста. Например, заполнить колонку А в таблице Б. Запускаешь тест, а он разваливается. Иногда с непонятным сообщением типа NullPointerException. Поди угадай, ты налажал или в коде бага. Я иду к разработчику, вместе смотрим и находим... Мой косяк в тесте =)
Поэтому, когда я жалуюсь Васе (разработчику), что у меня не проходит тест, он сначала пытается отмахнуться:
— А startdate в таблице связей заполнила?
— А id_cat в таблице cat точно равно id_cat в таблице animals? (see foreign key)
— А это сделала?
Конечно, иногда такой вопрос наводит меня на мысли, но я же обучаюсь)) И типовые проблемы проверяю сама перед тем, как идти с вопросом.... К чему это я? А к тому, что пока ты баг не локализуешь, хрен докажешь, что он есть! И хорошо, когда код полностью готов. Показываешь, что вручную падает на том же месте — значит, ошибка не в автотесте, а в коде. Живой случай из практики:
************************************************
Делаем большую доработку. Пока я занималась другими задачами, успели сделать не только серверную часть, но и клиентскую. Это здорово — я люблю потыкать вручную, это наводит на мысли и идеи.
Радостно потираю ручки, стартую билд, запускаю новую функцию — не работает о_О
Как так? Иду к разработчику:
— Но почеееееему?
— Ну так функция новая, по умолчанию выключена. Поменяй в админке WOW_FEATURE = ENABLE и перезапусти.
— ОК.
Поменяла, перезапустила, отвлеклась. Другие дела переделала, вернулась к своему локально развернутому стенду — а он не разворачивается! В логах текст:
Not found file bla-bla-bla\service.jar\bla\bla\bla\file.txt
Я опять к разработчику:
— Так и так.
— Эм. Этот файл должен выкачиваться из SVN при сборке. А сам файл у тебя есть?
— Есть!
— А локально собранный есть?
— *проверила* Есть!
— А в репозитории локальном?
— *проверила* Есть!
— А внутри собранного билда, в этом jar проверяла?
— ДА! Вот тебе мой билд, проверь.
— *проверил* У меня все работает, это у тебя локально какие-то проблемы.
А разработчики болеют, нельзя подозвать их, чтобы пошаманили над компом. Но такие проблемы правда бывают. Поэтому не стала копать, когда именно воспроизводится баг, поверила разработчику.
Стала экспериментировать, снесла к чертям весь локальный репозиторий, снова пересобрала — не работает :( А обычно помогает, когда глюки в репозитории! Я в печали, файлик внутри архива есть, а билд говорит, что нету! Как так?
Тут прилетела критикал задача, пришлось отложить шаманства — новую фичу будем выпускать в следующем релизе, текущий в приоритете. Отвлеклась на день или два. Потом появилось время и я вернулась к новому функционалу.
Пересобрала все сборки и на всякий случай пересоздала схему базы данных. Поднимаю билд — поднимается!!! Ура ура ура, я смогу потыкать функционал ручками. Потираю ручки, запускаю функцию... А она не работает (злобный смайлик).
Напрягаю память, ах да, она же пока DISABLE. Я пересоздала базу, где хранится состояние, вот она снова и выключена. Меняю на ENABLE, ребутаю... И снова эта ошибка! АГА! ТАК БАГ ВСЕ-ТАКИ ЕСТЬ!!! И вот почему моя сборка у разработчика поднялась — он поднимал на своей схеме БД, где функционал был выключен. Ну, теперь ты от меня не отмажешься!
Переоткрыла задачу, описала, как воспроизводить. Разработчик посмотрел — правда баг. Оказалось, неправильно было настроено приведение абсолютного пути к относительному. Поэтому, хотя файлик реально и был, найти его система не могла. А искать пыталась только в том случае, когда включался новый функционал.
***************************************************
Учу-учу своих студентов тому, как важно локализовывать баги, а сама
Мне помешали две вещи:
Писать тесты без реализации тяжело. Привык, что написал и сразу отлаживаешь: запускаешь, смотришь на падение и думаешь, ты накосячил в тесте или в коде правда баг. Когда отладиться нельзя, нужно быть особо внимательным. Высший пилотаж — написать тесты так, что при первом прогоне они все пройдут. Или упадут, но из-за найденного бага в коде, а не потому, что вы накопипастили лишнего.
Я иногда забываю какую-нибудь мелочь при написании теста. Например, заполнить колонку А в таблице Б. Запускаешь тест, а он разваливается. Иногда с непонятным сообщением типа NullPointerException. Поди угадай, ты налажал или в коде бага. Я иду к разработчику, вместе смотрим и находим... Мой косяк в тесте =)
Поэтому, когда я жалуюсь Васе (разработчику), что у меня не проходит тест, он сначала пытается отмахнуться:
— А startdate в таблице связей заполнила?
— А id_cat в таблице cat точно равно id_cat в таблице animals? (see foreign key)
— А это сделала?
Мой разработчик, когда у меня падает автотест
Конечно, иногда такой вопрос наводит меня на мысли, но я же обучаюсь)) И типовые проблемы проверяю сама перед тем, как идти с вопросом.... К чему это я? А к тому, что пока ты баг не локализуешь, хрен докажешь, что он есть! И хорошо, когда код полностью готов. Показываешь, что вручную падает на том же месте — значит, ошибка не в автотесте, а в коде. Живой случай из практики:
************************************************
Делаем большую доработку. Пока я занималась другими задачами, успели сделать не только серверную часть, но и клиентскую. Это здорово — я люблю потыкать вручную, это наводит на мысли и идеи.
Радостно потираю ручки, стартую билд, запускаю новую функцию — не работает о_О
Как так? Иду к разработчику:
— Но почеееееему?
— Ну так функция новая, по умолчанию выключена. Поменяй в админке WOW_FEATURE = ENABLE и перезапусти.
— ОК.
Поменяла, перезапустила, отвлеклась. Другие дела переделала, вернулась к своему локально развернутому стенду — а он не разворачивается! В логах текст:
Not found file bla-bla-bla\service.jar\bla\bla\bla\file.txt
Я опять к разработчику:
— Так и так.
— Эм. Этот файл должен выкачиваться из SVN при сборке. А сам файл у тебя есть?
— Есть!
— А локально собранный есть?
— *проверила* Есть!
— А в репозитории локальном?
— *проверила* Есть!
— А внутри собранного билда, в этом jar проверяла?
— ДА! Вот тебе мой билд, проверь.
— *проверил* У меня все работает, это у тебя локально какие-то проблемы.
А разработчики болеют, нельзя подозвать их, чтобы пошаманили над компом. Но такие проблемы правда бывают. Поэтому не стала копать, когда именно воспроизводится баг, поверила разработчику.
Стала экспериментировать, снесла к чертям весь локальный репозиторий, снова пересобрала — не работает :( А обычно помогает, когда глюки в репозитории! Я в печали, файлик внутри архива есть, а билд говорит, что нету! Как так?
Тут прилетела критикал задача, пришлось отложить шаманства — новую фичу будем выпускать в следующем релизе, текущий в приоритете. Отвлеклась на день или два. Потом появилось время и я вернулась к новому функционалу.
Пересобрала все сборки и на всякий случай пересоздала схему базы данных. Поднимаю билд — поднимается!!! Ура ура ура, я смогу потыкать функционал ручками. Потираю ручки, запускаю функцию... А она не работает (злобный смайлик).
Напрягаю память, ах да, она же пока DISABLE. Я пересоздала базу, где хранится состояние, вот она снова и выключена. Меняю на ENABLE, ребутаю... И снова эта ошибка! АГА! ТАК БАГ ВСЕ-ТАКИ ЕСТЬ!!! И вот почему моя сборка у разработчика поднялась — он поднимал на своей схеме БД, где функционал был выключен. Ну, теперь ты от меня не отмажешься!
Переоткрыла задачу, описала, как воспроизводить. Разработчик посмотрел — правда баг. Оказалось, неправильно было настроено приведение абсолютного пути к относительному. Поэтому, хотя файлик реально и был, найти его система не могла. А искать пыталась только в том случае, когда включался новый функционал.
***************************************************
Учу-учу своих студентов тому, как важно локализовывать баги, а сама
Мне помешали две вещи:
- Локальный репозиторий правда глючит периодически. Сносишь, пересобираешься — и все зашибись.
- Переключение внимания. Если бы в первый день я не отвлеклась, то могла бы вспомнить, что билд я не пересобирала, единственное, что поменяла — это флаг включения функции. Но, так как я между делом собрала локально еще пару билдов, я подумала, что это после пересборки что-то засбоило.
В общем, когда нашли баг — отложите другие дела и попробуйте локализовать его сразу. Это займет меньше времени, чем если отложить задачу и вернуться к ней спустя сутки/двое.
И помните — локализация очень важна. Не локализовал баг — разработчик это за тебя делать не будет: "А я что? У меня все работает!". Такие дела)
А у нас проще :)
ОтветитьУдалитьТестировщик: Тут баг, и я его завела
Программист: Да ладно.
Тестировщик: Топай сюда, будем в дебагер смотреть и тебя корить
Давай, расскажи про "топай сюда" программисту, который неделю болел и дома сидел :)
Удалить