Comments 17
Неплохо написано, но это, как бы, прописные истины :)
Да, этому мало кто следует, лишний раз можно перечитать, но хотелось бы реальных кейсов посмотреть. Что вы конкретно сделали, как это восприняла остальная команда, какие были сложности и противостояния?
У меня тоже был опыт построения более тесных взаимоотношений с разработчиками. И их лид не очень желал идти на встречу. Много усилий было приложено, чтобы коммиты моих ребят начали попадать в мастер.
Да, этому мало кто следует, лишний раз можно перечитать, но хотелось бы реальных кейсов посмотреть. Что вы конкретно сделали, как это восприняла остальная команда, какие были сложности и противостояния?
У меня тоже был опыт построения более тесных взаимоотношений с разработчиками. И их лид не очень желал идти на встречу. Много усилий было приложено, чтобы коммиты моих ребят начали попадать в мастер.
Большое спасибо за обратную связь :)
Очень здорово, что вы сейчас на том уровне, когда для вас это стало прописной истиной. Еще года три-четыре назад, я не знала, что вот так можно работать. (И думаю, среди читающих тоже найдутся юные коллеги, кто еще не верит в силу этих истин). В тех моих старых проектах, команды QA и команды разработчиков будто существовали параллельно, каждая сама по себе. Пока я не попала в анлийский проект, где девушка QA (англичанка с ямайскими корнями) была настолько ЛИДОМ, что все разработчики в сложных ситуациях спрашивали у нее «что мы будем делать дальше?». Тогда я и поняла насколько, это здорово, когда QA имеют голос, и заразилась от нее уверенностью, что наша роль в команде — действительно, важная и крутая! Поэтому мне сложно согласиться с утверждением, что этому мало кто следует. Мои два последних проекта только так и работают :). Так работал тот проект с той девушкой QA. И так работает мой текущий проект, где я сама QA Lead. Здесь тоже костяк девелоперов — англичане. ( Быть может лояльность и типичная вежливость англичан и служит мне хорошую службу...)
О том, что я конкретно сделала, чтобы закрепить свои позиции в команде, в которой вообще не понимали зачем нужны QA, я писала в статье, ссылка на которую дана в первых строках. Если коротко, когда я пришла на проект, я устроила meeting, на который созвала всех от CEO до рядовых девелоперов, где первый пункт обсуждения был " Какие ожидания у вас от меня?", а последним пунктом я рассказала «Что я буду делать, и как я представляю свою работу». И я во всеуслышание заручилась стопроцентной поддержкой и «благославением» всего руководства )))
После этого никто ни разу не пожелал «не идти мне навстречу» (русскоязычные разработчики здесь тоже имеются). Позже у нас появилась вторая QA, и девелоперы очень тщательно просматривали наши коммиты и давали подробные инструкции «как надо и как не надо делать». Моя история такова, мне жаль, что вам так не повезло с тем тим лидом...))
Очень здорово, что вы сейчас на том уровне, когда для вас это стало прописной истиной. Еще года три-четыре назад, я не знала, что вот так можно работать. (И думаю, среди читающих тоже найдутся юные коллеги, кто еще не верит в силу этих истин). В тех моих старых проектах, команды QA и команды разработчиков будто существовали параллельно, каждая сама по себе. Пока я не попала в анлийский проект, где девушка QA (англичанка с ямайскими корнями) была настолько ЛИДОМ, что все разработчики в сложных ситуациях спрашивали у нее «что мы будем делать дальше?». Тогда я и поняла насколько, это здорово, когда QA имеют голос, и заразилась от нее уверенностью, что наша роль в команде — действительно, важная и крутая! Поэтому мне сложно согласиться с утверждением, что этому мало кто следует. Мои два последних проекта только так и работают :). Так работал тот проект с той девушкой QA. И так работает мой текущий проект, где я сама QA Lead. Здесь тоже костяк девелоперов — англичане. ( Быть может лояльность и типичная вежливость англичан и служит мне хорошую службу...)
Что вы конкретно сделали, как это восприняла остальная команда, какие были сложности и противостояния?
О том, что я конкретно сделала, чтобы закрепить свои позиции в команде, в которой вообще не понимали зачем нужны QA, я писала в статье, ссылка на которую дана в первых строках. Если коротко, когда я пришла на проект, я устроила meeting, на который созвала всех от CEO до рядовых девелоперов, где первый пункт обсуждения был " Какие ожидания у вас от меня?", а последним пунктом я рассказала «Что я буду делать, и как я представляю свою работу». И я во всеуслышание заручилась стопроцентной поддержкой и «благославением» всего руководства )))
После этого никто ни разу не пожелал «не идти мне навстречу» (русскоязычные разработчики здесь тоже имеются). Позже у нас появилась вторая QA, и девелоперы очень тщательно просматривали наши коммиты и давали подробные инструкции «как надо и как не надо делать». Моя история такова, мне жаль, что вам так не повезло с тем тим лидом...))
Более плотная интеграция с разработкой это добро, общение идёт на одном языке. Но про ограниченность набора е2е UI тестов надо в школе рассказывать, это боль, особенно когда система сложная, с большим количеством интеграций и когда менеджмент не переубедить, что это путь ад поддержки тестов
Улыбка вам от меня в комментарии :)
Отличный план. Он не изобилует техническими деталями (это очень зависит от специфики проекта), и полезен тем QA, которые порой даже сами не совсем понимают свою роль. А некоторые не хотят развиваться в техническую сторону, утешая себя тем, что свою работу «мануальщика» они выполняют. Для них это возможность прочитать прописные истины и переосмыслить свою роль на проекте.
Отличный план. Он не изобилует техническими деталями (это очень зависит от специфики проекта), и полезен тем QA, которые порой даже сами не совсем понимают свою роль. А некоторые не хотят развиваться в техническую сторону, утешая себя тем, что свою работу «мануальщика» они выполняют. Для них это возможность прочитать прописные истины и переосмыслить свою роль на проекте.
Черт возьми, замечательная статья! Мне сейчас предстоит работа по построению QA процессов на проекте, не терпится применить ваши рекомендации :)
Большая к вам просьба — публикуйте свои статьи чаще, чем раз в полгода :)
Большая к вам просьба — публикуйте свои статьи чаще, чем раз в полгода :)
Как единственный тестер, так еще и мануальщик — прочитала статью с огромным интересом. И ваши комментарии тоже добавили поводов для мотивации, это супер круто, и радостно, что где-то есть такие компетентные специалисты.
:)
Статья очень хорошая и полезная.
Есть («вечные») вопросы по поводу окунания в написание юнит-тестов на долгоиграющем проекте, где этих тестов нет.
1) Есть понимание(ИМХО) что юниты пишут разрабы, а тестер, если в силах — помогает, дописывает, подсказывает. Но как подойти к тому, что бы их разработчики хотя бы начали писать?
2) И как организовывать эти тесты, если продукт постоянно меняется(как пример — банковское ПО)?
Статья очень хорошая и полезная.
Есть («вечные») вопросы по поводу окунания в написание юнит-тестов на долгоиграющем проекте, где этих тестов нет.
1) Есть понимание(ИМХО) что юниты пишут разрабы, а тестер, если в силах — помогает, дописывает, подсказывает. Но как подойти к тому, что бы их разработчики хотя бы начали писать?
2) И как организовывать эти тесты, если продукт постоянно меняется(как пример — банковское ПО)?
Спасибо за отклик ;)
В случае, когда на проекте их нет и разработчики не горят желанием их писать, а предложения от QA слышать не хотят, начинать работу нужно с менеджеров. Если на проекте введены позиции Quality Assuarance, это априори подразумевает организационную работу от этих людей по обеспечению высокого качества продукта. QA следует пообщаться с менеджерами:
— объяснить важность и нужность таких тестов (я не могу представить себе менеджера, который бы не согласился с этим)
— предложить стратегию по внедрению
(Варианты: 1. PR без автотестов не может получить апрув; 2. PR должен иметь хотя бы один апрув от QA(а они смотрят автотесты) )
— проявить настойчивость
А уж когда менеджеры официально поддержали и огласили, что «все, ребята, теперь работаем именно так», то тут уже разработчикам ничего не остается, как делать то, что нужно делать. Но и с ними мотивационную работу провести стоит ;) в идеале, у них у самих должен быть интерес делать качественный продукт. Я, наоборот, знала одного разработчика, который считал, что он настолько самодостаточный и классный, что ему подстраховка от QA не нужна. «Да, если вы завтра все исчезнете, я и не замечу, — говорил он, полушутя, — я свой функционал на 90 процентов покрываю тестами». :) А мне такая мотивация даже нравится.
У нас тоже постоянно что-то меняется, модифицируется. Но каждый разработчик, работая над куском функционала, неизменно чинит и поддерживает старые тесты, если они с новым кодом не работают. Его работа над текущим функционалом не может быть закончена, если есть сломанные тесты, просто потому что тесты автоматически крутятся на CI, которая интегрирована в github. И пока все его тесты не будут пройдены, github не даст ему смержить его обновление в master. В его PR будет светится сообщение: «Some checks were not successful. All check runs on this pull request must run successfully to enable automatic merging.» В этом и прелесть тестов в коде продукта, их постоянно поддерживает вся команда — по-другому нельзя.
Мое видение таково. Надеюсь, оно вам поможет.
1) Есть понимание(ИМХО) что юниты пишут разрабы, а тестер, если в силах — помогает, дописывает, подсказывает. Но как подойти к тому, что бы их разработчики хотя бы начали писать?
В случае, когда на проекте их нет и разработчики не горят желанием их писать, а предложения от QA слышать не хотят, начинать работу нужно с менеджеров. Если на проекте введены позиции Quality Assuarance, это априори подразумевает организационную работу от этих людей по обеспечению высокого качества продукта. QA следует пообщаться с менеджерами:
— объяснить важность и нужность таких тестов (я не могу представить себе менеджера, который бы не согласился с этим)
— предложить стратегию по внедрению
(Варианты: 1. PR без автотестов не может получить апрув; 2. PR должен иметь хотя бы один апрув от QA(а они смотрят автотесты) )
— проявить настойчивость
А уж когда менеджеры официально поддержали и огласили, что «все, ребята, теперь работаем именно так», то тут уже разработчикам ничего не остается, как делать то, что нужно делать. Но и с ними мотивационную работу провести стоит ;) в идеале, у них у самих должен быть интерес делать качественный продукт. Я, наоборот, знала одного разработчика, который считал, что он настолько самодостаточный и классный, что ему подстраховка от QA не нужна. «Да, если вы завтра все исчезнете, я и не замечу, — говорил он, полушутя, — я свой функционал на 90 процентов покрываю тестами». :) А мне такая мотивация даже нравится.
И как организовывать эти тесты, если продукт постоянно меняется(как пример — банковское ПО)?
У нас тоже постоянно что-то меняется, модифицируется. Но каждый разработчик, работая над куском функционала, неизменно чинит и поддерживает старые тесты, если они с новым кодом не работают. Его работа над текущим функционалом не может быть закончена, если есть сломанные тесты, просто потому что тесты автоматически крутятся на CI, которая интегрирована в github. И пока все его тесты не будут пройдены, github не даст ему смержить его обновление в master. В его PR будет светится сообщение: «Some checks were not successful. All check runs on this pull request must run successfully to enable automatic merging.» В этом и прелесть тестов в коде продукта, их постоянно поддерживает вся команда — по-другому нельзя.
Мое видение таково. Надеюсь, оно вам поможет.
Отличная статья и стратегия по автоматизации. У меня сейчас такой проект, где сложно и долго писать UI тесты, и очень много интеграции. Спасибо за идею реализации автоматизации. Это то, что мне нужно было.
Вот Вам смайл. =)
Да прибудет с Нами сила!
Подход хороший и, как мне кажется, правильный, у себя в компании движемся в том же направлении. Только вот какой вопрос — что если вместо привычной ноды или php (говорю опять-таки за себя) проект будет написан на условном go? И времени на освоение новой технологии нет? Это ведь разработчики имеют какую-то специализацию — фронт, бэк, реакт, C#… — тестировщик же будет тестировать проект независимо от стека. Как бы вы решили такой вопрос, Ирина?
Спасибо за интересный вопрос :)
Если ключевое здесь, что «И времени на освоение новой технологии нет» то я бы перешла на формат «требовать автотестов от разработчиков». Согласна, что для того, чтобы самому писать на новом языке программирования нужно подучиться. Тем не менее, я верю, что тот, кто хоть раз сам писал автотесты способен «прочитать» какие кейсы разработчик сейчас покрыл, а какие упустил, «язык автотестов» на многих языках программирования схож. Если прочитать не удается, я бы настаивала на включение в описание PR списка разработанных автотестов и ориентировалась на него. Я считаю, это полное право и обязанность команды QA максимально быть осведомленным о покрытии продукта автотестами, иначе вся идея Quality assurance теряется…
Если мы рассматриваем ситуацию жесткой ограниченности во времени всей команды, в том числе и девелопера, то я бы в ходе ревью настаивала на покрытии интеграционными автотестами критически/стратегически важных сценариев. А на все остальные сценарии документировала отдельные таски, чтобы сделать их позже. В любом проекте бывают спокойные периоды, когда нет дедлайнов — тогда и стоит акцентировать внимание Product Manager/Team Lead/Scrum Master-ов на том, чтобы включать в работу эти таски: посложнее — пусть делают разработчики, на самых простых — учиться самой.
Читая вопросы, которые поступают (не конкретно ваш), все чаще наталкиваюсь на мысль, что, как и 10 лет назад, так и сейчас во многих проектах остается проблема, что QA приходится «отвоевывать должный авторитет» и «добиваться от разработчиков продуктивного взаимодействия»… надо будет попробовать написать мотивационно-руководствующую статью о своем опыте и взгляде на эту тему :)
Если ключевое здесь, что «И времени на освоение новой технологии нет» то я бы перешла на формат «требовать автотестов от разработчиков». Согласна, что для того, чтобы самому писать на новом языке программирования нужно подучиться. Тем не менее, я верю, что тот, кто хоть раз сам писал автотесты способен «прочитать» какие кейсы разработчик сейчас покрыл, а какие упустил, «язык автотестов» на многих языках программирования схож. Если прочитать не удается, я бы настаивала на включение в описание PR списка разработанных автотестов и ориентировалась на него. Я считаю, это полное право и обязанность команды QA максимально быть осведомленным о покрытии продукта автотестами, иначе вся идея Quality assurance теряется…
Если мы рассматриваем ситуацию жесткой ограниченности во времени всей команды, в том числе и девелопера, то я бы в ходе ревью настаивала на покрытии интеграционными автотестами критически/стратегически важных сценариев. А на все остальные сценарии документировала отдельные таски, чтобы сделать их позже. В любом проекте бывают спокойные периоды, когда нет дедлайнов — тогда и стоит акцентировать внимание Product Manager/Team Lead/Scrum Master-ов на том, чтобы включать в работу эти таски: посложнее — пусть делают разработчики, на самых простых — учиться самой.
Читая вопросы, которые поступают (не конкретно ваш), все чаще наталкиваюсь на мысль, что, как и 10 лет назад, так и сейчас во многих проектах остается проблема, что QA приходится «отвоевывать должный авторитет» и «добиваться от разработчиков продуктивного взаимодействия»… надо будет попробовать написать мотивационно-руководствующую статью о своем опыте и взгляде на эту тему :)
Sign up to leave a comment.
Как QA организовать автоматизацию тестирования на проекте. Один практически примененный способ