Капитан очевидность на связи!
Итак, что делает тестировщик, когда необходимо закрыть задачу? Проверяет то, что было описано в баге / задаче и закрывает. Казалось бы, ничего сложного, да? Как бы не так. Если бы все было бы так просто, то зачем вообще были бы нужны тестировщики?
Проблема в том. что, исправляя одну багу, разработчик вполне может наплодить других. Да-да, именно других, даже не "другую", не одну.
Поэтому, перед тем, как закрыть задачу - остановить и подумай, а на что еще могла повлиять эта бага? А что еще могло бы быть затронуто?
Или даже так - а часто ли возникает такая потребность (если тип задачи был task, а не bug) ? Можно ли что-то сделать, чтобы сэкономить время в будущем?
Once upon the time... Когда-то, будучи простым black-box тестировщиком, я закрывала задачи быстрее, используя именно эвристику "Задание выполнено!"
Я тогда, правда, и баги иногда неоптимально описывала, особенно, не зная, в чем именно беда - "загрузить отчет *** на тестовой и он упадет". Как проверить, если разработчик не написал, из-за чего именно падало? Правильно, загрузить именно этот отчет (или скомбинировать его заново по скриншоту конфигурации) и закрыть задачу. Минут так за 5.
Графоманство? Не моя проблема, ТЗ пишет начальник. Тестировать "около"? Да тестирую я, тестирую, просто отдельную багу поставлю, делов то...
Сейчас, побывав по другую сторону баррикад, я эту эвристику почти не применяю.
Ведь exploratory в духе "а ничего ли вокруг не сломалось?" тоже занимает какое-то время. Но бывает и так, что новая фишечка ну настолько простая и обособленная, что ничего не уронит. Тоже за 5 минут закрыть? Не-е-е-ет, закрывающий проверяет документацию и пополняет ее.
Логи надо разобрать - быстро? Не-е-е-е-ет, это же не на один раз задачка, и вот ты уже сидишь и копаешься в js скрипте, который будет в будущем делать работу за тебя. А время то уже, ой, скоро полночь!
Запрос в поддержку пришел - зная систему, быстро ответил и забыл? Не-е-е-е-ет. Если это простой запрос, надо подумать, почему он возник - плохая документация? Или правда что-то непродумано в системе?
А если сложный запрос? Тут так просто не ответишь... Здесь уже нужен анализ ситуации. Даже если видна ошибка, и есть инструмент по ее исправлению - но откуда она вообще взялась? Не устраняем ли мы следствие, а не причину? А есть ли ошибка вообще? Это вообще такие непредсказуемые задачки...
Вот например, в пятницу были у меня определенные планы на день. Пришла на работу... И весь день занималась поддержкой. Ну ок, пришла в субботу, поработать, пока тебя никто не тронет и не отвлечет. Угадайте с трех раз, чем я занималась полдня
Закрывая задачу без дополнительного анализа, мы попадает в "черный круг". Исправляя последствия, не замечаем ошибок. Реальных ошибок, которые закопаны чуть глубже. А оставленные без присмотра ошибки радуются и пускают корни все глубже и глубже... Одновременно появляются новые ошибки, у которых, опять же, удаляется только верхушка, а корни все растут и растут... И вот уже у Вас такой клубок, который фиг распутаешь.
Не закрывайте задачу за 5 минут. Подумайте, откуда она вообще взялась и на что еще повлияла?
А если компания довела ситуацию до состояния "такой клубок, который фиг распутаешь"? Когда контроль качества годами сводился к заведению багов специалистами техподдержки, а тестовым покрытием и документацией практически не занимались.
ОтветитьУдалитьМожно много писать о причинам, приводящих к бардаку и хаосу, вопрос в том, как "без отрыва от производства" выйти из такого запущенного состояния?
А зачем Вам тестовое покрытие, чтобы подумать, на что могло повлиять исправление бага, где может быть похожий?
УдалитьЗачем Вам документация, если ее издревле нет? Бывают проекты, где все в головах. Что поделать, записан самый минимум.
Может, это просто не нужно? Все равно никто не мешает прикинуть, что где еще могло сломаться - пойти и проверить. Хотя бы так.
А документацию можно писать хотя бы для себя, выделяя по полчасика в день.