Одна, дополненная другой, мои статьи получились возможным руководством к действию для тех, кто еще не нашел «свой стиль» и не уверен с чего начать.
Кое-кто отозвался, что я пишу о «прописных истинах», но при этом я получила хороший отклик в комментариях и личных сообщениях из разряда «было полезно», «то, что мне сейчас нужно» и т.п. Но были и вопросы. Вопросы, по большей части, сводились к той «боли», которая не минует ни одного QA за его карьеру:
Сразу оговорюсь, что тема очень щекотливая, говоря о ней всегда приходится балансировать на грани того, чтобы не задеть самолюбие как разработчиков, так и самих QA. Поэтому я очень прошу читать с холодным сердцем и просто попробовать выделить себе пару полезных пунктов и опробовать их на практике.
Во-первых, как показывает практика, зачастую те QA, которым не удается вклиниться в разработку так, как этого требует профессия
Во-вторых, разработчики в команде воспринимают QA как придаток, который просто нажимает на кнопки прежде, чем отдать продукт клиенту, либо просто не представляют, как с ними взаимодействовать. Это может быть обусловлено тем, что
Начнем с первой проблемы.
Хочешь изменить мир, начни с себя. Известная и очень уместная в нашей теме истина.
Как QA Engineer-у вам, действительно, не помешает разобраться на какой вы позиции работаете. Если ваш проект еще живет по принципам waterfall архитектуры, и вас наняли просто мануальным тестировщиком, который наподобие ОТК на предприятиях осуществляет проверку готовности конечной продукции, то это одно, и здесь все довольно прозрачно.
А если вы находитесь на позиции полноценного QA Engineer, что сейчас почти повсеместно, то значит, что ваша ответственность, заложенная канонами этой профессии в [1], это не только тестирование готового продукта, но и непосредственно участие в организации процессов его создания и взаимодействия участников всего проекта. Помните, пожалуйста, что без четких процессов и организованности команды получить качественный продукт почти невозможно, поэтому на этом поприще голос QA должен звучать уверенно и четко. Предотвращать появление багов, а не фиксить постфактум — это удел хорошо организованных команд. А прилагать усилия на сведение количества багов к минимуму — это удел команды QA. (Круг замыкается.)
Поэтому самое первое, воскресите в памяти все фундаментальные вещи о принципах, типах, уровнях тестирования и формулировку определения профессии QA Engineer. Разберитесь с пресловутыми «Кто я?» и «Зачем я здесь?».
Когда с профессиональным самокопанием покончено обрисуйте себе план, что вы будете делать, можете взять идеи из моих статей, либо составить свой собственный план, подходящий под ваши обстоятельства. Каждый пункт вашей деятельности должен быть понятен вам самому — зачем он, как его внедрить, какой профит.
Только в таком случае у вас получится говорить на проекте уверенно. Даже если вы пока знаете только ответы на вопросы «зачем» и «какая выгода», но не знаете «как». Чувствуйте себя уверенно уже от того, что вы видите фронт работы, правильная постановка задачи — это 80% успеха.
Следующим шагом, запишите вопросы которые нужно решить, чтоб ответить на вопрос «как». И идите с этим в люди, то есть обсуждайте с командой — на специально организованном собрании, в чате между делом или неформально на кухне за чашкой кофе, не важно. Важно, что у вас на проекте полно людей, у которых есть другой опыт, другие знания, используйте этот кладезь полезной информации, общайтесь, спрашивайте и все обязательно прояснится.
Если вы очень стеснительны или по жизни максималист, который всегда стремитесь быть в лидерах, то в роли QA придется непросто. Потому что QA Engineer – это инженер, это человек, причастный к разработке, но при этом мы оказываемся на проектах с разным стеком технологий и архитектурой, в то время как разработчики имеют свою четкую специализацию. Признавать, что вы «не в теме» для некоторых людей означает записать себя в «слабое звено». И это и была моя проблема, с которой я боролась долго-долго. «Это что, мне надо сказать, что я не знаю, что я не умею, что я не понимаю?!» — не раз впадала я в ступор на обсуждениях полных технических аспектов.
Вот только в какой-то момент до меня, наконец, дошло, что не знать — не стыдно. Стыдно продолжать «прятаться в ракушку» и не пытаться узнать. А отмалчиваться, чтоб казаться всепонимающим, себе дороже.
Вас наняли на работу, ваше резюме читали (на завирайте свои способности ;) ), с вами общались на собеседовании, и вас взяли на работу. Значит ваш стек технических навыков всех устроил и те, кто нанял вас, догадывался, чего можно ожидать. Поэтому прыгать выше головы сейчас нет никакого смысла И когда вы говорите «мне не доводилось с таким работать, но я хочу разобраться, помогите понять вот это и вот это» — это абсолютно нормальная, здоровая и правильная ситуация (не доводите только до абсурда самые первичные знания — определения и формулировки — почерпните из интернета). И когда вы окружающим обозначаете, что вот эта техническая подоплека вам не понятна, во-первых, они уже чувствуют, что надо изъясняться проще, во-вторых, вы с чистой совестью можете задавать уточняющие вопросы. Если бы писали код на раз-два и понимали полностью внутреннюю архитектуру проекта, то вы бы, наверно, прямо разработкой и занимались, правда?
И мой маленький любимый прием — всегда помогать другим, когда я в силах — делом, советом, добрым словом, это возвращается взаимным желанием других помогать мне.
Примите как данность, что рабочие процессы подразумевают обсуждение всех возможных вариантов. В споре рождается истина. Ваша задача не оказаться правым, а находить лучшие решения. И если вы хотите, что-то предложить, но боитесь, что прозвучите глупо, то поверьте, сколько команд я видела, проигрышнее всего выглядят безучастные отмалчивающиеся коллеги. Признавать какие-то свои ошибки, поддерживать лучшие идеи и с энтузиазмом способствовать их воплощению — это здоровый рабочий процесс.
Помните, героиня Муравьевой в фильме «Москва слезам не верит» перед походом в библиотеку настраивала себя: «если ляпаешь, ляпай уверенно — тогда это называется точкой зрения». Это, правда, работает.
Не бойтесь накликать на себя задачи, с которыми вы не справитесь. Запомните, вы работаете в команде и говорить о том, что что-то не получается и просить команду помочь — это нормально.
И даже если в ходе вашей работы вы придете к выводу «так делать не надо» — это будет прогресс, потому что следующим шагом вы найдете лучшее решение.
Эти устои, что QA — это должность низкая, она не так важна и не так существенна так или иначе встречаются в коллективах. И пока вы сами думаете так, вы эту тенденцию быть недооцененным, увы, подкармливаете.
Вы каждый день работаете, вы каждый день прилагаете усилия, делая продукт и команду лучше, вы тратите силы и время, ваша позиция заложена в рамках проектах — значит это важно и нужно. Все. Не оставляйте места самоедству, и не оставляйте места в своей голове «колкостям» от тех, кто считает, что вы — статусом ниже, чем он. Эти времена, когда были простые ручные тестировщики monkey-tester канули в лету, в перспективе QA Engineer ы — это «отряд элитного спецназа, успех которого зависит от превосходной тактики и современного вооружения» [2].
Запомните, что сегодня в передовых компаниях, таких как, например, Microsoft и Google «за качество отвечают разработчики. Если продукт сломается после выпуска, то шишки полетят в разработчика, создавшего проблему, а не в тестировщика, который ее не нашел»[2]. Поэтому в таких компаниях иметь команду QA, которая поможет сделать качественный продукт, — это привилегия для разработчиков.
И в ваших руках — внедрять передовые устои в ваши компании, вместо того, чтобы оглядываться на прошлые стереотипы.
Но я опять же возвращаюсь к тому, что вам в своем проекте нужно постоянно расти. Если вы пришли на проект, прошло полгода, а вы до сих пор не придумали эффективную автоматизацию тестирования, не стремитесь разобраться в том, что делает команда, не анализируете существующие автотесты, то вы не совсем та элита о которых пишут в книгах.
Существуют команды, которые живут вообще без позиции QA Engineer, я знаю такие. И если вы уже сегодня стремитесь погружаться в проект и научитесь писать автотесты вместе с разработчиками, однажды вы сможете продать свои компетенции даже туда и стать там software engineer in test.
Когда работа над собой окончена, самое время поработать над налаживанием коллаборации с разработчиками.
Самое главное
Пусть изменения на проекте будут плавными. Если вы однажды утром придете на работу и заявите «я тут статью на Хабре прочитал, и начнете шлепать ботинком по условной трибуне, сотрясая воздух, мол, теперь я вам покажу Кузькину мать!», на вас посмотрят как на странного, это факт. Да и вам будет сложно — сталкиваясь с проблемами по всем фронтам — появится непреодолимое желание бросить всю затею по улучшению работы QA.
Лучше ставьте маленькие всем понятные задачи, достигайте их и беритесь за следующие. Аккуратно двигайтесь вперед, время летит быстро, однажды будет приятно обернуться назад.
После второй моей статьи, которая предлагала тесную работу QA и разработки, у аудитории обнажились настроения из разряда «мы пытались, но тим лид девелоперов не очень-то хотел идти на встречу». Со своего имеющегося уровня профессионального развития я могу советовать только следующее.
Будьте доброжелательны и относитесь с мудрым спокойствием к тем, кто не принимает вашу работу так, как вы того ожидаете. На своей практике я встречала много разных разработчиков и все те, которые были по-настоящему профессионально зрелыми, всегда шли мне навстречу, всегда помогали, и мы достигали прекрасных совместных результатов, ими все оставались довольны. Те, кто «фыркает» и «отмахивается от вас», увы, из категории «профессиональных тинейджеров». Они еще не научились совладать со своими чувствами, считая себя самыми правыми (и физический возраст тут не играет роли). Они попросту не умеют работать в команде, а вы — ее неотъемлемая часть. Вы как раз можете помочь им вырасти, но, к сожалению, некоторые не вырастают никогда. И тут можно только влиять на них через поддержку руководства и коллективный авторитет остальной части команды, которая вас поддержит. Если вы знаете лучшие способы, делитесь!
Еще там был интересный вопрос о том, как быть если ты просто еще не умеешь читать код разработчика, не можешь разобраться с их автотестами.
Я оставлю свой ответ и здесь, чтобы он не потерялся, быть может кому-то пригодится. Если прочитать не удается, я бы настаивала на включение в описание PR списка разработанных автотестов и ориентировалась на него. Я считаю, это полное право и обязанность команды QA максимально быть осведомленным о покрытии продукта автотестами, иначе вся идея Quality assurance теряется… Если мы рассматриваем ситуацию жесткой ограниченности во времени всей команды, в том числе и девелопера, то я бы в ходе ревью настаивала на покрытии интеграционными автотестами критически/стратегически важных сценариев. А на все остальные сценарии документировала отдельные таски, чтобы сделать их позже. В любом проекте бывают спокойные периоды, когда нет дедлайнов — тогда и стоит акцентировать внимание Product Manager/Team Lead/Scrum Master-ов на том, чтобы включать в работу эти таски: посложнее — пусть делают разработчики, на самых простых — учиться самому.
Не могу сказать, что все то, что написано выше непременно вам поможет, все-таки, есть у меня такое чувство, что собственный профессиональный голос и стиль приходят с опытом и через набитые шишки. Нельзя взять и как через трафарет приложить чужой сценарий работы к своему проекту. Но если моя писанина побудила вас не мириться с моментами, которые вам не нравятся, и у вас в голове появились идеи, что вы можете сделать хорошего для себя, для команды, для продукта, значит я потратила время не зря. И да, не подумайте что я изображаю QA Акулу, которая все знает, все умеет. Я учусь и меняюсь постоянно. Прекрасно отдаю себе отчет в том, что через год мои принципы работы могут измениться. Всегда очень рада обратной связи и с удовольствием поучусь вашему опыту, пишите ;)
А если хочется что-то почитать для упрочнения собственной мотивации начните с двух замечательных книжек, отсылку к которым я давала в тексте:
1. Foundations of Software Testing: ISTQB Certification
by Dorothy Graham, Rex Black, Erik van Veenendaal, Isabel Evans
2. Как тестируют в Google
Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло
Всем спасибо за внимание!
Кое-кто отозвался, что я пишу о «прописных истинах», но при этом я получила хороший отклик в комментариях и личных сообщениях из разряда «было полезно», «то, что мне сейчас нужно» и т.п. Но были и вопросы. Вопросы, по большей части, сводились к той «боли», которая не минует ни одного QA за его карьеру:
- как эффективно взаимодействовать с разработчиками?
- как выстраивать работу с ними так, чтобы они приняли: на проекте есть еще одно мнение, мнение QA, и оно тоже важно?
- как побудить их взаимодействовать, например, при построении совместной автоматизации тестирования, когда они не настроены к совместной работе?
- как действовать в том случае, когда твоих технических навыков в стеке используемых технологий просто не хватает?
Сразу оговорюсь, что тема очень щекотливая, говоря о ней всегда приходится балансировать на грани того, чтобы не задеть самолюбие как разработчиков, так и самих QA. Поэтому я очень прошу читать с холодным сердцем и просто попробовать выделить себе пару полезных пунктов и опробовать их на практике.
Введение
Во-первых, как показывает практика, зачастую те QA, которым не удается вклиниться в разработку так, как этого требует профессия
- попросту не уверенны в себе. Они не могут добиться того, чтобы их слышали, потому что говорят не слышно, не аргументированно, высказывая постоянные сомнения;
- боятся ошибиться и навлечь на себя лишнюю ответственность;
- комплексуют из-за несовершенных технических знаний.
Во-вторых, разработчики в команде воспринимают QA как придаток, который просто нажимает на кнопки прежде, чем отдать продукт клиенту, либо просто не представляют, как с ними взаимодействовать. Это может быть обусловлено тем, что
- они до сих пор мыслят о QA как о тестировщиках 10-20 летней давности, когда те, действительно были таковыми;
- все предыдущие QA, с которыми они работали именно так себя и вели, и они просто не знают, что бывает как-то иначе;
- в принципе, не представляют, в чем по сути своей заключается специфика работы QA Engineer, т. к. им это просто не нужно — они развиваются в своих навыках;
- разработка кода уже устоялась и менять в ней что-то просто лень.
Начнем с первой проблемы.
QA Engineer! Проведи генеральную уборку в свой голове
Поработайте над пониманием своей профессии
Хочешь изменить мир, начни с себя. Известная и очень уместная в нашей теме истина.
Как QA Engineer-у вам, действительно, не помешает разобраться на какой вы позиции работаете. Если ваш проект еще живет по принципам waterfall архитектуры, и вас наняли просто мануальным тестировщиком, который наподобие ОТК на предприятиях осуществляет проверку готовности конечной продукции, то это одно, и здесь все довольно прозрачно.
А если вы находитесь на позиции полноценного QA Engineer, что сейчас почти повсеместно, то значит, что ваша ответственность, заложенная канонами этой профессии в [1], это не только тестирование готового продукта, но и непосредственно участие в организации процессов его создания и взаимодействия участников всего проекта. Помните, пожалуйста, что без четких процессов и организованности команды получить качественный продукт почти невозможно, поэтому на этом поприще голос QA должен звучать уверенно и четко. Предотвращать появление багов, а не фиксить постфактум — это удел хорошо организованных команд. А прилагать усилия на сведение количества багов к минимуму — это удел команды QA. (Круг замыкается.)
Поэтому самое первое, воскресите в памяти все фундаментальные вещи о принципах, типах, уровнях тестирования и формулировку определения профессии QA Engineer. Разберитесь с пресловутыми «Кто я?» и «Зачем я здесь?».
Находите ответы на вопросы
Когда с профессиональным самокопанием покончено обрисуйте себе план, что вы будете делать, можете взять идеи из моих статей, либо составить свой собственный план, подходящий под ваши обстоятельства. Каждый пункт вашей деятельности должен быть понятен вам самому — зачем он, как его внедрить, какой профит.
Только в таком случае у вас получится говорить на проекте уверенно. Даже если вы пока знаете только ответы на вопросы «зачем» и «какая выгода», но не знаете «как». Чувствуйте себя уверенно уже от того, что вы видите фронт работы, правильная постановка задачи — это 80% успеха.
Следующим шагом, запишите вопросы которые нужно решить, чтоб ответить на вопрос «как». И идите с этим в люди, то есть обсуждайте с командой — на специально организованном собрании, в чате между делом или неформально на кухне за чашкой кофе, не важно. Важно, что у вас на проекте полно людей, у которых есть другой опыт, другие знания, используйте этот кладезь полезной информации, общайтесь, спрашивайте и все обязательно прояснится.
Отбросьте переживания, что вы не совершенны
Если вы очень стеснительны или по жизни максималист, который всегда стремитесь быть в лидерах, то в роли QA придется непросто. Потому что QA Engineer – это инженер, это человек, причастный к разработке, но при этом мы оказываемся на проектах с разным стеком технологий и архитектурой, в то время как разработчики имеют свою четкую специализацию. Признавать, что вы «не в теме» для некоторых людей означает записать себя в «слабое звено». И это и была моя проблема, с которой я боролась долго-долго. «Это что, мне надо сказать, что я не знаю, что я не умею, что я не понимаю?!» — не раз впадала я в ступор на обсуждениях полных технических аспектов.
Вот только в какой-то момент до меня, наконец, дошло, что не знать — не стыдно. Стыдно продолжать «прятаться в ракушку» и не пытаться узнать. А отмалчиваться, чтоб казаться всепонимающим, себе дороже.
Вас наняли на работу, ваше резюме читали (на завирайте свои способности ;) ), с вами общались на собеседовании, и вас взяли на работу. Значит ваш стек технических навыков всех устроил и те, кто нанял вас, догадывался, чего можно ожидать. Поэтому прыгать выше головы сейчас нет никакого смысла И когда вы говорите «мне не доводилось с таким работать, но я хочу разобраться, помогите понять вот это и вот это» — это абсолютно нормальная, здоровая и правильная ситуация (не доводите только до абсурда самые первичные знания — определения и формулировки — почерпните из интернета). И когда вы окружающим обозначаете, что вот эта техническая подоплека вам не понятна, во-первых, они уже чувствуют, что надо изъясняться проще, во-вторых, вы с чистой совестью можете задавать уточняющие вопросы. Если бы писали код на раз-два и понимали полностью внутреннюю архитектуру проекта, то вы бы, наверно, прямо разработкой и занимались, правда?
И мой маленький любимый прием — всегда помогать другим, когда я в силах — делом, советом, добрым словом, это возвращается взаимным желанием других помогать мне.
Не бойтесь ошибаться
Примите как данность, что рабочие процессы подразумевают обсуждение всех возможных вариантов. В споре рождается истина. Ваша задача не оказаться правым, а находить лучшие решения. И если вы хотите, что-то предложить, но боитесь, что прозвучите глупо, то поверьте, сколько команд я видела, проигрышнее всего выглядят безучастные отмалчивающиеся коллеги. Признавать какие-то свои ошибки, поддерживать лучшие идеи и с энтузиазмом способствовать их воплощению — это здоровый рабочий процесс.
Помните, героиня Муравьевой в фильме «Москва слезам не верит» перед походом в библиотеку настраивала себя: «если ляпаешь, ляпай уверенно — тогда это называется точкой зрения». Это, правда, работает.
Не бойтесь накликать на себя задачи, с которыми вы не справитесь. Запомните, вы работаете в команде и говорить о том, что что-то не получается и просить команду помочь — это нормально.
И даже если в ходе вашей работы вы придете к выводу «так делать не надо» — это будет прогресс, потому что следующим шагом вы найдете лучшее решение.
Отпустите устаревшие стандарты, смотрите в будущее
Эти устои, что QA — это должность низкая, она не так важна и не так существенна так или иначе встречаются в коллективах. И пока вы сами думаете так, вы эту тенденцию быть недооцененным, увы, подкармливаете.
Вы каждый день работаете, вы каждый день прилагаете усилия, делая продукт и команду лучше, вы тратите силы и время, ваша позиция заложена в рамках проектах — значит это важно и нужно. Все. Не оставляйте места самоедству, и не оставляйте места в своей голове «колкостям» от тех, кто считает, что вы — статусом ниже, чем он. Эти времена, когда были простые ручные тестировщики monkey-tester канули в лету, в перспективе QA Engineer ы — это «отряд элитного спецназа, успех которого зависит от превосходной тактики и современного вооружения» [2].
Запомните, что сегодня в передовых компаниях, таких как, например, Microsoft и Google «за качество отвечают разработчики. Если продукт сломается после выпуска, то шишки полетят в разработчика, создавшего проблему, а не в тестировщика, который ее не нашел»[2]. Поэтому в таких компаниях иметь команду QA, которая поможет сделать качественный продукт, — это привилегия для разработчиков.
И в ваших руках — внедрять передовые устои в ваши компании, вместо того, чтобы оглядываться на прошлые стереотипы.
Но я опять же возвращаюсь к тому, что вам в своем проекте нужно постоянно расти. Если вы пришли на проект, прошло полгода, а вы до сих пор не придумали эффективную автоматизацию тестирования, не стремитесь разобраться в том, что делает команда, не анализируете существующие автотесты, то вы не совсем та элита о которых пишут в книгах.
Существуют команды, которые живут вообще без позиции QA Engineer, я знаю такие. И если вы уже сегодня стремитесь погружаться в проект и научитесь писать автотесты вместе с разработчиками, однажды вы сможете продать свои компетенции даже туда и стать там software engineer in test.
QA Engineer! Проведи тонкую настройку работы в команде
Когда работа над собой окончена, самое время поработать над налаживанием коллаборации с разработчиками.
Самое главное
- ваши действия должны быть понятны и прозрачны для команды. Самое простое и эффективное — это донести до них свою миссию. Если вы ни с того, ни с сего начинаете лезть к ним в пулл реквесты с вопросами «а что это у вас тут за тесты?», «а вот надо бы еще вот такой тест написать», то первая (защитная) реакция будет «ты то куда лезешь?!», «кто ты такой/такая, чтобы критиковать мою работу?!». Он может неделю этот бранч готовил, наконец-то выдохнул, а тут еще QA «нарисовались». Поэтому расскажите им заранее, что вы собираетесь делать, почему и какая выгода от этого для проекта и команды. Подготовьте почву.
- Ваше участие в разработке априори должно восприниматься как благо, как то, что качественно улучшает работу разработчику. Станьте ему партнером. Например, просвещайте — расскажите как клиенты, скорее всего, будут использовать функционал, какие баги уже случались и какие нужно постараться избежать, а значит вместе подумайте какие тесты и почему важны. Не общайтесь в повелительном наклонении. Можете даже прибегать к психологическим хитростям — отмечать тех, кто увеличил покрытие автотестами, в каких-то итоговых отчетах в формате «какие мы все молодцы!». Это всегда приятно, когда твой труд оценен по достоинству. И традиционные обзоры от QA с результатами о покрытии автотестами — это тоже мотивация работать сообща.
Пусть изменения на проекте будут плавными. Если вы однажды утром придете на работу и заявите «я тут статью на Хабре прочитал, и начнете шлепать ботинком по условной трибуне, сотрясая воздух, мол, теперь я вам покажу Кузькину мать!», на вас посмотрят как на странного, это факт. Да и вам будет сложно — сталкиваясь с проблемами по всем фронтам — появится непреодолимое желание бросить всю затею по улучшению работы QA.
Лучше ставьте маленькие всем понятные задачи, достигайте их и беритесь за следующие. Аккуратно двигайтесь вперед, время летит быстро, однажды будет приятно обернуться назад.
Ответы на конкретные вопросы
После второй моей статьи, которая предлагала тесную работу QA и разработки, у аудитории обнажились настроения из разряда «мы пытались, но тим лид девелоперов не очень-то хотел идти на встречу». Со своего имеющегося уровня профессионального развития я могу советовать только следующее.
Будьте доброжелательны и относитесь с мудрым спокойствием к тем, кто не принимает вашу работу так, как вы того ожидаете. На своей практике я встречала много разных разработчиков и все те, которые были по-настоящему профессионально зрелыми, всегда шли мне навстречу, всегда помогали, и мы достигали прекрасных совместных результатов, ими все оставались довольны. Те, кто «фыркает» и «отмахивается от вас», увы, из категории «профессиональных тинейджеров». Они еще не научились совладать со своими чувствами, считая себя самыми правыми (и физический возраст тут не играет роли). Они попросту не умеют работать в команде, а вы — ее неотъемлемая часть. Вы как раз можете помочь им вырасти, но, к сожалению, некоторые не вырастают никогда. И тут можно только влиять на них через поддержку руководства и коллективный авторитет остальной части команды, которая вас поддержит. Если вы знаете лучшие способы, делитесь!
Еще там был интересный вопрос о том, как быть если ты просто еще не умеешь читать код разработчика, не можешь разобраться с их автотестами.
Я оставлю свой ответ и здесь, чтобы он не потерялся, быть может кому-то пригодится. Если прочитать не удается, я бы настаивала на включение в описание PR списка разработанных автотестов и ориентировалась на него. Я считаю, это полное право и обязанность команды QA максимально быть осведомленным о покрытии продукта автотестами, иначе вся идея Quality assurance теряется… Если мы рассматриваем ситуацию жесткой ограниченности во времени всей команды, в том числе и девелопера, то я бы в ходе ревью настаивала на покрытии интеграционными автотестами критически/стратегически важных сценариев. А на все остальные сценарии документировала отдельные таски, чтобы сделать их позже. В любом проекте бывают спокойные периоды, когда нет дедлайнов — тогда и стоит акцентировать внимание Product Manager/Team Lead/Scrum Master-ов на том, чтобы включать в работу эти таски: посложнее — пусть делают разработчики, на самых простых — учиться самому.
Заключение
Не могу сказать, что все то, что написано выше непременно вам поможет, все-таки, есть у меня такое чувство, что собственный профессиональный голос и стиль приходят с опытом и через набитые шишки. Нельзя взять и как через трафарет приложить чужой сценарий работы к своему проекту. Но если моя писанина побудила вас не мириться с моментами, которые вам не нравятся, и у вас в голове появились идеи, что вы можете сделать хорошего для себя, для команды, для продукта, значит я потратила время не зря. И да, не подумайте что я изображаю QA Акулу, которая все знает, все умеет. Я учусь и меняюсь постоянно. Прекрасно отдаю себе отчет в том, что через год мои принципы работы могут измениться. Всегда очень рада обратной связи и с удовольствием поучусь вашему опыту, пишите ;)
А если хочется что-то почитать для упрочнения собственной мотивации начните с двух замечательных книжек, отсылку к которым я давала в тексте:
1. Foundations of Software Testing: ISTQB Certification
by Dorothy Graham, Rex Black, Erik van Veenendaal, Isabel Evans
2. Как тестируют в Google
Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло
Всем спасибо за внимание!
