Не далее чем вчера прочитала о том, что читать про простые, "не заковыристые" баги скучно и неинтересно, и вообще потеря времени. И не далее чем сегодня убедилась в том, что как раз о простых вещах никогда не стоит забывать 
Не всегда фикс в бранче - это фикс бага. Иногда это просто некая фича, которая нужна "здесь и сейчас". И вот мы имеем некую функцию, которая умеет работать со списком. То есть мы передали ей на вход список элементов, которые мы хотим изменить и она их модифицирует.
Сейчас эта функция очень пригодилась - надо было написать патч, временно изменяющий поведение системы, прогнать в нем эту функцию и вернуть все обратно.
Задачка элементарнейшая, поправить которую - ну 5 минут от силы! В коде... Но как-то так получилось, что она заняла у меня много времени. Ведь это поправить 5 минут, а проверить?
Надо поднять билд без патча, подготовить данные, создать отдельную (желательно) БД, потом поднять патч, проверить функцию... И, кстати, делается это все не зря, потому что первый раз я поправила не то, что надо было ))
Но неважно, когда вот так тратишь время на одну задачу, особенно ту, которая кажется очень простой, начинаешь немного нервничать. И можешь что-то упустить. Вот, допустим, сама функция уже была протестирована ранее - то, что она в принципе работает.
Соответственно, мне надо только проверить свою кастомизацию. Подняла патч, прогнала функцию, элементы изменились? Изменились! Счастье счастье, радость радость! Нет бы в логи посмотреть...
Патч был передан для интеграционного тестирования на приближенные к реальным данные. И через пару часов мы почувствовали подвох...
Обратимся еще раз к условию - на вход мы передаем список элементов, которые мы хотим модифицировать. Какие самые главные позитивные и негативные сценарии возникают у нас в голове?
+ Передать список элементов, проверить, что они модифицировались.
- Проверить, что элементы, не попавшие в список, не были модифицированы.
Причем функция такая не одна, и на другие я точно помню, были подобные негативные тесты - а что, если элемента в списке нет, будет ли он изменен?
Но угадайте с 3-х раз, на какую функцию не был написан такой тест и где в итоге обнаружилась бага?
Причем по данным бага некритичная, модификация нигде ничего не ломает. Просто выполняется дольше, чем ожидалось...
Вот читаешь, читаешь всякие книжки по тайм-менеджменту и прочим радостям жизни. Но самые главный закон - СЯДЬ И ПОДУМАЙ!
Я его, кстати, запомнила со своей первой встречи с MSTC
Там еще выступала Третьяк Анастасия, так зажигательно выступала, что до сих пор помню!
А так здорово сформулированный девиз до сих пор повторяю, особенно после очередного подтверждения, как же он все-таки прав.
Неважно, что на вас давят сроки. Да, надо вот прям сейчас, в течении пары часов сделать, проверить и отдать. Но не позволяйте времени брать верх. Позвольте себе расслабиться и посмотреть на проблему немного со стороны - а все ли я учел, а где тут еще может выстрелить?
Для этого очень помогает пройтись мысленно по пользовательскому сценарию. Вот именно представить себя пользователем - как я буду это использовать? Что я буду нажимать? Сколько времени это займет? А то меня и написание инструкции не спасло, я смотрела на нее и видела данные, даже не думая о времени. Не торопитесь. Вы все успеете
Позвольте себе сесть и подумать. Все ли сделано правильно, на что это еще могло повлиять и как?
Не всегда фикс в бранче - это фикс бага. Иногда это просто некая фича, которая нужна "здесь и сейчас". И вот мы имеем некую функцию, которая умеет работать со списком. То есть мы передали ей на вход список элементов, которые мы хотим изменить и она их модифицирует.
Сейчас эта функция очень пригодилась - надо было написать патч, временно изменяющий поведение системы, прогнать в нем эту функцию и вернуть все обратно.
Задачка элементарнейшая, поправить которую - ну 5 минут от силы! В коде... Но как-то так получилось, что она заняла у меня много времени. Ведь это поправить 5 минут, а проверить?
Надо поднять билд без патча, подготовить данные, создать отдельную (желательно) БД, потом поднять патч, проверить функцию... И, кстати, делается это все не зря, потому что первый раз я поправила не то, что надо было ))
Но неважно, когда вот так тратишь время на одну задачу, особенно ту, которая кажется очень простой, начинаешь немного нервничать. И можешь что-то упустить. Вот, допустим, сама функция уже была протестирована ранее - то, что она в принципе работает.
Соответственно, мне надо только проверить свою кастомизацию. Подняла патч, прогнала функцию, элементы изменились? Изменились! Счастье счастье, радость радость! Нет бы в логи посмотреть...
Патч был передан для интеграционного тестирования на приближенные к реальным данные. И через пару часов мы почувствовали подвох...
Обратимся еще раз к условию - на вход мы передаем список элементов, которые мы хотим модифицировать. Какие самые главные позитивные и негативные сценарии возникают у нас в голове?
+ Передать список элементов, проверить, что они модифицировались.
- Проверить, что элементы, не попавшие в список, не были модифицированы.
Причем функция такая не одна, и на другие я точно помню, были подобные негативные тесты - а что, если элемента в списке нет, будет ли он изменен?
Но угадайте с 3-х раз, на какую функцию не был написан такой тест и где в итоге обнаружилась бага?
Причем по данным бага некритичная, модификация нигде ничего не ломает. Просто выполняется дольше, чем ожидалось...
Вот читаешь, читаешь всякие книжки по тайм-менеджменту и прочим радостям жизни. Но самые главный закон - СЯДЬ И ПОДУМАЙ!
Я его, кстати, запомнила со своей первой встречи с MSTC
Там еще выступала Третьяк Анастасия, так зажигательно выступала, что до сих пор помню!
А так здорово сформулированный девиз до сих пор повторяю, особенно после очередного подтверждения, как же он все-таки прав.
Неважно, что на вас давят сроки. Да, надо вот прям сейчас, в течении пары часов сделать, проверить и отдать. Но не позволяйте времени брать верх. Позвольте себе расслабиться и посмотреть на проблему немного со стороны - а все ли я учел, а где тут еще может выстрелить?
Для этого очень помогает пройтись мысленно по пользовательскому сценарию. Вот именно представить себя пользователем - как я буду это использовать? Что я буду нажимать? Сколько времени это займет? А то меня и написание инструкции не спасло, я смотрела на нее и видела данные, даже не думая о времени. Не торопитесь. Вы все успеете
Позвольте себе сесть и подумать. Все ли сделано правильно, на что это еще могло повлиять и как?
Тест-инженер NASA: Да, я понимаю что из-за взрыва шаттла погибло более тысячи человек, мы знали об этом баге и предупреждали разработчиков, но они сказали что этот кейс никогда не вылезет в продакшене.
ОтветитьУдалитьСудья: Хорошо. А теперь сядь и подумай!