Вот кто мне cкажет - что должен делать тестировщик? У 9/10 в голове всплывает "искать баги". Увы, это именно то, что хоронит проекты. Если тестировщик заинтересован только в поиске багов - пиши пропало. Если у него - после туевой хучи уебанных треннингов аля "Как найти удовольствие в работе? - Радоваться найденным багам!" - мозг настроен исключительно на поиск багов - проект либо вообще не будет выпущен, либо будет выпущен поздно (упущенная выгода + потеря лидирующих позиций) и все равно хромой. Поясняю на пальцах навожу порчу по IP - все знают, что программу невозможно полностью избавить от багов. Все знают, что если хорошенько искать - то найдется. А уж если речь идет о сложной программе, когда чиним уши - отваливается нос, то и подавно - багогенератор, точнее, эндорфиногенератов у вышеозначенных товарищей. Они не заинтересованы в затыкании фонтана своего удовольствия, а, следовательно, в выходе проекта. "Но что же тогда должен делать тестировщик?! Неужели пропускать баги, закрывать глаза на произвол?!" - в пылу воскликнет молодой и/или неопытный тестировщик. В первую очередь тестировщик должен уметь правильно расставлять приоритеты. Не у тикетов, нет, а в голове. "Насколько ломает игровой процесс этот баг? Сложен ли он в повторении? Реальна ли эта ситуация для пользователя? Сколько времени (читай - денег) может занять его починка?". Если это действительно важно - тикет. Если это может подождать до багфикса после выхода - запишите себе в отдельный список и не мучайте команду обновляющимися через каждые 5 минут тикетами. Конечно, не все эти вопросы тестировщик может решить сам - подойдите к PM'у - они не кусаются. Более того, именно PM лучше вас даст оценку - будет это чинится срочно или нет и будет в курсе всех проблем. И ваша совесть будет чиста - вы не просто умолчали, а доложили и приняли решение вместе (ваша задача для этого - дать PM'у понять всю полноту картины). Далее. Не нужно плодить кучу однородных тикетов - "тут съехал текст", "тут кривая кнопка", "тут вылез английский/китайский/афрояпонский текст" - сделайте один с пунктами и вы увидите, насколько вы облегчите собственную жизнь и жизнь программиста. Куда легче обновлять тикет пачкой, чинить и проверять, чем жонглировать 10 однотипными. Ну, про уточнение условий писано-переписано уже сто раз. Не пишите условия "шаг влево, шаг вправо - расстрел" - исследуйте вширь - только ли при таких условиях, а если чуть изменить/убрать шаг? Не пишите "тут сломалось, наверное в <аналогичное место> тоже поломано" - посмотрите бога ради в это аналогичное место! Чем больше информации вы дадите для починки, тем меньше времени уйдет на починку, ведь именно вы, а не программист работаете с клиентской частью, вы знаете ее куда лучше. И последнее - помните про приемочное тестирование - именно этим вы должны заниматься перед выходом проекта, а не поиском багов.
А радоваться надо не найденным багам, а починенным. Если вы радуетесь только найденным - получается, что вам совсем неважно? что ваш проект - хромой, убогий и болезный, да вы именно этому и рады. А если вы радуетесь починкам - значит, вы улучшаете качество вашего продукта, радуетесь его росту, улучшению.
Комментариев нет:
Отправить комментарий