Самые интересные баги - это баги-провокаторы, баги-партизаны. Они ну никак не должны были выжить при тестировании и всё-таки они здесь, живут себе спокойно и попадаются пользователям.
Это что называется "недотестировали". Не подумали, что такая ситуация возможна (или подумали, но забыли записать). Не обратили внимания, списали на устаревший кэш браузера или проблемы настройки.
Всё бы ничего, но это баг на сайте сервиса кроссбраузерного тестирования. И воспроизвёлся он в обычном Firefox 27.0.1.
Эти баги очень интересно находить на каких-то случайных ресурсах, особенно посвящённых тестированию или на каких-нибудь серьёзных сайтах. К таким ресурсам всегда высокий уровень доверия и как-то не ожидаешь таких простых ошибок, а они всё равно есть.
Другое дело, когда после релиза такие ошибки находишь в продукте, который тестировал ты и твоя команда. И даже бывает так, что ты проверял и точно помнишь это - а вот, возьмите, распишитесь - оно не работает. Как??
Причин много, и тестировщик должен знать своих врагов в лицо, так же как и каждый найденный баг:
1. Планирование. Кто, когда и какой функционал проверяет, как мониторить прогресс тестирования, когда можно ожидать исправления всех критических багов и их верификацию?
2. Организация. Релиз близко, обстановка накаляется. Все нервничают и отвлекаются на почтовые рассылки и чатики, мы жанглируем багами, пытаясь пройтись по намеченному тест плану и не забыть описать все баги во всех подробностях.
- Эй, парень, сколько еще критических багов у нас висит?
- Какой парень?
3. Доверие автоматизированным тестам. И это тоже бывает одной из причин - у нас много автоматизированных тестов и мы надеемся на то, что уж они-то не пропустят баг, но что-нибудь автоматизировать забыли и вообще забыли о какой-нибудь маленькой фиче или изменении в продукте. Да, автотест сам не напишется. Или вовремя не отреагировали на падающие автоматизированные тесты - и вот он баг.
4. Костыли. Часто мы тестируем продукт в условиях, мало напоминающих те, которые будут у наших клиентов, что является почти бесконечным источником проблем. Ведь мы не смогли протестировать это на множестве возможных конфигураций и что-то упустили при настройке своего окружения, сделали какие-то дополнительные "действия" (шаманства) чтобы у нас всё работало и забыли об этом. Это как с кэшем браузера - если его надо чистить раз в пол часа то и у пользователя будут с этим проблемы.
таких причин много... список очень длинный. Но хватит и одной, чтобы пропустить баги. Простые баги, которые, казалось бы, прямо на поверхности - и не надо далеко идти или глубоко копать.
И есть одна практика, которая всегда мне нравилась - нашли проблему - надо немедленно начинать с ней работать, улучшая что-то каждый день, чтобы по прошествии времени оглянуться и сказать - да, благодаря этому я многому научился и мне многое удалось.
Это что называется "недотестировали". Не подумали, что такая ситуация возможна (или подумали, но забыли записать). Не обратили внимания, списали на устаревший кэш браузера или проблемы настройки.
Всё бы ничего, но это баг на сайте сервиса кроссбраузерного тестирования. И воспроизвёлся он в обычном Firefox 27.0.1.
Эти баги очень интересно находить на каких-то случайных ресурсах, особенно посвящённых тестированию или на каких-нибудь серьёзных сайтах. К таким ресурсам всегда высокий уровень доверия и как-то не ожидаешь таких простых ошибок, а они всё равно есть.
Другое дело, когда после релиза такие ошибки находишь в продукте, который тестировал ты и твоя команда. И даже бывает так, что ты проверял и точно помнишь это - а вот, возьмите, распишитесь - оно не работает. Как??
Причин много, и тестировщик должен знать своих врагов в лицо, так же как и каждый найденный баг:
1. Планирование. Кто, когда и какой функционал проверяет, как мониторить прогресс тестирования, когда можно ожидать исправления всех критических багов и их верификацию?
2. Организация. Релиз близко, обстановка накаляется. Все нервничают и отвлекаются на почтовые рассылки и чатики, мы жанглируем багами, пытаясь пройтись по намеченному тест плану и не забыть описать все баги во всех подробностях.
- Эй, парень, сколько еще критических багов у нас висит?
- Какой парень?
3. Доверие автоматизированным тестам. И это тоже бывает одной из причин - у нас много автоматизированных тестов и мы надеемся на то, что уж они-то не пропустят баг, но что-нибудь автоматизировать забыли и вообще забыли о какой-нибудь маленькой фиче или изменении в продукте. Да, автотест сам не напишется. Или вовремя не отреагировали на падающие автоматизированные тесты - и вот он баг.
4. Костыли. Часто мы тестируем продукт в условиях, мало напоминающих те, которые будут у наших клиентов, что является почти бесконечным источником проблем. Ведь мы не смогли протестировать это на множестве возможных конфигураций и что-то упустили при настройке своего окружения, сделали какие-то дополнительные "действия" (шаманства) чтобы у нас всё работало и забыли об этом. Это как с кэшем браузера - если его надо чистить раз в пол часа то и у пользователя будут с этим проблемы.
таких причин много... список очень длинный. Но хватит и одной, чтобы пропустить баги. Простые баги, которые, казалось бы, прямо на поверхности - и не надо далеко идти или глубоко копать.
И есть одна практика, которая всегда мне нравилась - нашли проблему - надо немедленно начинать с ней работать, улучшая что-то каждый день, чтобы по прошествии времени оглянуться и сказать - да, благодаря этому я многому научился и мне многое удалось.
Комментариев нет:
Отправить комментарий
Я признателен Вам за то, что делитесь своим мнением