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