Комментарии 34
И удивительный факт — во многих студиях нету формализованных чек-листов.
У опытного тестировщика вырабатывается еще такой навык как буфер памяти. Ну у меня во всяком случае он выработался за годы. Часто бывает выполняя какое-то действие, каскад ввода и вывода происходят практически одновременно. И такой буфер в голове помогает по памяти восстанавливать ход событий за секунды до "аварии", даже если раздел программы тебе незнаком. Этот буфер можно нацелено тренировать. Например просить друг друга в неожиданный момент описать последние свои действия в подробностях. Например коллега принес кофе поставил на стол, а ты просишь его рассказать как это произошло. Весьма увлекательная игра.
Если когда-нибудь на пенсии мне будет тяжело работать по специальности пойду в гейм дев джуном на полставки.
Кто сливает фичу в основную ветку?
Техлид или ответственные за фичу программисты
Тогда странно, что они неправильно разрешают конфликты слияния
Причем тут конфликт слияния?
Конфликт слияния это ошибка разработчика. Пулл реквест не будет корректным, пока разработчик не приведет ветку в порядок таким образом, чтобы она могла быть слита без конфликта.
Мержит техлид потому что он знает в какой момент нужно релизить и в какой релиз какие фичи пойдут, а в какой не пойдут, чтобы тестировщики знали что им тестить а что потом.
Вы писали: Правда, у Git есть интересная особенность — после слития что-то может перестать работать (из-за конфликтов) так, как было нужно.
Вот при этом конфликт слияния. Если разработчик правильно их разрешил и подготовил ветку к слиянию, то не вижу проблем почему должно что-то перестать работать (из-за конфликтов) и почему это особенность GIT, а не проблемы разработчиков. А в целом мне статья понравилась.
Почему и зачем тестировщик назначает исполнителя для бага?
Это помогает сократить время на бюрократию. Так как в большинстве случаев у нас узконаправленные команды разработчиков, то мы обычно знаем, кто и чем занимался. Если возникают трудности, то исполнителя назначает техлид
Понятно. Мы сейчас работаем по другой модели - есть перечень ничьих задач, кто освободился берёт ту, которую может сделать. В большинстве случаев это срабатывает лучше, чем когда задачу назначал руководитель или кто-то ещё, т.к. сам сотрудник лучше знает свои возможности и нет предвзятости, когда руководитель или другой сотрудник считает, что этот исполнитель не потянет задачу. Опять же перегруза нет, когда все задачи назначаются на одного уже и так загруженного сотрудника.
Это работает только в кроссплатформенных командах (имеется в виду, что каждый может выполнять условно "любую" задачу).
У вас каждый специализируется в чём то одном? Почему это не может работать в командах где все узко специализированы? Если человек видит что он эту задачу не сможет сделать он её не возьмёт, если видит что может и освободился - возьмёт. Но допустим пока специалист занят освободился человек, который раньше занимался другими задачами, но сейчас таких задач нет и он вместо того, чтобы тупо бить баклуши начинает делать не свойственную задачу, разбирается в теме и вот у вас уже два специалиста, которые могут решать подобные задачи. Чем принудительное назначение лучше и где подвох?
Не говорю, что наш подход лучше или хуже — это не то, из-за чего стоит устраивать холливар) Оба подхода применяются и имеют право на жизнь. Если человек освободился, он берет следующую задачу, относящуюся к своему отделу из бэклога. Что касается отдела тестирования, то ситуация действительно близка к тому, что Вы описали, но не всегда. Почти всегда гораздо быстрее и надежнее с точки зрения результата дать задачу человеку, который работал с ней ранее
Мы, кстати, периодически помогаем разработчикам обнаружить опечатки в коде. В Git есть история изменений, тянем коммит, который только запушили, он не запускается, открываем лог и понимаем, где может быть проблема. Идем с этим к программисту и фиксим за пару секунд.
WTF? В коммите опечатка, которую проигнорировал разработчик? Разработчик который свой код не тестирует ни до ни после коммита?
Ребят, меняйте процессы.
+1
Либо там тестировщики "работают за еду", либо мы что-то в тексте не понимаем. Опечатки в коде ведь находят компиляторы.
Рискну предположить, что имелись в виду опечатки типа "при активировании X даётся Y опыта, а должно даваться Z финтифлюшек".
Возможно, ввел в заблуждение словом "периодически". Конечно, больше уместно слово “случалось”. Такое случалось некоторое количество раз, и, как правило, в дни повышенной загруженности. В статье указано просто как пример пользы от базовых знаний синтаксиса используемого языка
Полгода поработал тестировщиком в геймдеве и уже почти год как не играю в мобильные игры и часть компьютерных, желание отбито на глухо.
Но если я всё-таки играть начинаю, то игра превращается в поиск багов и если я получил АНР, то все, игру прошёл считай ))
Тоже считаю, что "перестанете ли вы играть"—абсолютно личная история. Я не работаю в сфере геймдева 24/7, только разрабатываю пару проектов как хобби. Но даже при таком раскладе, я перестала играть в игры, хотя раньше могла в них буквально жить.
Возможно, перестают играть те, кто склонен к постоянному анализу и рефлексии. Потому что сейчас мои мысли в играх не "как красиво, как интересно))))", а "это можно сделать так, а тут они пропустили этот момент".
Сейчас пытаюсь найти другие способы расслабиться и все, что помогает—спорт))
На самом деле сочувствую) У меня в период адаптации (как раз первые полгода) тоже было похожее состояние, это нормально. Потом входишь в рабочий ритм и начинаешь разделять работу и отдых. Но предположу, что у всех индивидуально)
Пост про тестировщиков и очень уж похож на начало воронки найма, но вакансии нет ни на сайте ни на Хабре.
С Краснодара рассматриваете без опыта работы тестировщиком/QA?
А много ли вообще компаний, которые берут человека без опыта? И на какую зарплату может рассчитывать новичок?
Не могу тут утверждать за все компании, но лично мы берем, и, скорее всего, мы такие не одни, иначе откуда браться новым людям?
Также и по поводу зп — вилка сильно зависит от компании/города/условий (можно, например, сравнить на hh), но самый главный плюс в геймдеве в том, что есть хорошие возможности для роста, как внутри отдела, так и в масштабах всей компании. От этого я бы и отталкивался на месте джуна
Какие нюансы существуют при работе тестировщиком на удаленке? (со стороны соискателя-стажера)
Что точно можно сказать, это снижение эффективности коммуникации.
Одно дело когда ты встал пошел постучался в соседний кабинет где сидят инженеры разработки, спросил свое "что, зачем, почему" и пошел работать дальше, а другое, когда нужно людей вызванивать, а они почти весь день в веб-конференци сидят, ведь из-за удаленки им еще и между собой теперь приходится общаться виртуально, а у них pair programming и масса других поводов общаться. Пишешь простыню в чат, потом кто-то на обед кто-то к врачу, вопрос переезжает уже на следующий день. Поэтому важно этот момент сразу прояснить. Чтобы тестировщик участвовал в дейли, и/или организовать специальные регулярные конференции "dev+qa = ❤" или иметь любую другую запасную возможность регулярного прямого контакта.
В одной команде у нас было так, что была общая веб-конференция команды, где все сидели просто весь день в пассивном режиме с видео. Это немного непривычно, но пожалуй максимально эффективно, всегда можно напрямую че-нить спросить.
Для начинающего тестировщика, для его становления, для зарабатывания репутации и своего места под солнцем в команде это очень важный момент, больше общаться, проявлять свое присутствие. Иначе будешь как Гарри Поттер в чулане под лестницей жить.
Абсолютно верно сказано. От себя могу добавить, что это частично нивелируется только если вся команда (имею в виду не только тестировщиков, а и разработчиков, и геймдизайнеров, художников) работает на удаленке. Когда мы работали на удаленке, создавали себе канал в дискорде со свободным доступом, где у каждого была своя личная комната, и если что нужно узнать/обсудить можно было просто перейти в комнату к нужному человеку и пообщаться.
Классная статья ,все понятно и просто ))
Устану ли я играть, нужно ли уметь кодить и чем вообще занимаются QA в геймдеве