Заметки на полях

Просто интересно - две компании, разработчики игр. На главных страницах - ВНЕЗАПНО - указана одна и та же игра, только у первых на мейле, у вторых - на одкл. С теми же...гм...ляпами. Нет, это не функционал (хотя я глубоко не копала), но в нашей фирме локализация поставлена так, что даже на банке с краской в арте вы не найдете следов английского текста. Т.е. у товарищей либо в куске движка остались англицизмы, либо это было портирование, поделенное между компаниями на 2 сети. Вторая интересная весчь - прикалываются они что ли - у обоих компаний открыты вакансии на QA (на сайтах с работой), но на сайтах собственных в перечне доступных вакансий - ВНЕЗАПНО! - ни у одной компании нет вакансии для QA. Это типа мы так пытаемся сразу определить насколько кандидат пошарился по сайту и нашел "баг" или просто несколько неактуальное состояние вакансий на сайте? У одних есть форма обратной связи - спросила интереса ради почему так - ответа нет. У второй компании даже формы обратной связи нет, только мыло - спрашивать лень. Но все равно интересно.
Еще наблюдизм - по ходу никто не отличает QA от QC - на всех сайтах с работой пишут QA, хотя по факту часто нужен QC. Если говорить о разнице, то QA это больше менеджмент (направление, постановка процесса для QC), а QC - практическая часть (тест-кейсы, выполнение, фиксация ошибок, проверки фиксов, пр). Такие хи-хи. UPD: они реально издеваются - еще одна контора, имеющая вакансию на сайте с работой, но которой нет на сайте (есть все, кроме как на тестировщика).

Большое заблуждение тестировщиков

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