среда, 18 мая 2011 г.

Рекомендации молодым багоборцам.

Несколько советов молодым от умудренного опытом горе, т.е. гуру тестера...

  1. Изучайте баг репорты, написанные своими коллегами.
    Очень часто, прочтя баг репорт, написанный кем-то, задумываешься: “Интересно... А что если мне проверить такое?” Проверяешь и действительно, находишь багу.
  2. Утром после вечернего, ночного, выходного продакшн деплоя, первым делом проверьте работоспособность приложения, даже если никто из пользователей не сообщил о проблемах.
    Были случаи, когда сразу после деплоя все работало как часы, а на утро - бац и отвалилось. Либо утром ты проснулся с идеей прогнать тест, который ты не проводил на фазе тестирования. Сделал - и действительно нашел критическую багу. Либо как часто бывает в реальной жизни - нагрузочное тестирование проводили на тестовой платформе, отличающейся по конфигурации от используемой в продакшине, в “тесте” все ОК, а в “проде” - в силу каких-то причин тормозит... У всего этого итог один - Rollback.
  3. Пишите шпаргалки неофициальные короткие инструкции, пометки и комментарии, чек листы, логи прохождения тест кейсов. Иногда они будут полезнее, чем официальные документы.
    Вы думаете, перерабатываете, прогоняете информацию через себя и выдаете её в более понятной форме. Своими записями вы оптимизируете процесс своей работы, выбрасываете не нужное, добавляете необходимое.
  4. Задавайте вопросы и уточняйте нюансы даже когда для Вас все кажется очевидным. Читайте спецификации, спрашивайте у бизнес аналитиков, разработчиков, менеджеров и пользователей.
    Обладая информацией, полученной из разных источников, Вы будете писать более качественные тест кейсы и тем самым цена, написанных Вами, баг репортов будет намного выше.

Отправить комментарий

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.