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.» В этом и прелесть тестов в коде продукта, их постоянно поддерживает вся команда — по-другому нельзя.
Большое спасибо за обратную связь :)
Очень здорово, что вы сейчас на том уровне, когда для вас это стало прописной истиной. Еще года три-четыре назад, я не знала, что вот так можно работать. (И думаю, среди читающих тоже найдутся юные коллеги, кто еще не верит в силу этих истин). В тех моих старых проектах, команды QA и команды разработчиков будто существовали параллельно, каждая сама по себе. Пока я не попала в анлийский проект, где девушка QA (англичанка с ямайскими корнями) была настолько ЛИДОМ, что все разработчики в сложных ситуациях спрашивали у нее «что мы будем делать дальше?». Тогда я и поняла насколько, это здорово, когда QA имеют голос, и заразилась от нее уверенностью, что наша роль в команде — действительно, важная и крутая! Поэтому мне сложно согласиться с утверждением, что этому мало кто следует. Мои два последних проекта только так и работают :). Так работал тот проект с той девушкой QA. И так работает мой текущий проект, где я сама QA Lead. Здесь тоже костяк девелоперов — англичане. ( Быть может лояльность и типичная вежливость англичан и служит мне хорошую службу...)
Что вы конкретно сделали, как это восприняла остальная команда, какие были сложности и противостояния?
О том, что я конкретно сделала, чтобы закрепить свои позиции в команде, в которой вообще не понимали зачем нужны QA, я писала в статье, ссылка на которую дана в первых строках. Если коротко, когда я пришла на проект, я устроила meeting, на который созвала всех от CEO до рядовых девелоперов, где первый пункт обсуждения был " Какие ожидания у вас от меня?", а последним пунктом я рассказала «Что я буду делать, и как я представляю свою работу». И я во всеуслышание заручилась стопроцентной поддержкой и «благославением» всего руководства )))
После этого никто ни разу не пожелал «не идти мне навстречу» (русскоязычные разработчики здесь тоже имеются). Позже у нас появилась вторая QA, и девелоперы очень тщательно просматривали наши коммиты и давали подробные инструкции «как надо и как не надо делать». Моя история такова, мне жаль, что вам так не повезло с тем тим лидом...))
Пожалуйста! Мне приятно знать, что статья понравилась.
Чувствую, что писанина временами вам сильно докучает. Вам она, наверно, кажется незначимой деятельностью в работе команды «Тьфу! А собственно дела немного». Но все-таки, в моем видении вы делаете важную работу, во-первых, именно строго записанные инструкции и тест кейсы помогают создать порядок из рабочего хаоса (кроме того, проверка функционирования по памяти, без плана, очень опасна тем, что баги будут пропущены и вся работа команды окажется неплодотворной для клиента, то есть вы как раз прикрываете все тылы), во-вторых, прописывая тест кейсы для автоматизаторов вы, становитесь тем самым главным экспертом по функциональности продукта из п.5, ибо нет лучшего способа понять что-то, чем попытаться донести это другому. Попробуйте поменять свое отношение к тому, что вы делаете, станет приятнее работать ;)
Ну а если поменять отношение не получается, просто не растягивайте эту не самую приятную работу для вас, сделайте ее быстренько (мы часто растягиваем то, что нам неинтересно) и поощерите себя тем, что поработаете над другими задачами, которые вам в кайф!
Сегодня, например, можно быстрее окончить «всю писанину» и почитать книгу «Как тестируют в гугл», тк у вас есть отдельно автоматизаторы, и отдельно ручные тестировщики, которые готовят им почву для работы, возможно, у вас пытаются привить некоторые идеи оттуда. Пролистайте главу 3, она как раз про вашу позицию в команде.
Удачи Вам!
А автотесты у вас уже были введены на проекте получается? Или вам приходится еще и их введением заниматься?
Автотесты уже были введены и использовались все, кроме end-to-end тестов. Последние выполнялись вручную по необходимости. Если верить пирамиде тестирования — это не великая беда, но тем не менее жизнь проще, когда они есть в заавтоматизированном виде. Поэтому этой категорией автотестов я сейчас занимаюсь. Они почти готовы, пока гоняю вручную. Следующий шаг — интегрировать их в jenkins/circleCi.
В случае, когда на проекте их нет и разработчики не горят желанием их писать, а предложения от 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.» В этом и прелесть тестов в коде продукта, их постоянно поддерживает вся команда — по-другому нельзя.
Мое видение таково. Надеюсь, оно вам поможет.
Спасибо!
Очень здорово, что вы сейчас на том уровне, когда для вас это стало прописной истиной. Еще года три-четыре назад, я не знала, что вот так можно работать. (И думаю, среди читающих тоже найдутся юные коллеги, кто еще не верит в силу этих истин). В тех моих старых проектах, команды QA и команды разработчиков будто существовали параллельно, каждая сама по себе. Пока я не попала в анлийский проект, где девушка QA (англичанка с ямайскими корнями) была настолько ЛИДОМ, что все разработчики в сложных ситуациях спрашивали у нее «что мы будем делать дальше?». Тогда я и поняла насколько, это здорово, когда QA имеют голос, и заразилась от нее уверенностью, что наша роль в команде — действительно, важная и крутая! Поэтому мне сложно согласиться с утверждением, что этому мало кто следует. Мои два последних проекта только так и работают :). Так работал тот проект с той девушкой QA. И так работает мой текущий проект, где я сама QA Lead. Здесь тоже костяк девелоперов — англичане. ( Быть может лояльность и типичная вежливость англичан и служит мне хорошую службу...)
О том, что я конкретно сделала, чтобы закрепить свои позиции в команде, в которой вообще не понимали зачем нужны QA, я писала в статье, ссылка на которую дана в первых строках. Если коротко, когда я пришла на проект, я устроила meeting, на который созвала всех от CEO до рядовых девелоперов, где первый пункт обсуждения был " Какие ожидания у вас от меня?", а последним пунктом я рассказала «Что я буду делать, и как я представляю свою работу». И я во всеуслышание заручилась стопроцентной поддержкой и «благославением» всего руководства )))
После этого никто ни разу не пожелал «не идти мне навстречу» (русскоязычные разработчики здесь тоже имеются). Позже у нас появилась вторая QA, и девелоперы очень тщательно просматривали наши коммиты и давали подробные инструкции «как надо и как не надо делать». Моя история такова, мне жаль, что вам так не повезло с тем тим лидом...))
Чувствую, что писанина временами вам сильно докучает. Вам она, наверно, кажется незначимой деятельностью в работе команды «Тьфу! А собственно дела немного». Но все-таки, в моем видении вы делаете важную работу, во-первых, именно строго записанные инструкции и тест кейсы помогают создать порядок из рабочего хаоса (кроме того, проверка функционирования по памяти, без плана, очень опасна тем, что баги будут пропущены и вся работа команды окажется неплодотворной для клиента, то есть вы как раз прикрываете все тылы), во-вторых, прописывая тест кейсы для автоматизаторов вы, становитесь тем самым главным экспертом по функциональности продукта из п.5, ибо нет лучшего способа понять что-то, чем попытаться донести это другому. Попробуйте поменять свое отношение к тому, что вы делаете, станет приятнее работать ;)
Ну а если поменять отношение не получается, просто не растягивайте эту не самую приятную работу для вас, сделайте ее быстренько (мы часто растягиваем то, что нам неинтересно) и поощерите себя тем, что поработаете над другими задачами, которые вам в кайф!
Сегодня, например, можно быстрее окончить «всю писанину» и почитать книгу «Как тестируют в гугл», тк у вас есть отдельно автоматизаторы, и отдельно ручные тестировщики, которые готовят им почву для работы, возможно, у вас пытаются привить некоторые идеи оттуда. Пролистайте главу 3, она как раз про вашу позицию в команде.
Удачи Вам!
Ага, трекер от Vive. Увы, больше никакого дополнительного оборудования нам для проектов не пригождалось.
Приятно знать, спасибо!
Автотесты уже были введены и использовались все, кроме end-to-end тестов. Последние выполнялись вручную по необходимости. Если верить пирамиде тестирования — это не великая беда, но тем не менее жизнь проще, когда они есть в заавтоматизированном виде. Поэтому этой категорией автотестов я сейчас занимаюсь. Они почти готовы, пока гоняю вручную. Следующий шаг — интегрировать их в jenkins/circleCi.