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

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

Будем тестировать кошечек!

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

• 10 жильцов. Если больше, берем первые 10.
• 5 кошечек. Если больше 5, берем первые 5.
• 10 рыбок. Ну вы поняли.

Справочники загружаются в систему и домовладелец может искать по жильцу или кличке кота. Если результат найден в справочнике — возвращается номер квартиры.

Мы весь функционал покрываем автотестами. Но времени нет. Значит, надо проверить ручками, отдать билд и спокойно писать автотесты. Примерно прикинула план действий. Тут заходит разработчик, пусть будет Вася:

— Оля, как у тебя с модулем жильцов? Отдавать ведь надо...

— Да, надо. Поэтому я сегодня проверю вручную, а потом буду тесты писать...

— А что там писать?

— Как это что, вот тут и вот тут интеграционные тесты (стык двух систем), а еще внутри самого модуля — на то, что у нас 5 жильцом, 10, 11...

— Зачем это проверять? о_О

— Как зачем? о_О Надо же проверить, что 10-ого жильца он грузит, а 11 уже нет...

— Да ну, нет смысла. *Махнул на меня рукой* Все комбинации не проверишь. *ушел*.

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

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

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

Пишу Васе:

— Так и так, только первые четыре жильца работают, дальше нет. 

— А что в обработанном справочнике?

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

— Там есть!

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

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

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

— Пофиксил! Молодец, Оля, хороший баг!

— А кто говорил «не надо это тестить, не надо»? ;)

— Нууууууу... Я говорил, что не надо все комбинации тестировать.

И убежал =)

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

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

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

См также:

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