Здравствуйте. Меня зовут Илья Кудинов, мне 27 лет, и я тестировщик.
Все: Здравствуй, Илья!
Мы уже много писали о том, как здорово мы в Badoo тестируем наши продукты. А сегодня я (внезапно!) расскажу о том, как круто тестировать ВООБЩЕ. И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.
О чём она будет? Я поделюсь своим личным опытом, расскажу, как развивалась индустрия в течение шести с небольшим лет, что я за ней наблюдаю, и опишу своё видение карьерного пути тестировщика. Устраивайтесь поудобнее, настало время (неразборчиво, зачёркнуто) занимательных историй…
Дисклеймер
Всё, что я напишу в этой статье, основано на моём личном восприятии, опыте и информации, которую я почерпнул на QA-конференциях и митапах. Статья будет интересна начинающим специалистам и тем, кто мечтает работать в IT, но ещё не определился с профессией. И главным образом тем, кто считает, что тестирование — несерьёзная, скучная и рутинная работа.
Если вы со мной в чём-то не согласны — добро пожаловать в комментарии. Я всегда открыт к диалогу.
Про меня
Моя история как тестировщика началась в 2011 году. К этому времени я уже успешно бросил учёбу в МГТУ имени Н. Э. Баумана, побывал в армии и поработал
Всё начиналось очень скучно и обыденно. Я был единственным тестировщиком на семь программистов. Разработчики писали код на локальных машинах, скидывали его на тестовый сервер, просили меня его там потестировать, а потом вручную заливали код на продакшн (я наивно полагал, что все так делают). Что-то заливали на прод без моего ведома ( «Забыл сказать, извини!» ), что-то делали сразу на проде по требованию менеджмента. В общем, тихий ужас.
Спустя несколько недель я узнал про существование систем контроля версий. Мир перевернулся. Несколько людей могут работать над одним и тем же кодом, и это будет УДОБНО! Я прожужжал все уши начальнику и добился установки SVN. Всего через месяц после этого мы начали работать в ветках (!), заливать изменения на продакшн организованными протестированными пачками (!!) и даже заимели какое-то подобие расписания релизов (!!!). Когда я смотрел на это всё, у меня начало зарождаться ощущение, что разработка и тестирование — это не хаотичный процесс, у всего этого может быть какая-то организация. Почитать интернеты? Вы что, я был молод и горяч, мне было не до этого.Итак, помимо тестировщика, я стал ещё и релиз-инженером. Работа стала более интересной и менее топорной. Из-за снижения уровня хаоса у меня появилось больше свободного времени, и я стал интересоваться, что же это за зверь такой — «Автоматизированное тестирование». Нашёл в интернете информацию о только-только вышедшем Selenium WebDriver, и мои глаза снова полезли на лоб: можно заставить программу ТЫКАТЬ КНОПОЧКИ НА САЙТЕ ЗА ТЕБЯ??? Воображение рисовало идиллическую реальность, в которой человеку не нужно заниматься регрессионным тестированием (нет, этого термина в тот момент я не знал). И я тут же начал тратить всё свободное время на разработку тестов. Честно говоря, написаны они были ужасно, но свою функцию выполняли.
К тому времени я работал в компании уже девять месяцев. И всё ещё получал свою изначальную зарплату ручного тестировщика (поверьте, она была не очень впечатляющей). Безумно гордившийся мной начальник повёл меня к руководству — выбивать повышение. Я рассказал о переходе к релизной системе и своих обязанностях в этой области, показал свои автотесты, рассказал о том, как они сокращают время на рутинную работу. И продемонстрировал, что количество ошибок, попадающих на продакшн, за последние полгода упало драматически. Я уже практически не хотел быть программистом!
Но представитель менеджмента, скучающим взглядом окинув возделанные мною поля, сказал: «Да вроде бы и безо всей этой мишуры всё нормально было, зря только время тратили».Такого удара я не ожидал. Никакие цифры руководство не убедили, для него тестировщик был мартышкой, щёлкающей по кнопкам и за небольшую плату уменьшающей (иногда) количество фаталов на продакшне. Рассматривать что-то большее никто и не собирался. Можете считать это чрезмерной реакцией, но заявление на увольнение я написал тем же вечером.
Я начал снова искать работу. Разуверившись в тестировании, опять стал смотреть в сторону программирования. Даже успел получить оффер на позицию младшего С-разработчика в одной брокерской фирме… А потом мне позвонили из Badoo.
Про Badoo я впервые услышал буквально за несколько месяцев до этого — на мастер-классе Алексея Рыбака на DevConf 2012. Компания тогда моментально встала для меня в один ряд с Google и Facebook. Мне казалось, Badoo — это что-то невероятно крутое, куда я, простой смертный, никогда не попаду. Поэтому на собеседование я согласился исключительно ради опыта. Я ни на что не рассчитывал — просто излил Илье Агееву всю свою фрустрацию по поводу того, чего я хотел добиться и чего меня лишили. А через несколько дней я уже стал частью этой компании, которую, к слову, всем сердцем люблю по сей день.
«А как же твоё желание быть программистом?» — спросите вы. С ним всё в порядке. В Badoo я занимаюсь разработкой систем автоматизации тестирования и оптимизации рабочих процессов. А в свободное время потихоньку разрабатываю компьютерные игры. Это моё хобби, дело для души. Нет, идти работать программистом мне больше не хочется.
Про индустрию
В первые дни работы в Badoo я испытывал культурный шок. И дело вовсе не в катающихся по офису на самокатах и кричащих во всё горло разработчиках. Хорошо, не только в них. А ещё и в том, что здесь старались организовать, оптимизировать и автоматизировать каждый шаг. Я подумал: «Так вот как должно быть!» — и всеми силами старался соответствовать: участвовал в разработке процессов и средств тестирования, неустанно искал места, где можно что-то улучшить. А потом я начал ездить и рассказывать о наших решениях на конференциях. Боялся, что для всех всё будет очевидно — ведь все вокруг тестируют так же круто, как мы в Badoo! Но на деле…
Внушительная часть российских компаний, а особенно IT-департаменты крупных неайтишных компаний, видели процесс тестирования примерно так же, как мои предыдущие работодатели. Вопросы после докладов ставили меня в тупик.
«А как вы заставляете разработчиков писать тесты?»
«Как это, вы можете отложить релиз фичи? Вот прям достаточно баг найти?»
«Автотесты вы пишете сами? Если вы умеете программировать, почему вы не программист?»
Проблема была в первую очередь в восприятии профессии тестировщика в нашей стране. Стыдно сказать, я тогда даже не любил слово «тестировщик» — считал, что оно приближает меня к тому образу низкоквалифицированного работника, который представляют себе консервативные бизнесмены. Я предпочитал претенциозное «QA-инженер».
Я и мои коллеги год за годом старались донести одну и ту же мысль: тестировщик — это не wannabe-программист, тестировщик — это полноценная специальность. Она не проще программирования. Она не сложнее. Просто это совершенно другое занятие. Оно требует других навыков. Оно требует высокой квалификации. И опытный тестировщик — не менее ценный (и редкий) кадр, чем опытный разработчик. Путь тестировщика не заканчивается на бездумном клацании кнопок и следовании инструкциям — он с него только начинается.
И, к счастью, с каждым годом всё больше людей это понимало. Предпочитаю находить в этом и свой скромный вклад. Стало появляться всё больше вакансий для профессиональных тестировщиков и автоматизаторов, всё больше крутых специалистов, к мнению которых прислушивается вся отечественная (и заодно зарубежная) индустрия. И это прекрасно. Я чувствую, что отечественное тестирование в целом идёт примерно тем же путём, что и я в свои первые годы.
Про путь тестировщика
Карьера тестировщика — история развития технических, личностных и многих других навыков. Как и в любой другой профессии, да. Сразу хочу сказать: я не считаю движение от ручного тестировщика до автоматизатора путём развития. Навыки автоматизации важны и полезны любому тестировщику, но это лишь вариации должности, а не прямая эволюция. Итак, приступим.
Уровень 0. Не тестировщик. На этом уровне находится любой пользователь программного обеспечения. Казалось бы, если это не тестировщик, то зачем я его сюда добавил? А затем, что все эти люди могут выполнять часть работы тестировщика. Они могут находить баги. Не специально, они не старались, просто так вышло. Именно такого человека, на самом деле, и ожидали увидеть в должности тестировщика на моём первом месте работы. И любой специалист с этого начинает. Вот только у некоторых баги вызывают раздражение и злость на разработчиков, а у некоторых — праведный гнев и желание сделать так, чтобы в нашем мире багов больше не было. Из последних и рождаются начинающие тестеры.
Уровень 1. Почти тестировщик. Человек, которому доверили работу тестировщика и который пытается её выполнять. Не просто пользуется приложением, а настырно им пользуется. Иногда даже нажимает на одну и ту же кнопку несколько раз. Он всё ещё не обладает никакими навыками, в его действиях нет никакой системы — есть только желание найти баг. Либо чтобы не уволили с работы, либо из врождённой ненависти к несовершенствам — так сразу и не скажешь.
Уровень 2. Тестировщик. Понимает, что он делает. Может быть, прочитал пару книжек об основах тестирования. Берясь за каждую новую задачу, может построить план своих действий (либо прочитать документацию и следовать ей). Цель постепенно смещается от «найти какой-нибудь баг» к «контролировать качество продукта». Примерно на этом уровне я находился в свои лучшие дни на предыдущем месте работы.
Уровень 3. Продвинутый тестировщик. Действительно понимает, что он делает. Прекрасно знает проект и может проанализировать влияние на него тех или иных изменений. Может оценить, насколько тестируемый функционал соответствует остальному проекту не только в плане качества, но и в плане UX и прочих важных вещей. Может не только найти баги, но и предупредить возникновение ошибок в планировании и дизайне того или иного функционала. 
Уровень 4. Инициативный тестировщик. Он не просто работает в организованной среде и процессах — он старается их улучшить. Цель из «контроля качества» превращается в «обеспечение качества». Развитие и разработка средств оптимизации и автоматизации, бесконечные идеи об улучшении рабочего процесса — вся эта прелесть начинается где-то здесь.
Уровень 5. Профессиональный тестировщик. Бессовестно и беззастенчиво располагаю себя на этом уровне. Понимание используемых на проекте технологий позволяет принимать решения и разрабатывать план тестирования не только по описанию задачи, но и по её решению. Иногда для обнаружения ошибок прочтения кода и списка изменений бывает более чем достаточно. Тестировщик начинает видеть опутывающие проект связи, о которых он ранее и не подозревал.
Уровень 6. Гуру-тестировщик. Как вы можете заметить, квалификация предыдущих уровней сильно завязана на проект. Переходя в другую компанию, а тем более на другой стек технологий, обычный тестировщик теряет часть своего профессионализма. Её придётся восстанавливать. Гуру-тестировщики же смотрят на вещи с более высокой точки. Они могут в кратчайшие сроки разобраться с любой системой, найти как явные, так и скрытые связи между компонентами за счёт своего опыта и понимания работы IT-систем (и IT-специалистов). Волшебные люди. Вот бы мне так.
Но постойте же, это всё про самостоятельное тестирование! Разве тестировщик не имеет возможности за счёт своего развития стать руководителем? Конечно, имеет. Но это требует целого набора других качеств и навыков, которых у него может и не быть. Не каждый хороший тестировщик может стать хорошим тест-менеджером. Однако, я твёрдо уверен в том, что каждый хороший тест-менеджер обязан быть хорошим тестировщиком.
Про навыки хорошего тестировщика
«Наверное, достаточно прочитать десяток известных книг от именитых тестировщиков!» Не-а, вообще ни разу не согласен.
Профессиональная литература может помочь быстрее усвоить те уроки, которые тестировщик получает в первые месяцы своей карьеры. Но без настоящего опыта тестирования книжные знания практически бесполезны. Реальный мир сильно отличается от того идеального, который описывают в большинстве книг.
А вот те определяющие качества, которые вижу я:
- Любовь к тестированию. Да, к тестированию вообще. Не нужно считать тестирование побочным занятием в IT, не надо мечтать сбежать в разработку или руководство — надо в первую очередь получать удовольствие от работы. «Это относится вообще к любой специальности, спасибо, кэп!» — скажете вы и будете правы. Однако это не делает данный пункт менее значимым.
- Любовь к проекту. Вы не будете радеть за качество проекта, на который вам наплевать. Даже если вы будете исправно делать свою работу (деньги же надо как-то зарабатывать), вы будете закрывать глаза на замеченные вне своего компонента недостатки («Не моё дело, да и вообще проблема на вашей стороне»). Вы не будете предлагать улучшения и проявлять инициативу («Если полить г**но одеколоном, оно будет пахнуть как г**но под одеколоном!»).
- Знание проекта. Очень красивая кнопка! Прям как в ТЗ написано! И делает она всё, что от неё требуется, замечательная кнопка! Очень жаль, что она выглядит совсем не так, как все остальные кнопки на сайте, ломает шесть критических фич и вызывает Сатану в профиле пользователя. Но откуда мне было про это знать?!
- Понимание технологий проекта. Нет, не обязательно иметь возможность самостоятельно переписать весь проект с нуля, только лучше. Но хотя бы в общих чертах понимать, КАК работает то, что ты тестируешь, просто необходимо. Это позволяет находить неочевидные баги, делать подмены кода для воспроизведения тех или иных кейсов и видеть дополнительные зависимости внутри проекта.
- Соблюдение баланса между качеством и скоростью. Качество не бывает абсолютным. Каждая единица времени, которую тестировщик проводит за задачей, теоретически приближает её качество к асимптоте в 100%. В какой момент нужно остановиться? Всё зависит от проекта. Если на вашем софте будут летать самолёты с сотнями пассажиров, не стоит жалеть на тестирование ещё час-другой. А если вы разрабатываете проект с несколькими релизами в неделю и возможностью доставлять патчи пользователям за секунды, можно остановиться и раньше. Нет, я не поощряю выпуск багов на продакшн — просто скорость развития проекта иногда бывает важнее. Можно прочитать это качество как «Умение ориентироваться в приоритетах бизнеса».
Совсем же не необходимыми я вижу следующие часто приписываемые тестировщикам качества:
- Перфекционизм. Ненавидеть баги и несоответствия — это хорошо. Зацикливаться на этом — плохо. Будет страдать скорость тестирования, а требования менеджера выпустить недотестированный функционал будут вгонять в депрессию. Тестировщики софта для самолётов, не слушайте меня, будьте перфекционистами! Пожалуйста.
- Любовь к бюрократии. Ах, тестовая документация. О ней уже столько рассказано и написано, я и сам рано или поздно доберусь до этой темы. Сейчас же ограничусь тем, что скажу, что эффективное тестирование бывает и без подробной всеобъемлющей тестовой документации при условии наличия толковой технической документации. Честное слово!
- Радость от нахождения бага. Нет, хвалить себя за хитровыдуманный кейс, который сломал систему, — это нормально. Любить себя тоже надо. Но это не самоцель — не нужно надеяться на ошибку в каждой попавшейся задаче, не нужно глумиться над разработчиками, которые пропустили баг, и чувствовать своё превосходство, когда вы нашли неточность в компоненте, уже проверенном вашим коллегой. Гораздо лучше радоваться тому, что задача уехала на продакшн без ошибок и в срок. Вот это — ваше настоящее достижение, даже если вы ни разу не переоткрывали задачу.
И в заключение…
Я люблю свою работу. Это включает в себя всё — и мои собственные обязанности, и проект, и моих дражайших коллег. Я знаю множество тестировщиков, которые испытывают те же чувства. Но знаю и много других, которые на своей позиции несчастны, по своей ли вине, или по вине руководства — неважно. А ещё знаю людей, которые хотят работать в IT, но не хотят идти в тестирование, потому что считают эту работу недостойной и неинтересной. Если хотя бы один из этих людей благодаря моей статье сможет стать счастливее и успешнее в собственных глазах, я всё это писал не зря. Комментарии (49)
AnthonyBY
25.12.2017 18:49+3Хороший тестировщик на проекте на вес золота. Поэтому приятно слышать что это к кому в удовольствие. Но как отметили выше, не совсем понятно куда расти.
У меня была почти такая же ситуация как у вас, 9 лет назад выбирал между junior developer и senior automaiton dev. Деньги перевесили и пошёл в «сеньёры», но в long term пожалел, ибо стеклянный потолок очень близок, перешёл в iOS dev и ни разу не пожалел (первый год конечно очень тяжело было).
Плюсы:
— очень много вакансий
— твоя работа не так завязана на команду
— результаты твоей работы видят все
— радость от того когда стартуешь проекты с нуля
Из QA получаются отличные PM, DevOps и т.д., но всё же в разработке гораздо комфортней. С такой хорошей технической базой можно ещё два раза карьеру поменять. Удачи
Relz Автор
25.12.2017 19:00-1Технически да — в данный момент я уже упёрся в потолок развития для чисто технического специалиста. Поэтому сейчас стал больше заниматься отвлечёнными делами — продуктовыми проектами, геймдевом, деврелом.
Да, для следующего шага рано или поздно придётся менять сферу деятельности (и, возможно, компанию), но это путешествие было интересным и я ни о чём не жалею (:
pierrevanstulov
26.12.2017 18:38+1Ну вооот :( Так Вы красиво все расписали, сколько перспектив открывается перед специалистом по QA, каким он может стать важным человеком. Типа: «ребята, все за мной, тут круто!» И на тебе:
Да, для следующего шага рано или поздно придётся менять сферу деятельности (и, возможно, компанию), но это путешествие было интересным и я ни о чём не жалею (:
Начали за здравие, а кончали за упокой.Relz Автор
26.12.2017 18:45Я уже поплакал из-за того как плохо построил этот комментарий. Надо было его сначала раз 10 перечитать, скорее всего решил бы ничего не писать :-D
У QA (как, впрочем, и у рядового разработчика) есть однозначный технический потолок, пробить который достаточно сложно. Можно уйти в тим-лиды, можно углубиться в смежные области (например, аналитику и безопасность), а без этого профессиональный рост (и рост заработной платы) начинают сильно замедлятся. Именно про такие шаги я и писал (:
alicepepel
25.12.2017 19:22как же приятно всегда почитать такие заметки от людей, которые простолюбят свое дело. без претензий, без обидок на бывшее начальство/коллег и без «мерянья незаменимостью» с другими спецами, которое обычно неуместно. автору спасибо.
sayber
25.12.2017 21:04+1Без тестировщиков я работать в проектах отказываюсь сразу.
Причем нужны как минимум два уровня. Те кто тестируют интерфейсы и т.п., и те кто пишут тест-кейсы.24twelve
26.12.2017 03:56А это интересно! Можете раскрыть, чего такого вы ждете от тестировщиков, что не хотите работать без них?
YaRobot
26.12.2017 04:22Может я помогу =)
Представьте финансовую или туристическую систему, с сотнями форм, бланков и т.п.
Большие алгоритмические процессы при проводках, заказах и т.п.
Представили? Отлично.
Допустим реализовали новый функционал по определенной юзерстори и ТЗ соответственно.
Написали тесты, все вроде работает. Однако мы все знаем, что зачастую разработчики имеют так называемый «замылиный взгляд». Так же, мы точно знаем, что пользователи обязательно что то сделают, чего не должно было произойти. Где то возможны не верные алгоритмические решения и все в подобном духе.
Как же избежать подобной ситуации? Конечно — стать богом. Но к сожалению, это маловероятно.
И тут на сцену выходит команда тестировщиков. Кто то пишет подробные тест кейсы и различные вариации, кто то все это тестирует.
Понятно, что имеются и автоматизированные тесты.
Из моей 16 летней (сейчас будет уже 17 лет) практики разработки различных крупных продуктов, могу сказать — без тестировщиков, продукт будет постоянно иметь баги, недоработки и различные мелкие косяки.
Не хорошо, когда бизнес из-за этого начинает пробуксовывать а еще хуже, когда клиенты натыкаются на подобные вещи.
Как это работает у нас.
В беклог заводятся различные юзерстори, разработчики делают декомпозицию задач и т.д. Начинает кипеть работа. Есть подготовленные юзер-кейсы от тестировщиков.
Готовые решения складываются в ветки историй. Далее «готовые» истории отправляются к мистеру дженкинсу и собираются в дев. средах. Там производятся различные автоматизированные тесты. Как на интерфейсе так и на бекенде.
Если все ок, и все тесты прошли, собирается полностью готовый вариант на отдельном физическом сервере. Там в работу вступают тестировщики.
Если они находят проблему, соответственно она появляется на доске.
Выставляются приоритеты и далее по накатанной фиксятся/дорабатываются/переделываются. После все по кругу.
В конечном счете, каждая история проходит максимальное количество тестов и вариаций.
Что сводит к миниму проблем.
Тогда тестовому серверу дают зеленый свет и данная сворка мержится в препрод. По сути прод., но с специально репликой. Где внешние клиенты (к примеру триваго или booking.com), не могут оперировать данными, только менеджеры (коих 700 человек).
После мерджа в препрод всех проверенных историй и нормальной отработки, идет деплой в прод., примерно раз в неделю.
Надеюсь я ответил на ваш вопрос подробно, в 4 часа ночи =)24twelve
26.12.2017 04:56Спасибо вам за подробный комментарий в 4 часа ночи. В такие моменты чувствуешь себя не одиноким =)
То есть вы разрабатываете, а от тестировщиков ждете, что они зарепортят баги и проблемы, которые вам отловить не удалось. Я сам тестировщик и считаю, что это хороший, понятный контракт.
Но есть наблюдение:
Итоговый продукт сильно зависит от процесса разработки. Разработчик завален задачами и делает код-ревью спустя рукава? Аналитику по задаче писал стажер, а опытный аналитик её не посмотрел? Это обязательно породит баги =)
Из этого следует забавный факт (видел такое не раз): чем больше багов в обновлении нашел тестировщик, тем больше он их найдет в дальнейшем. Потому что много багов означают, что в процессе разработки что-то сломалось и лучше уже не будет.
Вы описали многоступенчатый процесс тестирования и обкатки обновлений. Если разработчики, аналитики и другие люди выше по течению будут отдавать недоделанные задачи, то такой процесс не будет сходиться — релизы будут тестироваться месяцами и релизиться не «когда мы пофиксили все баги», а «когда дедлайн» или «когда пришел менеджер и сказал что хватит это тестировать».
В двух словах — я не согласен, когда разработчики и аналитики делают что-то в расчете на то, что «тестировщики все равно все баги найдут». Это плохо заканчивается.1001001
26.12.2017 09:50Еще хуже, когда разработчики пишут в надежде, что баг не будет найден. (отдают заведомо кривой код)
YaRobot
26.12.2017 11:14+1Для код-ревью есть отдельный человек.
Релизы делаются раз в неделю, на прод. попадает вариант, без ошибок в 90-94% случаев.
Я не говорил о аналитике, хотя и такой человек присутствовал, не давно расстались.
Делается не в расчете, что тестироващик найдет обязательно баг. Система так не работает. Каждый баг (именно статус бага в жире), это минус команде. Каждый срыв срока, это тоже минус и т.д.
Естественно, минусы влияют на конечный финансовый результат премии, а если совсем плохо, то и на менеджмент.
По этому вы далеко не правы, что разработчик ждет спасательного круга от отдела тестирования. Скорее он ждет, что данная история уже не вернется к нему в руки.
И обычно так оно и есть.
Но как я сказал, без отдела тестирования, проект легко может забуксовать и то и вовсе, понести серьезные финансовые потери.Relz Автор
26.12.2017 11:17К сожалению, программисты-новички так тестировщиков и видят. Спасательный круг, который их выручит от пендюлей руководства.
И уже от руководства зависит, будет ли меняться такое отношение. Если во всех багах винят только тестировщиков — программисты будут становиться всё расслабленнее и проект рано или поздно увязнет. Если ответственность распределяется поровну (или в некоторых случаях даже преимущественно на разработчика), то и сами разработчики начинают меньше уповать на тестирование вместо самих себя.YaRobot
26.12.2017 11:21Я такой вариант не исключаю и видел подобное лет 6 назад.
В данном случае, говорю о текущих проектах.
Извиняюсь перед всеми, забыл упомянуть — мы все (команды разработчиков), работаем удаленно.
Germanets
26.12.2017 10:59+1Те кто тестируют интерфейсы и т.п., и те кто пишут тест-кейсы.
— как по-вашему, эти самые два уровня может занимать один тестировщик, или нет?YaRobot
26.12.2017 11:17Без понятия. Если специалист может продумать кейсы и проработать их, то почему нет.
Ведь в сфере разработки часто встречаются full-stack. Но именно по моему мнению, каждый должен заниматься своим делом.Relz Автор
26.12.2017 11:22Тестировщик, слепо следующий написанным кем-то другим кейсам — это самое начало карьеры тестировщика. Как программист, который переводит написанный кем-то другим алгоритм в код. Такие практики имеют право на существование, но кажутся мне менее эффективными (хоть и потенциально более надёжными), чем программисты, сами разрабатывающие свою систему и тестировщики, сами прорабатывающий план тестирования компонента.
YaRobot
26.12.2017 11:24Я не могу вам ответить на данный вопрос. Хоть мы и связанны с командой тестирования, но не углублялся в их внутреннюю кухню.
Relz Автор
26.12.2017 11:26Никогда ещё не работал в физически распределённой команде, у нас разработка и тестирование работают совместно всегда. Очень интересно узнать, как что работает при вашей схеме :)
YaRobot
26.12.2017 11:41Да все просто =)
Есть доска, на ней всегда видно что происходит. Подробное описание и тест-кейс присутствует. Если что то не понятно, всегда можно обсудить голосом.
Удаленный процесс — выглядит примерно так:
Митинги по утрам.
Общение в основном Slack или если того требует ситуация, то голосом.
По пятницам ретроспектива.
По понедельникам, общение с бизнесом (что бы знать бизнес а не тупо писать код).
В остальном уже технические моменты, типа git, jira/tsf, jenkins и т.п.
Т.к. команды международные а не только Россия и СНГ, то с некоторыми участниками, в живую не знаком. Хотя сам в офисе, бываю довольно часто.
Все остальное время — пишем код =)
В основном с 12ч. до 19ч. по МСК.
Ndochp
26.12.2017 15:49То, что свой код проверять нельзя это ясно, но если кодить спарками аналитик-разработчик, на описании задачи и тестировании аналитик, разработчик понятно чем занимается.
Насколько по вашему это нежизнеспособная ситуация?
Регресс тесты автоматические, пишет команда под архитектором, который как раз становится чуть свободнее к середине проекта, когда появляется необходимость в регрессе.Relz Автор
26.12.2017 16:07Мы в Badoo примерно так и разрабатываем. Разработчик берёт задачу из пула, если задача с ходу не ясна — к нему присоединяется QA-инженер (если всё понятно сразу — QA подключается уже после первого resolve) и дальше они работают над задачей сообща, включая все возможные циклы reopen'ов.
Непосредственно над каждой задачей архитектора нет, но есть код-ревью, во время которого сообща решаются любые архитектурные вопросы.Ndochp
26.12.2017 16:48Отвечаю сразу Вам и @ nizkopal
Я в 1С проектах живу. К счастью, пока XXS слегка не про нас. Соотвественно, аналитик добывает задачу из ключевого пользователя заказчика, и ему же сдаёт. Бизнес-аналитик + QA в одном флаконе.
А архитектор один на проект, типа самый опытный разработчик, в начале именно архитектор, к середине — концу проекта смещается в релиз инженера, главного код ревьювера.
Вот что меня беспокоит в Бизнес-аналитик = QA это же тоже в некотором роде тестирование «собственного кода».
nizkopal
26.12.2017 16:57+1Суть не в XSS, а в том, что взгляд аналитика и тестировщика на результат работы разработчика будет разным. Аналитик видит воплащенное ТЗ, где надо проверить все пункты из ТЗ в действии и на этом все.
А вот QA будет видеть продукт, который может быть использован конечным пользователем как угодно. Он будет пытаться предсказать поведение конечного пользователя и проверить те места, где что-то может пойти не так. Включая использование продукта не по назначению.
Так что не удивительно, что интуитивно Вас смущает объединение этих двух ролей.
nizkopal
26.12.2017 16:12Ставлю сотку — такой аналитик будет тестировать только позитивные кейзы. Слабо представляю себе ситуацию, где аналитик получает задачу от ПМ: сделать поле ввода, в которое можно ввести текст и он отобразится в таком-то блоке — и аналитик после реализации задачи начинает тестировать это поле на XXS, например. Зачем? Ему задачу «сдать» надо поскорее и приступить к реализации следующей.
Skaild
26.12.2017 09:50— И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.
— Всё, что я напишу в этой статье, основано на моём личном восприятии
Вас не бьют еще? Нет, я сам тестировщик, я практически полностью согласен с тезисами статьи, но, признаться, кое-как заставил себя читать дальше после такого вступления.Relz Автор
26.12.2017 09:51Проснулся вроде целый. Пишу слишком пафосно? У меня такое бывает, а снобом меня называли уже в младшей школе. Так что извините, если что (:
RINSPEED85
26.12.2017 10:03напишите список книг, которые must read, для тестировщика?
Relz Автор
26.12.2017 10:09Я вот совсем пропустил этот этап обучения, всё познавал уже на собственных шишках)
Но по отзывам могу порекомендовать три книжки:
Скучную, но дельную «Testing computer software» от Cem Kaner и Jack L. Falk
Более читаемую, но менее интересную для опытного специалиста «Software Testing» от Ron Patton
Отличное пособие по тест-дизайну «A Practitioner’s Guide to Software Test Design» от Lee Copeland
Ну и что-нибудь вроде «Как тестируют в Google» чтобы узнать о реальных практиках. Ну или почитать другие наши статьи о тестировании (:
evgeniykhafizov
26.12.2017 11:12Я бы даже назвал — «Все профессии важны: почему хорошего тестировщика нужно ценить больше чем программиста»
Relz Автор
26.12.2017 11:13Давайте не будем вдаваться в споры о том, какая специальность важнее) Любой толковый специалист на своём месте — человек очень важный и ценный.
alix_ginger
26.12.2017 12:42+1«почему хорошего тестировщика нужно ценить больше чем среднего программиста»
Wolonter
26.12.2017 20:10+1Я прожужжал все уши начальнику и добился установки SVN.
Если я не ошибся в подсчетах, шел 2010 год? Тогда вы правильно сделали что
заявление на увольнение я написал тем же вечером.
Путь тестировщика не заканчивается на бездумном клацании кнопок и следовании инструкциям — он с него только начинается. <...> Предпочитаю находить в этом и свой скромный вклад.
Вклад определенно есть. С удовольствием советую всем доклады от badoo и смело иду на них на любых конференциях.
Про путь тестировщика
Шикарный список уровней. В свое время предложил такой:
- Тестер. Ищет баги
- QA. Не наносит вред. Уменьшает количество багов в проекте.
- Гуру. Учит команду писать меньше багов.
- Евангелист. Все, кто с ним общаются создают меньше багов.
- Пророк. Меньше багов создают даже те, кто с ним не общаются.
Любовь к тестированию
Справедливо стоит на первом месте. Илья, большое спасибо за статью.
функционал
Функциональность.nizkopal
27.12.2017 12:46+1Из Ваших уровней получается, что когда тестировщик достигает 5ого уровня, его можно смело увольнять. Ведь он будет приносить пользу даже не будучи работником (ведь с ним можно даже не общаться). Это — отличная экономия. :D
Terras
27.12.2017 13:26+1В свое время после работы в технической поддержки мне предложили в компании повышение, и дали денег, как уровня middle developer, чему я был безумно рад. Ответственность лежала на уровне:
1) Ведение продуктовых задач в тройках: pm + dev + qa
2) Написание тест-кейсов, тест-ранов, беклока для регресса
3) Приготовление конфигураций для релиза
4) Введение документации по задачам
5) Проверка проблем поступающих от первой линии поддержки, передачи готовых задач девелоперам
6) Поддержка качества продукции, на уровне «делаем адекватно», без херни и «потом допилим».
Из стека было:
Python/java — написание тестов, конфигурация сред, поддержка портала тестирования, портала qa и так далее (т.е. там и тесты, и девопсы инструменты и Django + Spring)
Php/JavaScript — понимания кода, когда не было возможности нативно проверить задачу, и приходилось чекать код разработчика на соответствие требованиям.
Понимание Windows/linux(Debian)/macOS/Android/IOS, всяких virtualbox и прочее
Jira/YouTrack/SEZ(собственная система)
Всякие почтовые программы очередей типа Реббита, Селери и прочеее.
Знание Английского, русского языка — умение читать и разговаривать. Португальский, Испанский — базовое понимание, чтобы чекать сквозные таски.
Из приятного, были полномочия полностью стопнуть задачу и объяснить ПМ и разработчикам, что вы делаете херню, я эту задачу в таком виде не пропущу.
P.s. Обидно, что обычно QA воспринимаются манки-кликарами.
sand14
29.12.2017 13:11+2Если говорить об Automation QA, то это тот же разработчик, с тем же необходимым бекграундом, включающим с актуальные стеки технологий, фундаментальные/академические знания, понимание этапов жизненного цикла ПО и т.д., но чуть с другим фокусом в работе.
Однако, если говорить по теме статьи, то мои наблюдения рынка вакансий и коллег показывают, что QA _уже_ ценятся больше больше, чем разработчики.
И это неудивительно, учитывая сдвиг разработки в сторону составления кейсов и их проверки (есть и множество других факторов).
При этом есть ощущение, что и QA-вакансий заметно больше, и порог входа заметно ниже, в том числе для Automation QA.
Да, пока разработчики в абсолютных цифрах получают/зарабатывают больше, судя по рынку, раза в полтора.
Но в пересчете на объемы работ и требуемых знаний и скиллов ситуация сильно не в пользу разработчиков.
SirEdvin
Вот я общался на эту тему с своим коллегой, он так и не смог ответить на вопрос "Куда расти мануальному QA именно в рамках профессии, а не доменной области". То есть, что там такого сложно, что можно за 2 года практики не освоить?
Или у вас для QA автоматизация обязательна?
eloin
Хороший мануальщик должен уметь программировать, чтобы понимать, что вообще реализовано в задаче. Есть достаточно много хороших программистов, умеющих создавать код, но мало хороших программистов, умеющих его тестировать (читай, иметь нужный для этого склад ума).
Соответственно, осваивать надо языки программирования и технологии, используемые в компании, в которой работаешь.
azShoo
Давайте начнем издалека:
QA — это не только тестирование. А автоматизация тестирования — это всего лишь инструмент, а не отдельный «вид» или специальность.
Чем больше опыта я набираюсь в качестве QA-инженера — тем больше простора для развития вижу. Хотя, вынужден признать, после определенной планки количество «интересных» вакансий начинает стремительно падать.
Но всё таки. Список компетенций, которыми приходится обладать QA инженеру (в широком, т.е. правильном, смысле этого термина) — предельно широкий.
Ты должен обладать достаточной компетенцией в разработке — тебе необходимо понимать, как будет работать код, который пишут твои коллеги. Видеть все возможные bottleneck`и и потенциальные проблемы, а в определенный момент — не только увидеть их, но и суметь донести это видение проблемы до коллег и, возможно, предложить альтернативные варианты.
Ты должен обладать хорошими навыками аналитика и менеджера, что бы работать с требованиями, избегать создания defective by design продуктов, иметь возможность увидеть и оценить максимум из возможных сценариев использования.
Ты должен уметь работать с данными: не только анализировать те данные, что есть, но и формировать пул требований по метрикам, логированию и аналитике, необходимой тебе для обеспечения качества продукта.
Ты должен разбираться в инфраструктурных моментах, ведь недостаточно обеспечить корректное выполнение кода в вакууме. Приложение должно работать корректно (а формирование критериев корректности — это отдельная история) в продакшен окружении.
И тебе нужно понимать, как создать адекватное тестовое окружение и каким оно должно быть, что бы это было production-like. Тебе нужно понимание того, как это сделать (что бы если уж не настроить самому, то иметь возможность сформировать требования коллегам).
Ко всему этому необходимо понимание бизнес-специфики приложения, с которым вы работаете. Просто потому, что критерии качества, которые вы должны формировать и которым должен соответствовать продукт, неразрывно связаны с бизнесом. Нет золотого стандарта «high quality product», подходящего для всех приложений. Где-то важна высокая отказоустойчивость и минимум багов. Где-то важна возможность безболезненно откатиться, но опробовать фичу. Где-то вы можете допустить 300 UI багов, главное что бы логика работала, а где-то цена одной уехавшей кнопки слишком высока.
Для каждого продукта процесс «калибровки» качества разработки будет разным. И ожидаемый результат — тоже.
В конце концов, это большое количество soft-skills, потому что обеспечение качества продукта — это прежде всего про процессы и работу с людьми. Придется «продавать» свое видение решений членам команды и руководству. Придется «продавливать» использование нужных инструментов.
В целом, да, я думаю что любой опытный QA инженер должен иметь навыки автоматизации.
Это не значит, что он должен ей сконцентрироваться на написании автотестов. Это значит, что он должен понимать когда и в каком виде стоит применять это решение. Какой профит от этого будет и каких трудозатрат это потребует.
С другой стороны я, например, категорически не понимаю Test Automation Engineer, т.е. ребят, которым спускают список кейсов на автоматизацию, а они выдают код. На мой взгляд, это категорически неэффективная схема.
Но это всё тема для холиваров.
bbidox
SirEdvin
Это кросс-доменная область, как мне кажется. Или я не прав?
Это вроде кросс-доменная область, как мне кажется. Или я не прав? Потому что для такого вполне нужен отдельный специалист.
Разве таким не должен заниматся QA team lead?
Возможно, я прошу странно, но вот, например, программисту понятно куда расти. Изучать как и общее программирование, так и инструменты, которые используются в языке + учить новые языки. А manual QA нужно уходить в кросс-доменную область?
Relz Автор
Если считать обязанностью тестировщика только прокликать все возможные кейсы в чёрном ящике — да, тут конечно расти дальше следования инструкциям некуда. Точно так же как до сих пор кое-где есть программисты, которые занимаются только переводом написанного другим человеком алгоритма в код. Там тоже нет особого пути развития.
В большинстве же случаев сейчас «программист» — не машина для выдачи кода, он занимается такими «кросс-доменными» делами как проектирование, алгоритмизация, оптимизация, поиск новых способов решения задач… То же самое и с тестировщиками. Кликать кнопки — самый базовый уровень, начало карьеры. Хороший тестировщик должен уметь намного больше. Немного автоматизации, немного UX, немного аналитики и оптимизации архитектуры…
nizkopal
Построение безопасной архитектуры — это зона разработки и администрирования. Проверка безопасности — это зона QA.
Ну и так далее на все предыдущие вопросы. Что бы не делал разработчик, это требует той или иной перепроверки (ибо все мы люди и все мы можем ошибиться или о чем-то не подумать). Чем сложнее манипуляция, тем больше знаний требуется от QA для адекватного тестирования данной манипуляции.
Средний QA знает каждую из областей разработки не так глубоко, как сам разработчик. Но зато он знает о большем количестве областей в целом, потому что сталкивается с их тестированием. Тут Вам и фронт, и бэк, и знание баз данных, и нагрузочное тестирование, и тестирование безопасности, и все виды негативного тестирования и так далее…
Развиваться тестировщик должен в сторону понимания устройства каждой из деталек продукта и способов адекватного тестирования онных.
Адекватный способ тестирования в данном контексте — максимально эффективный по времени и перформансу (читай — как можно быстрее убедиться, что продукт реализован как надо или доказать обратное). Это, пожалуй, самый спороный и сложный вопрос в тестировании. Оказывается, просто кликать по сайту (то, что Вы, видимо, называете мануальным тестировщиком) — чаще всего не самый адекватный способ проверять приложение. Это только первый уровень, Илья писал об этом.
bbidox
Документация по проекту — да, а документация по тому, как тестировать проект — нет. Часто ооочень многими недооценивается факт того, что не весь функционал в проекте тестируется в один клик. И как быстро объяснить кому-то что и как можно протестировать? А новому сотруднику? А если вы сами забыли? А если документации на проекте в принципе нет (читайте — стартап)? Это забота QA создавать подобные заметки, которые потом перерастут в документацию.
Визуализация и организация данных, которые в виде графов выглядят лучше, чем в текстовом. Так же, как и везде :)
И да, и нет. Если у вас есть поле description, как вы там опишете какую-то багу? Когда 15 человек на проекте заводят баги с текстом вида "кнопка не работает" — у вас голова опухнет ходить к каждому и спрашивать: "так какая кнока не работает? и КАК она не работает? по enter? по click?" Запись видео, скриншотов, гифок в разных средах, браузерах и операционных системах. Если работаете с вебом, то BugReplay и т.п.
Сделаю круглые глаза. Абсолютно нужна. Как минимум надо знать git и mercurial хотя бы на базовом уровне. Да вы самому себе упростите жизнь, если научитесь ими пользоваться.
Вас же по голове никто не бьёт развиваться в "кросс-доменной" области? То, что вы можете найти не только XSS, но и что-то посерьёзнее (и, более того, знаете как это быстро и эффективно искать) — очень даже большая польза.
А если вы не веб тестируете, а андроид? а iOS? ууу… поле непаханное.
А если вы единственный человек на проекте? Manual QA может вполне вырасти до QA team lead. Вам не надо уметь писать код для этого, поверьте.
QA — в принципе кросс-доменная область. Там есть тестирование, обеспечение качества, контроль качества. Если хотите остаться только в тестировании — развивайте навыки и обогащайте знаяния в инструментарии. Знайте слабые и сильные стороны различных браузеров. Тестируете андроид? Какие устройства идут без установленного google play market, а ваше приложение должно бы работать в этой стране? и так далее, и тому подобное.
Грамотный тестировщик — специалист миллиона навыков.