Лично я могу только восхититься ответственностью команды, что они не обрадованно скинули с себя эти обязанности, а понимают, что новому человеку нужно время на вникание. Обсудить с тимлидом можно в целом

> В ближайшее время хочу поговорить с тимлидом на эту тему, но хотела узнать, как бывает в других местах, чтобы понять более объективно.

Здравствуйте, в других местах бывает очень по-разному - где-то люди живут без тестеров вообще и делают качественные продукты (т.е. делают всё необходимое тестирование без выделенного тестировщика), где-то наоборот есть большие отделы тестирования, через которые проходит каждое изменение и которые полностью отвечают за тестирование. И ещё куча других вариаций

Роль тестировщика и границы ответственности отличаются от команды к команде.

> У меня возникает ощущение, будто они не понимают, зачем я вообще в проекте (самый главный приоритет — регресс),
А у вас какое понимание - зачем вы вообще в проекте?

Да, непрозрачность присутствует. Хочется всему научиться и взаимодействовать качественно, но из-за таких моментов возникает потом ситуация "мне лучше знать / я быстрее проверю" (утрированно).

Спасибо, вы помогли увидеть это все с разных сторон :)
Буду обсуждать, как раз скоро ретроспектива.

Дизайн-ревью это в целом неплохая практика, даже если на проекте есть тестировщики
У нас проходило примерно так: дизайнер прикладывал дизайн, верстальщик верстал, мы сверяли всё чётко по макету + уточняли какие-то вещи у дизайнера (верстальщики тоже уточняли всякое, если, например, дизайнер надизайнил что-то сильно трудозатратное)
И после того, как все шрифты, цвета и отступы прилизывались, итоговая реализация (до выливки в прод), полностью соответствующая макету, отдавалась дизайнеру. Тут дизайнер мог либо дать добро на выкладку со своей стороны, либо (!) внести какие-то доработки, потому что-то выглядит не совсем так, как он себе представлял (или у него изменилось представление о прекрасном с того момента, как он отдал дизайн на вёрстку). Или, например, за это время на проекте начали формироваться какие-то другие стандарты (новый фирстиль, другой шрифт или оттенок цвета), и если в изначальном макете этого ещё не учли (а команда в целом пока не в курсе), то постправками на ещё не вылитой задаче это исправить несложно и в целом к месту

Тут правильно сказали, что ваши коллеги могли ещё не привыкнуть к такому раскладу (наличие тестировщика), но тут всё равно есть, что разграничить по функциональным обязанностям, поэтому не стоит просто отодвигать коллег от этого

В каком-то "обычном случае обычной продуктовой команды, работющей по обычному как-бы-agile" я бы обратил внимание на следующие пункты:
1. за счёт чего команда выживала без тестировщика? видимо все подряд тестировали? - наверное я бы скорее поощрял эти практики и смотрел с точки зрения - как их улучшить
2. что всё-таки заставило команду взять выделенного тестировщика? вырос регресс? - я бы посмотрел "свежим" взглядом на корень проблемы вместе с опытными и мтоивированными участниками команды

Соглашусь, я понимаю, что ведь у них экспертиза тоже есть, и какая-то доля проверок на их плечи тоже ложится. У нас примерно также сейчас проходит, как вы описали

Спасибо, это действительно важные вопросы)

О, тем более скрам)

+1.
Регресс лучше максимально автоматизировать, манки-тестер - это скучно

Понимаю) пока учусь, так что это вопрос времени

При работе в стартапа и быстрых изменениях/правках/тз - автоматизация практически невозможна/слишком затратна

Спасибо!

У меня была отчасти похожая ситуация, если такого документа нет, могу посоветовать изложить своё видение QA процессов на проекте в виде QA plan/strategy, чтобы все включая вас понимали, что и как делает тестировщик и его роль в процессе разработки, и пошарить его со всей командой на ревью, попросить фидбэк от тимлида. Это может показаться непростой задачей по началу, но мне это очень помогло, т.к. сам начинаешь лучше понимать свою роль в процессах. Все наладится, успехов 🍀👍🏻

ой да что вы начинаете, разрабы и дизайнеры всех мастей вообще порой не понимают, на кой к ним приставили QA, ведь их код всегда идеален) потому не обращайте ни на кого внимания и просто тестируете как вы считаете нужным. Тем более если это фронт или дизайн - там тестировать - не перетестировать (все браузеры, если надо, то и мобилки)

В этом плане немножко сомневаюсь, потому что первый тестер, так еще и джун, и могу сама не понимать каких-то моментов. Но информирование всегда важно, это правда. Спасибо!)

Такая же ситуация, писала свой первый QA plan, проработав джуном 1,5 месяца и будучи единственным тестировщиком на проекте. По крайней мере у вас будет фидбэк от более опытных коллег, пусть и не тестировщиков. Когда/если придёт более опытный QA, но уже с высоты своего опыта подскажет, как можно улучшить процесс, внесёт свой вклад. В любом случае, вам будет легче и вы таким образом привнесёте прозрачности в процесс для всей команды. Но разумеется смотрите по ситуации, все индивидуально и зависит от многих факторов))

что такое QA план?

я так понял тестплан имеется в виду

Всем привет!
Подскажите пожалуйста, как можно с минимальным количеством боли перенести issues из редмайна в джиру?

скриптик попросить разработчика написать?)