понедельник, 21 декабря 2015 г.

Зачем тестировать граничные значения? © Разработчик

В пятницу я тестировала модуль, который надо было срочно отгрузить Заказчику — близился deadline. Давайте преположим, что у нас приложение, в котором можно увидеть информацию по жильцам дома. У каждого жильца могут быть кошечки и собачки, дети, семья...
Будем тестировать кошечек!

Информация по проживающим загружается из файлов в виде внешних справочников. Справочники могут быть разных форматов. Модуль загрузки в систему уже есть, он готовый. Фактически надо просмотреть существующие справочники и настроить их обработку — xml конвертируем в scv, оттуда считываем в систему. Есть и ограничения, на одну квартиру может быть:

  • 10 жильцов. Если больше, берем первые 10.
  • 5 кошечек. Если больше 5, берем первые 5.
  • 10 рыбок. Ну вы поняли.
Справочники загружаются в систему и домовладелец может искать по жильцу или кличке кота. Если результат найден в справочнике — возвращается номер квартиры.
Мы весь функционал покрываем автотестами. Но времени нет. Значит, надо проверить ручками, отдать билд и спокойно писать автотесты. Примерно прикинула план действий. Тут заходит разработчик, пусть будет Вася:

— Оля, как у тебя с модулем жильцов? Отдавать ведь надо...
— Да, надо. Поэтому я сегодня проверю вручную, а потом буду тесты писать...
— А что там писать?
— Как это что, вот тут и вот тут интеграционные тесты (стык двух систем), а еще внутри самого модуля — на то, что у нас 5 жильцом, 10, 11...
— Зачем это проверять? о_О
— Как зачем? о_О Надо же проверить, что 10-ого жильца он грузит, а 11 уже нет...
— Да ну, нет смысла. *Махнул на меня рукой* Все комбинации не проверишь. *ушел*.

Ну здрасьте. Я что, джуниор чтоли, все комбинации перебирать? Делим на классы эквивалентности, берем значение из интервала, пограничное, за границей... Пффф, ох уж эти разработчики!

Начала тестировать. Завожу в справочнике разные варианты: 1 жилец с парой кошек, вообще без животных, максимально заполненный...

Раз я пишу этот пост, нетрудно догадаться, что баг там был =) При попытке поискать по седьмому жильцу поиск вернул пустоту... Хммммм, пошла локализовывать — третий работает, шестой нет, четвертый работает, пятый уже нет. 

Пишу Васе:
— Так и так, только первые четыре жильца работают, дальше нет. 
— А что в обработанном справочнике?

О, не проверяла. Дейстивтельно, косяк мог быть на этапе конвертации, там отсекались первые четыре. Но нет, в csv, который получен из xml, все на месте.

— Там есть!

Не поверил (smile) Пришел, постоял над душой — может, ты плохое имя жильцу ввела? Ага, «Томат» работает, а «Вася» нет. Да, так совпало, что первым неработающим именем у меня было имя разработчика. Это не я, оно само =)


Убедился, подебажил. Нашел ошибку. Так как ранее модуль использовался по другому, ни у кого не было желания таскать сразу десяток записей, то там стояло ограничение. В том коде, который, по идее, тестировать то было и не надо, готовый же =)

Вечером Вася зашел ко мне снова:

— Пофиксил! Молодец, Оля, хороший баг!
— А кто говорил «не надо это тестить, не надо»? ;)
— Нууууууу... Я говорил, что не надо все комбинации тестировать.

И убежал =)

Капитанские выводы, о которых никогда не надо забывать:

— Даже если берете готовый модуль, его надо тестировать в рамках свой задачи. Особенно если берете готовый модуль. Потому что его сделали год назад, потестили и забили. За столько времени новые бажики нарисовались.
— Не верьте разработчикам, тестируйте границы =) Даже если разработчик говорит, что там багов быть не может. Особенно если он так говорит!

См также:
Нет доступа к коду? Проверяй все! — Поучительная история о том, как разработчики сами пишут тесты.

2 комментария:

  1. +1

    Программистам вообще верить нельзя, когда они говорят о качестве их программы.

    Это я тебе как программист говорю. Правда автотесты я себе сам писал. Не было у меня тестировщика, к сожалению.


    ОтветитьУдалить
    Ответы
    1. А я тебе как тестировщик верю )))))
      Точнее, не верю, когда дело касается "да там все работает" :)

      Удалить