Крутая подборка рекомендаций, благодарю. Тоже заметил, что люди, которые приходя в компанию, воспринимают ее как "свою" и выстраивают работу соответственно - хорошо продвигаются и по росту скиллов и по карьере :)
Довольно структурированно и мотивирующе выглядит статья, благодарю ) Тоже хочу попробовать на каком-нибудь небольшом проекте питон попробовать, а то у нас всё на java, а у меня с ней как-то не сложилось ))
Мне в целом нравится подход когда QA в продуктовой команде и проводит ручное тестирование и пишет тесты на готовую стори/баг из своего спринта (при условии что есть готовый фреймворк, который написал кто-то из AQA/SDET).
Это правда надо в definition of done задачи закладывать и включать в оценку задач спринта, да и часть тестов (особенно unit, которых больше всего в пирамиде) должны разработчики писать, а qa могут подсказать какие-то дополнительные проверки в них.
Но чаще видел когда автоматизаторы отдельно, а ручное тестирование отдельно.
У нас у техподдержки своя Jira, у разработки и тестирования своя, поэтому это несколько усложняет процесс. Но в целом наша техподдержка достаточно адекватная, специалисты со второй линии могут сами полезть в серверные логи, найти информацию, при необходимости запросить у пользователей логи с устройств и передать нам.
Общение есть в небольшом чате который связан с нашей частью продукта, где наша скрам команда и пара человек из саппорта + из ops человек, так что особо не отвлекаемся.
Есть еще правда бета, куда выделенные пользователи отправляют вопросы, жалобы и предложения. Мы его выборочно просматриваем, но нам в отдельный tg чатик присылают жалобы уже по согласованному шаблону, и дальше мы смотрим, что с этим делать. В целом хаоса еще много, но уже лучше, чем было полгода назад :)
Спасибо за статью, интересный опыт трансформации взаимодействия между отделами.
Крутая подборка рекомендаций, благодарю. Тоже заметил, что люди, которые приходя в компанию, воспринимают ее как "свою" и выстраивают работу соответственно - хорошо продвигаются и по росту скиллов и по карьере :)
Довольно структурированно и мотивирующе выглядит статья, благодарю ) Тоже хочу попробовать на каком-нибудь небольшом проекте питон попробовать, а то у нас всё на java, а у меня с ней как-то не сложилось ))
Это правда надо в definition of done задачи закладывать и включать в оценку задач спринта, да и часть тестов (особенно unit, которых больше всего в пирамиде) должны разработчики писать, а qa могут подсказать какие-то дополнительные проверки в них.
Но чаще видел когда автоматизаторы отдельно, а ручное тестирование отдельно.
Общение есть в небольшом чате который связан с нашей частью продукта, где наша скрам команда и пара человек из саппорта + из ops человек, так что особо не отвлекаемся.
Есть еще правда бета, куда выделенные пользователи отправляют вопросы, жалобы и предложения. Мы его выборочно просматриваем, но нам в отдельный tg чатик присылают жалобы уже по согласованному шаблону, и дальше мы смотрим, что с этим делать. В целом хаоса еще много, но уже лучше, чем было полгода назад :)
Спасибо за статью, интересный опыт трансформации взаимодействия между отделами.