Comments 53
тестировщик — это полноценная специальность.
Вот я общался на эту тему с своим коллегой, он так и не смог ответить на вопрос "Куда расти мануальному QA именно в рамках профессии, а не доменной области". То есть, что там такого сложно, что можно за 2 года практики не освоить?
Или у вас для QA автоматизация обязательна?
Хороший мануальщик должен уметь программировать, чтобы понимать, что вообще реализовано в задаче. Есть достаточно много хороших программистов, умеющих создавать код, но мало хороших программистов, умеющих его тестировать (читай, иметь нужный для этого склад ума).
Соответственно, осваивать надо языки программирования и технологии, используемые в компании, в которой работаешь.
Соответственно, осваивать надо языки программирования и технологии, используемые в компании, в которой работаешь.
Давайте начнем издалека:
QA — это не только тестирование. А автоматизация тестирования — это всего лишь инструмент, а не отдельный «вид» или специальность.
Чем больше опыта я набираюсь в качестве QA-инженера — тем больше простора для развития вижу. Хотя, вынужден признать, после определенной планки количество «интересных» вакансий начинает стремительно падать.
Но всё таки. Список компетенций, которыми приходится обладать QA инженеру (в широком, т.е. правильном, смысле этого термина) — предельно широкий.
Ты должен обладать достаточной компетенцией в разработке — тебе необходимо понимать, как будет работать код, который пишут твои коллеги. Видеть все возможные bottleneck`и и потенциальные проблемы, а в определенный момент — не только увидеть их, но и суметь донести это видение проблемы до коллег и, возможно, предложить альтернативные варианты.
Ты должен обладать хорошими навыками аналитика и менеджера, что бы работать с требованиями, избегать создания defective by design продуктов, иметь возможность увидеть и оценить максимум из возможных сценариев использования.
Ты должен уметь работать с данными: не только анализировать те данные, что есть, но и формировать пул требований по метрикам, логированию и аналитике, необходимой тебе для обеспечения качества продукта.
Ты должен разбираться в инфраструктурных моментах, ведь недостаточно обеспечить корректное выполнение кода в вакууме. Приложение должно работать корректно (а формирование критериев корректности — это отдельная история) в продакшен окружении.
И тебе нужно понимать, как создать адекватное тестовое окружение и каким оно должно быть, что бы это было production-like. Тебе нужно понимание того, как это сделать (что бы если уж не настроить самому, то иметь возможность сформировать требования коллегам).
Ко всему этому необходимо понимание бизнес-специфики приложения, с которым вы работаете. Просто потому, что критерии качества, которые вы должны формировать и которым должен соответствовать продукт, неразрывно связаны с бизнесом. Нет золотого стандарта «high quality product», подходящего для всех приложений. Где-то важна высокая отказоустойчивость и минимум багов. Где-то важна возможность безболезненно откатиться, но опробовать фичу. Где-то вы можете допустить 300 UI багов, главное что бы логика работала, а где-то цена одной уехавшей кнопки слишком высока.
Для каждого продукта процесс «калибровки» качества разработки будет разным. И ожидаемый результат — тоже.
В конце концов, это большое количество soft-skills, потому что обеспечение качества продукта — это прежде всего про процессы и работу с людьми. Придется «продавать» свое видение решений членам команды и руководству. Придется «продавливать» использование нужных инструментов.
В целом, да, я думаю что любой опытный QA инженер должен иметь навыки автоматизации.
Это не значит, что он должен ей сконцентрироваться на написании автотестов. Это значит, что он должен понимать когда и в каком виде стоит применять это решение. Какой профит от этого будет и каких трудозатрат это потребует.
С другой стороны я, например, категорически не понимаю Test Automation Engineer, т.е. ребят, которым спускают список кейсов на автоматизацию, а они выдают код. На мой взгляд, это категорически неэффективная схема.
Но это всё тема для холиваров.
QA — это не только тестирование. А автоматизация тестирования — это всего лишь инструмент, а не отдельный «вид» или специальность.
Чем больше опыта я набираюсь в качестве QA-инженера — тем больше простора для развития вижу. Хотя, вынужден признать, после определенной планки количество «интересных» вакансий начинает стремительно падать.
Но всё таки. Список компетенций, которыми приходится обладать QA инженеру (в широком, т.е. правильном, смысле этого термина) — предельно широкий.
Ты должен обладать достаточной компетенцией в разработке — тебе необходимо понимать, как будет работать код, который пишут твои коллеги. Видеть все возможные bottleneck`и и потенциальные проблемы, а в определенный момент — не только увидеть их, но и суметь донести это видение проблемы до коллег и, возможно, предложить альтернативные варианты.
Ты должен обладать хорошими навыками аналитика и менеджера, что бы работать с требованиями, избегать создания defective by design продуктов, иметь возможность увидеть и оценить максимум из возможных сценариев использования.
Ты должен уметь работать с данными: не только анализировать те данные, что есть, но и формировать пул требований по метрикам, логированию и аналитике, необходимой тебе для обеспечения качества продукта.
Ты должен разбираться в инфраструктурных моментах, ведь недостаточно обеспечить корректное выполнение кода в вакууме. Приложение должно работать корректно (а формирование критериев корректности — это отдельная история) в продакшен окружении.
И тебе нужно понимать, как создать адекватное тестовое окружение и каким оно должно быть, что бы это было production-like. Тебе нужно понимание того, как это сделать (что бы если уж не настроить самому, то иметь возможность сформировать требования коллегам).
Ко всему этому необходимо понимание бизнес-специфики приложения, с которым вы работаете. Просто потому, что критерии качества, которые вы должны формировать и которым должен соответствовать продукт, неразрывно связаны с бизнесом. Нет золотого стандарта «high quality product», подходящего для всех приложений. Где-то важна высокая отказоустойчивость и минимум багов. Где-то важна возможность безболезненно откатиться, но опробовать фичу. Где-то вы можете допустить 300 UI багов, главное что бы логика работала, а где-то цена одной уехавшей кнопки слишком высока.
Для каждого продукта процесс «калибровки» качества разработки будет разным. И ожидаемый результат — тоже.
В конце концов, это большое количество soft-skills, потому что обеспечение качества продукта — это прежде всего про процессы и работу с людьми. Придется «продавать» свое видение решений членам команды и руководству. Придется «продавливать» использование нужных инструментов.
В целом, да, я думаю что любой опытный QA инженер должен иметь навыки автоматизации.
Это не значит, что он должен ей сконцентрироваться на написании автотестов. Это значит, что он должен понимать когда и в каком виде стоит применять это решение. Какой профит от этого будет и каких трудозатрат это потребует.
С другой стороны я, например, категорически не понимаю Test Automation Engineer, т.е. ребят, которым спускают список кейсов на автоматизацию, а они выдают код. На мой взгляд, это категорически неэффективная схема.
Но это всё тема для холиваров.
- умение строить вести QA в миллионе тонкостей: как писать документацию и держать её хоть как-то актуальной, mind maps, как описывать задачи / баги, работа с VCS,… тысячи таких вопросов, которые выглядят мелкими, но ответов на которые дадут десятки
- безопасность
- интернационализация приложений / сайтов (тут не обойтись без хотя бы поверхностного представления о языках и культурах)
- умение построить процесс QA, когда это требуется
- умение отделять мух от котлет — как раз «Умение ориентироваться в приоритетах бизнеса» в словах автора — тоже дело опыта
умение строить вести QA в миллионе тонкостей: как писать документацию и держать её хоть как-то актуальной, mind maps, как описывать задачи / баги, работа с VCS,… тысячи таких вопросов, которые выглядят мелкими, но ответов на которые дадут десятки
- Документация — это боль всегда, причем сильно зависит от компании и инструментов. Опыт в написании документации для одной компании, может быть вполне неприменим для другой, как минимум потому, что у них нет confluence.
- Не подскажите, зачем manual QA нужен mind map?
- Вопрос о том, как описывать задачи и баги почти на 100% лежит на трекинговой системе.
- работа с VCS для мануальщика разве нужна?
безопасность
Это кросс-доменная область, как мне кажется. Или я не прав?
интернационализация приложений / сайтов (тут не обойтись без хотя бы поверхностного представления о языках и культурах)
Это вроде кросс-доменная область, как мне кажется. Или я не прав? Потому что для такого вполне нужен отдельный специалист.
умение построить процесс QA, когда это требуется
Разве таким не должен заниматся QA team lead?
Возможно, я прошу странно, но вот, например, программисту понятно куда расти. Изучать как и общее программирование, так и инструменты, которые используются в языке + учить новые языки. А manual QA нужно уходить в кросс-доменную область?
Если считать обязанностью тестировщика только прокликать все возможные кейсы в чёрном ящике — да, тут конечно расти дальше следования инструкциям некуда. Точно так же как до сих пор кое-где есть программисты, которые занимаются только переводом написанного другим человеком алгоритма в код. Там тоже нет особого пути развития.
В большинстве же случаев сейчас «программист» — не машина для выдачи кода, он занимается такими «кросс-доменными» делами как проектирование, алгоритмизация, оптимизация, поиск новых способов решения задач… То же самое и с тестировщиками. Кликать кнопки — самый базовый уровень, начало карьеры. Хороший тестировщик должен уметь намного больше. Немного автоматизации, немного UX, немного аналитики и оптимизации архитектуры…
В большинстве же случаев сейчас «программист» — не машина для выдачи кода, он занимается такими «кросс-доменными» делами как проектирование, алгоритмизация, оптимизация, поиск новых способов решения задач… То же самое и с тестировщиками. Кликать кнопки — самый базовый уровень, начало карьеры. Хороший тестировщик должен уметь намного больше. Немного автоматизации, немного UX, немного аналитики и оптимизации архитектуры…
>безопасность
>>Это кросс-доменная область, как мне кажется. Или я не прав?
Построение безопасной архитектуры — это зона разработки и администрирования. Проверка безопасности — это зона QA.
Ну и так далее на все предыдущие вопросы. Что бы не делал разработчик, это требует той или иной перепроверки (ибо все мы люди и все мы можем ошибиться или о чем-то не подумать). Чем сложнее манипуляция, тем больше знаний требуется от QA для адекватного тестирования данной манипуляции.
Средний QA знает каждую из областей разработки не так глубоко, как сам разработчик. Но зато он знает о большем количестве областей в целом, потому что сталкивается с их тестированием. Тут Вам и фронт, и бэк, и знание баз данных, и нагрузочное тестирование, и тестирование безопасности, и все виды негативного тестирования и так далее…
Развиваться тестировщик должен в сторону понимания устройства каждой из деталек продукта и способов адекватного тестирования онных.
Адекватный способ тестирования в данном контексте — максимально эффективный по времени и перформансу (читай — как можно быстрее убедиться, что продукт реализован как надо или доказать обратное). Это, пожалуй, самый спороный и сложный вопрос в тестировании. Оказывается, просто кликать по сайту (то, что Вы, видимо, называете мануальным тестировщиком) — чаще всего не самый адекватный способ проверять приложение. Это только первый уровень, Илья писал об этом.
Документация — это боль всегда, причем сильно зависит от компании и инструментов. Опыт в написании документации для одной компании, может быть вполне неприменим для другой, как минимум потому, что у них нет confluence.
Документация по проекту — да, а документация по тому, как тестировать проект — нет. Часто ооочень многими недооценивается факт того, что не весь функционал в проекте тестируется в один клик. И как быстро объяснить кому-то что и как можно протестировать? А новому сотруднику? А если вы сами забыли? А если документации на проекте в принципе нет (читайте — стартап)? Это забота QA создавать подобные заметки, которые потом перерастут в документацию.
Не подскажите, зачем manual QA нужен mind map?
Визуализация и организация данных, которые в виде графов выглядят лучше, чем в текстовом. Так же, как и везде :)
Вопрос о том, как описывать задачи и баги почти на 100% лежит на трекинговой системе.
И да, и нет. Если у вас есть поле description, как вы там опишете какую-то багу? Когда 15 человек на проекте заводят баги с текстом вида "кнопка не работает" — у вас голова опухнет ходить к каждому и спрашивать: "так какая кнока не работает? и КАК она не работает? по enter? по click?" Запись видео, скриншотов, гифок в разных средах, браузерах и операционных системах. Если работаете с вебом, то BugReplay и т.п.
работа с VCS для мануальщика разве нужна?
Сделаю круглые глаза. Абсолютно нужна. Как минимум надо знать git и mercurial хотя бы на базовом уровне. Да вы самому себе упростите жизнь, если научитесь ими пользоваться.
безопасность
Вас же по голове никто не бьёт развиваться в "кросс-доменной" области? То, что вы можете найти не только XSS, но и что-то посерьёзнее (и, более того, знаете как это быстро и эффективно искать) — очень даже большая польза.
А если вы не веб тестируете, а андроид? а iOS? ууу… поле непаханное.
Разве таким не должен заниматся QA team lead?
А если вы единственный человек на проекте? Manual QA может вполне вырасти до QA team lead. Вам не надо уметь писать код для этого, поверьте.
А manual QA нужно уходить в кросс-доменную область?
QA — в принципе кросс-доменная область. Там есть тестирование, обеспечение качества, контроль качества. Если хотите остаться только в тестировании — развивайте навыки и обогащайте знаяния в инструментарии. Знайте слабые и сильные стороны различных браузеров. Тестируете андроид? Какие устройства идут без установленного google play market, а ваше приложение должно бы работать в этой стране? и так далее, и тому подобное.
Грамотный тестировщик — специалист миллиона навыков.
Промазал веткой
Хороший тестировщик на проекте на вес золота. Поэтому приятно слышать что это к кому в удовольствие. Но как отметили выше, не совсем понятно куда расти.
У меня была почти такая же ситуация как у вас, 9 лет назад выбирал между junior developer и senior automaiton dev. Деньги перевесили и пошёл в «сеньёры», но в long term пожалел, ибо стеклянный потолок очень близок, перешёл в iOS dev и ни разу не пожалел (первый год конечно очень тяжело было).
Плюсы:
— очень много вакансий
— твоя работа не так завязана на команду
— результаты твоей работы видят все
— радость от того когда стартуешь проекты с нуля
Из QA получаются отличные PM, DevOps и т.д., но всё же в разработке гораздо комфортней. С такой хорошей технической базой можно ещё два раза карьеру поменять. Удачи
У меня была почти такая же ситуация как у вас, 9 лет назад выбирал между junior developer и senior automaiton dev. Деньги перевесили и пошёл в «сеньёры», но в long term пожалел, ибо стеклянный потолок очень близок, перешёл в iOS dev и ни разу не пожалел (первый год конечно очень тяжело было).
Плюсы:
— очень много вакансий
— твоя работа не так завязана на команду
— результаты твоей работы видят все
— радость от того когда стартуешь проекты с нуля
Из QA получаются отличные PM, DevOps и т.д., но всё же в разработке гораздо комфортней. С такой хорошей технической базой можно ещё два раза карьеру поменять. Удачи
Технически да — в данный момент я уже упёрся в потолок развития для чисто технического специалиста. Поэтому сейчас стал больше заниматься отвлечёнными делами — продуктовыми проектами, геймдевом, деврелом.
Да, для следующего шага рано или поздно придётся менять сферу деятельности (и, возможно, компанию), но это путешествие было интересным и я ни о чём не жалею (:
Да, для следующего шага рано или поздно придётся менять сферу деятельности (и, возможно, компанию), но это путешествие было интересным и я ни о чём не жалею (:
Ну вооот :( Так Вы красиво все расписали, сколько перспектив открывается перед специалистом по QA, каким он может стать важным человеком. Типа: «ребята, все за мной, тут круто!» И на тебе:
Начали за здравие, а кончали за упокой.
Да, для следующего шага рано или поздно придётся менять сферу деятельности (и, возможно, компанию), но это путешествие было интересным и я ни о чём не жалею (:
Начали за здравие, а кончали за упокой.
Я уже поплакал из-за того как плохо построил этот комментарий. Надо было его сначала раз 10 перечитать, скорее всего решил бы ничего не писать :-D
У QA (как, впрочем, и у рядового разработчика) есть однозначный технический потолок, пробить который достаточно сложно. Можно уйти в тим-лиды, можно углубиться в смежные области (например, аналитику и безопасность), а без этого профессиональный рост (и рост заработной платы) начинают сильно замедлятся. Именно про такие шаги я и писал (:
У QA (как, впрочем, и у рядового разработчика) есть однозначный технический потолок, пробить который достаточно сложно. Можно уйти в тим-лиды, можно углубиться в смежные области (например, аналитику и безопасность), а без этого профессиональный рост (и рост заработной платы) начинают сильно замедлятся. Именно про такие шаги я и писал (:
как же приятно всегда почитать такие заметки от людей, которые простолюбят свое дело. без претензий, без обидок на бывшее начальство/коллег и без «мерянья незаменимостью» с другими спецами, которое обычно неуместно. автору спасибо.
Без тестировщиков я работать в проектах отказываюсь сразу.
Причем нужны как минимум два уровня. Те кто тестируют интерфейсы и т.п., и те кто пишут тест-кейсы.
Причем нужны как минимум два уровня. Те кто тестируют интерфейсы и т.п., и те кто пишут тест-кейсы.
А это интересно! Можете раскрыть, чего такого вы ждете от тестировщиков, что не хотите работать без них?
Может я помогу =)
Представьте финансовую или туристическую систему, с сотнями форм, бланков и т.п.
Большие алгоритмические процессы при проводках, заказах и т.п.
Представили? Отлично.
Допустим реализовали новый функционал по определенной юзерстори и ТЗ соответственно.
Написали тесты, все вроде работает. Однако мы все знаем, что зачастую разработчики имеют так называемый «замылиный взгляд». Так же, мы точно знаем, что пользователи обязательно что то сделают, чего не должно было произойти. Где то возможны не верные алгоритмические решения и все в подобном духе.
Как же избежать подобной ситуации? Конечно — стать богом. Но к сожалению, это маловероятно.
И тут на сцену выходит команда тестировщиков. Кто то пишет подробные тест кейсы и различные вариации, кто то все это тестирует.
Понятно, что имеются и автоматизированные тесты.
Из моей 16 летней (сейчас будет уже 17 лет) практики разработки различных крупных продуктов, могу сказать — без тестировщиков, продукт будет постоянно иметь баги, недоработки и различные мелкие косяки.
Не хорошо, когда бизнес из-за этого начинает пробуксовывать а еще хуже, когда клиенты натыкаются на подобные вещи.
Как это работает у нас.
В беклог заводятся различные юзерстори, разработчики делают декомпозицию задач и т.д. Начинает кипеть работа. Есть подготовленные юзер-кейсы от тестировщиков.
Готовые решения складываются в ветки историй. Далее «готовые» истории отправляются к мистеру дженкинсу и собираются в дев. средах. Там производятся различные автоматизированные тесты. Как на интерфейсе так и на бекенде.
Если все ок, и все тесты прошли, собирается полностью готовый вариант на отдельном физическом сервере. Там в работу вступают тестировщики.
Если они находят проблему, соответственно она появляется на доске.
Выставляются приоритеты и далее по накатанной фиксятся/дорабатываются/переделываются. После все по кругу.
В конечном счете, каждая история проходит максимальное количество тестов и вариаций.
Что сводит к миниму проблем.
Тогда тестовому серверу дают зеленый свет и данная сворка мержится в препрод. По сути прод., но с специально репликой. Где внешние клиенты (к примеру триваго или booking.com), не могут оперировать данными, только менеджеры (коих 700 человек).
После мерджа в препрод всех проверенных историй и нормальной отработки, идет деплой в прод., примерно раз в неделю.
Надеюсь я ответил на ваш вопрос подробно, в 4 часа ночи =)
Представьте финансовую или туристическую систему, с сотнями форм, бланков и т.п.
Большие алгоритмические процессы при проводках, заказах и т.п.
Представили? Отлично.
Допустим реализовали новый функционал по определенной юзерстори и ТЗ соответственно.
Написали тесты, все вроде работает. Однако мы все знаем, что зачастую разработчики имеют так называемый «замылиный взгляд». Так же, мы точно знаем, что пользователи обязательно что то сделают, чего не должно было произойти. Где то возможны не верные алгоритмические решения и все в подобном духе.
Как же избежать подобной ситуации? Конечно — стать богом. Но к сожалению, это маловероятно.
И тут на сцену выходит команда тестировщиков. Кто то пишет подробные тест кейсы и различные вариации, кто то все это тестирует.
Понятно, что имеются и автоматизированные тесты.
Из моей 16 летней (сейчас будет уже 17 лет) практики разработки различных крупных продуктов, могу сказать — без тестировщиков, продукт будет постоянно иметь баги, недоработки и различные мелкие косяки.
Не хорошо, когда бизнес из-за этого начинает пробуксовывать а еще хуже, когда клиенты натыкаются на подобные вещи.
Как это работает у нас.
В беклог заводятся различные юзерстори, разработчики делают декомпозицию задач и т.д. Начинает кипеть работа. Есть подготовленные юзер-кейсы от тестировщиков.
Готовые решения складываются в ветки историй. Далее «готовые» истории отправляются к мистеру дженкинсу и собираются в дев. средах. Там производятся различные автоматизированные тесты. Как на интерфейсе так и на бекенде.
Если все ок, и все тесты прошли, собирается полностью готовый вариант на отдельном физическом сервере. Там в работу вступают тестировщики.
Если они находят проблему, соответственно она появляется на доске.
Выставляются приоритеты и далее по накатанной фиксятся/дорабатываются/переделываются. После все по кругу.
В конечном счете, каждая история проходит максимальное количество тестов и вариаций.
Что сводит к миниму проблем.
Тогда тестовому серверу дают зеленый свет и данная сворка мержится в препрод. По сути прод., но с специально репликой. Где внешние клиенты (к примеру триваго или booking.com), не могут оперировать данными, только менеджеры (коих 700 человек).
После мерджа в препрод всех проверенных историй и нормальной отработки, идет деплой в прод., примерно раз в неделю.
Надеюсь я ответил на ваш вопрос подробно, в 4 часа ночи =)
Спасибо вам за подробный комментарий в 4 часа ночи. В такие моменты чувствуешь себя не одиноким =)
То есть вы разрабатываете, а от тестировщиков ждете, что они зарепортят баги и проблемы, которые вам отловить не удалось. Я сам тестировщик и считаю, что это хороший, понятный контракт.
Но есть наблюдение:
Итоговый продукт сильно зависит от процесса разработки. Разработчик завален задачами и делает код-ревью спустя рукава? Аналитику по задаче писал стажер, а опытный аналитик её не посмотрел? Это обязательно породит баги =)
Из этого следует забавный факт (видел такое не раз): чем больше багов в обновлении нашел тестировщик, тем больше он их найдет в дальнейшем. Потому что много багов означают, что в процессе разработки что-то сломалось и лучше уже не будет.
Вы описали многоступенчатый процесс тестирования и обкатки обновлений. Если разработчики, аналитики и другие люди выше по течению будут отдавать недоделанные задачи, то такой процесс не будет сходиться — релизы будут тестироваться месяцами и релизиться не «когда мы пофиксили все баги», а «когда дедлайн» или «когда пришел менеджер и сказал что хватит это тестировать».
В двух словах — я не согласен, когда разработчики и аналитики делают что-то в расчете на то, что «тестировщики все равно все баги найдут». Это плохо заканчивается.
То есть вы разрабатываете, а от тестировщиков ждете, что они зарепортят баги и проблемы, которые вам отловить не удалось. Я сам тестировщик и считаю, что это хороший, понятный контракт.
Но есть наблюдение:
Итоговый продукт сильно зависит от процесса разработки. Разработчик завален задачами и делает код-ревью спустя рукава? Аналитику по задаче писал стажер, а опытный аналитик её не посмотрел? Это обязательно породит баги =)
Из этого следует забавный факт (видел такое не раз): чем больше багов в обновлении нашел тестировщик, тем больше он их найдет в дальнейшем. Потому что много багов означают, что в процессе разработки что-то сломалось и лучше уже не будет.
Вы описали многоступенчатый процесс тестирования и обкатки обновлений. Если разработчики, аналитики и другие люди выше по течению будут отдавать недоделанные задачи, то такой процесс не будет сходиться — релизы будут тестироваться месяцами и релизиться не «когда мы пофиксили все баги», а «когда дедлайн» или «когда пришел менеджер и сказал что хватит это тестировать».
В двух словах — я не согласен, когда разработчики и аналитики делают что-то в расчете на то, что «тестировщики все равно все баги найдут». Это плохо заканчивается.
Еще хуже, когда разработчики пишут в надежде, что баг не будет найден. (отдают заведомо кривой код)
Для код-ревью есть отдельный человек.
Релизы делаются раз в неделю, на прод. попадает вариант, без ошибок в 90-94% случаев.
Я не говорил о аналитике, хотя и такой человек присутствовал, не давно расстались.
Делается не в расчете, что тестироващик найдет обязательно баг. Система так не работает. Каждый баг (именно статус бага в жире), это минус команде. Каждый срыв срока, это тоже минус и т.д.
Естественно, минусы влияют на конечный финансовый результат премии, а если совсем плохо, то и на менеджмент.
По этому вы далеко не правы, что разработчик ждет спасательного круга от отдела тестирования. Скорее он ждет, что данная история уже не вернется к нему в руки.
И обычно так оно и есть.
Но как я сказал, без отдела тестирования, проект легко может забуксовать и то и вовсе, понести серьезные финансовые потери.
Релизы делаются раз в неделю, на прод. попадает вариант, без ошибок в 90-94% случаев.
Я не говорил о аналитике, хотя и такой человек присутствовал, не давно расстались.
Делается не в расчете, что тестироващик найдет обязательно баг. Система так не работает. Каждый баг (именно статус бага в жире), это минус команде. Каждый срыв срока, это тоже минус и т.д.
Естественно, минусы влияют на конечный финансовый результат премии, а если совсем плохо, то и на менеджмент.
По этому вы далеко не правы, что разработчик ждет спасательного круга от отдела тестирования. Скорее он ждет, что данная история уже не вернется к нему в руки.
И обычно так оно и есть.
Но как я сказал, без отдела тестирования, проект легко может забуксовать и то и вовсе, понести серьезные финансовые потери.
К сожалению, программисты-новички так тестировщиков и видят. Спасательный круг, который их выручит от пендюлей руководства.
И уже от руководства зависит, будет ли меняться такое отношение. Если во всех багах винят только тестировщиков — программисты будут становиться всё расслабленнее и проект рано или поздно увязнет. Если ответственность распределяется поровну (или в некоторых случаях даже преимущественно на разработчика), то и сами разработчики начинают меньше уповать на тестирование вместо самих себя.
И уже от руководства зависит, будет ли меняться такое отношение. Если во всех багах винят только тестировщиков — программисты будут становиться всё расслабленнее и проект рано или поздно увязнет. Если ответственность распределяется поровну (или в некоторых случаях даже преимущественно на разработчика), то и сами разработчики начинают меньше уповать на тестирование вместо самих себя.
Те кто тестируют интерфейсы и т.п., и те кто пишут тест-кейсы.— как по-вашему, эти самые два уровня может занимать один тестировщик, или нет?
Без понятия. Если специалист может продумать кейсы и проработать их, то почему нет.
Ведь в сфере разработки часто встречаются full-stack. Но именно по моему мнению, каждый должен заниматься своим делом.
Ведь в сфере разработки часто встречаются full-stack. Но именно по моему мнению, каждый должен заниматься своим делом.
Тестировщик, слепо следующий написанным кем-то другим кейсам — это самое начало карьеры тестировщика. Как программист, который переводит написанный кем-то другим алгоритм в код. Такие практики имеют право на существование, но кажутся мне менее эффективными (хоть и потенциально более надёжными), чем программисты, сами разрабатывающие свою систему и тестировщики, сами прорабатывающий план тестирования компонента.
Я не могу вам ответить на данный вопрос. Хоть мы и связанны с командой тестирования, но не углублялся в их внутреннюю кухню.
Никогда ещё не работал в физически распределённой команде, у нас разработка и тестирование работают совместно всегда. Очень интересно узнать, как что работает при вашей схеме :)
Да все просто =)
Есть доска, на ней всегда видно что происходит. Подробное описание и тест-кейс присутствует. Если что то не понятно, всегда можно обсудить голосом.
Удаленный процесс — выглядит примерно так:
Митинги по утрам.
Общение в основном Slack или если того требует ситуация, то голосом.
По пятницам ретроспектива.
По понедельникам, общение с бизнесом (что бы знать бизнес а не тупо писать код).
В остальном уже технические моменты, типа git, jira/tsf, jenkins и т.п.
Т.к. команды международные а не только Россия и СНГ, то с некоторыми участниками, в живую не знаком. Хотя сам в офисе, бываю довольно часто.
Все остальное время — пишем код =)
В основном с 12ч. до 19ч. по МСК.
Есть доска, на ней всегда видно что происходит. Подробное описание и тест-кейс присутствует. Если что то не понятно, всегда можно обсудить голосом.
Удаленный процесс — выглядит примерно так:
Митинги по утрам.
Общение в основном Slack или если того требует ситуация, то голосом.
По пятницам ретроспектива.
По понедельникам, общение с бизнесом (что бы знать бизнес а не тупо писать код).
В остальном уже технические моменты, типа git, jira/tsf, jenkins и т.п.
Т.к. команды международные а не только Россия и СНГ, то с некоторыми участниками, в живую не знаком. Хотя сам в офисе, бываю довольно часто.
Все остальное время — пишем код =)
В основном с 12ч. до 19ч. по МСК.
То, что свой код проверять нельзя это ясно, но если кодить спарками аналитик-разработчик, на описании задачи и тестировании аналитик, разработчик понятно чем занимается.
Насколько по вашему это нежизнеспособная ситуация?
Регресс тесты автоматические, пишет команда под архитектором, который как раз становится чуть свободнее к середине проекта, когда появляется необходимость в регрессе.
Насколько по вашему это нежизнеспособная ситуация?
Регресс тесты автоматические, пишет команда под архитектором, который как раз становится чуть свободнее к середине проекта, когда появляется необходимость в регрессе.
Мы в Badoo примерно так и разрабатываем. Разработчик берёт задачу из пула, если задача с ходу не ясна — к нему присоединяется QA-инженер (если всё понятно сразу — QA подключается уже после первого resolve) и дальше они работают над задачей сообща, включая все возможные циклы reopen'ов.
Непосредственно над каждой задачей архитектора нет, но есть код-ревью, во время которого сообща решаются любые архитектурные вопросы.
Непосредственно над каждой задачей архитектора нет, но есть код-ревью, во время которого сообща решаются любые архитектурные вопросы.
Отвечаю сразу Вам и @ nizkopal
Я в 1С проектах живу. К счастью, пока XXS слегка не про нас. Соотвественно, аналитик добывает задачу из ключевого пользователя заказчика, и ему же сдаёт. Бизнес-аналитик + QA в одном флаконе.
А архитектор один на проект, типа самый опытный разработчик, в начале именно архитектор, к середине — концу проекта смещается в релиз инженера, главного код ревьювера.
Вот что меня беспокоит в Бизнес-аналитик = QA это же тоже в некотором роде тестирование «собственного кода».
Я в 1С проектах живу. К счастью, пока XXS слегка не про нас. Соотвественно, аналитик добывает задачу из ключевого пользователя заказчика, и ему же сдаёт. Бизнес-аналитик + QA в одном флаконе.
А архитектор один на проект, типа самый опытный разработчик, в начале именно архитектор, к середине — концу проекта смещается в релиз инженера, главного код ревьювера.
Вот что меня беспокоит в Бизнес-аналитик = QA это же тоже в некотором роде тестирование «собственного кода».
Суть не в XSS, а в том, что взгляд аналитика и тестировщика на результат работы разработчика будет разным. Аналитик видит воплащенное ТЗ, где надо проверить все пункты из ТЗ в действии и на этом все.
А вот QA будет видеть продукт, который может быть использован конечным пользователем как угодно. Он будет пытаться предсказать поведение конечного пользователя и проверить те места, где что-то может пойти не так. Включая использование продукта не по назначению.
Так что не удивительно, что интуитивно Вас смущает объединение этих двух ролей.
А вот QA будет видеть продукт, который может быть использован конечным пользователем как угодно. Он будет пытаться предсказать поведение конечного пользователя и проверить те места, где что-то может пойти не так. Включая использование продукта не по назначению.
Так что не удивительно, что интуитивно Вас смущает объединение этих двух ролей.
Ставлю сотку — такой аналитик будет тестировать только позитивные кейзы. Слабо представляю себе ситуацию, где аналитик получает задачу от ПМ: сделать поле ввода, в которое можно ввести текст и он отобразится в таком-то блоке — и аналитик после реализации задачи начинает тестировать это поле на XXS, например. Зачем? Ему задачу «сдать» надо поскорее и приступить к реализации следующей.
— И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.
— Всё, что я напишу в этой статье, основано на моём личном восприятии
Вас не бьют еще? Нет, я сам тестировщик, я практически полностью согласен с тезисами статьи, но, признаться, кое-как заставил себя читать дальше после такого вступления.
— Всё, что я напишу в этой статье, основано на моём личном восприятии
Вас не бьют еще? Нет, я сам тестировщик, я практически полностью согласен с тезисами статьи, но, признаться, кое-как заставил себя читать дальше после такого вступления.
напишите список книг, которые must read, для тестировщика?
Я вот совсем пропустил этот этап обучения, всё познавал уже на собственных шишках)
Но по отзывам могу порекомендовать три книжки:
Скучную, но дельную «Testing computer software» от Cem Kaner и Jack L. Falk
Более читаемую, но менее интересную для опытного специалиста «Software Testing» от Ron Patton
Отличное пособие по тест-дизайну «A Practitioner’s Guide to Software Test Design» от Lee Copeland
Ну и что-нибудь вроде «Как тестируют в Google» чтобы узнать о реальных практиках. Ну или почитать другие наши статьи о тестировании (:
Но по отзывам могу порекомендовать три книжки:
Скучную, но дельную «Testing computer software» от Cem Kaner и Jack L. Falk
Более читаемую, но менее интересную для опытного специалиста «Software Testing» от Ron Patton
Отличное пособие по тест-дизайну «A Practitioner’s Guide to Software Test Design» от Lee Copeland
Ну и что-нибудь вроде «Как тестируют в Google» чтобы узнать о реальных практиках. Ну или почитать другие наши статьи о тестировании (:
Я бы даже назвал — «Все профессии важны: почему хорошего тестировщика нужно ценить больше чем программиста»
Я прожужжал все уши начальнику и добился установки SVN.
Если я не ошибся в подсчетах, шел 2010 год? Тогда вы правильно сделали что
заявление на увольнение я написал тем же вечером.
Путь тестировщика не заканчивается на бездумном клацании кнопок и следовании инструкциям — он с него только начинается. <...> Предпочитаю находить в этом и свой скромный вклад.
Вклад определенно есть. С удовольствием советую всем доклады от badoo и смело иду на них на любых конференциях.
Про путь тестировщика
Шикарный список уровней. В свое время предложил такой:
- Тестер. Ищет баги
- QA. Не наносит вред. Уменьшает количество багов в проекте.
- Гуру. Учит команду писать меньше багов.
- Евангелист. Все, кто с ним общаются создают меньше багов.
- Пророк. Меньше багов создают даже те, кто с ним не общаются.
Любовь к тестированию
Справедливо стоит на первом месте. Илья, большое спасибо за статью.
функционал
Функциональность.
В свое время после работы в технической поддержки мне предложили в компании повышение, и дали денег, как уровня 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 воспринимаются манки-кликарами.
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 воспринимаются манки-кликарами.
Если говорить об Automation QA, то это тот же разработчик, с тем же необходимым бекграундом, включающим с актуальные стеки технологий, фундаментальные/академические знания, понимание этапов жизненного цикла ПО и т.д., но чуть с другим фокусом в работе.
Однако, если говорить по теме статьи, то мои наблюдения рынка вакансий и коллег показывают, что QA _уже_ ценятся больше больше, чем разработчики.
И это неудивительно, учитывая сдвиг разработки в сторону составления кейсов и их проверки (есть и множество других факторов).
При этом есть ощущение, что и QA-вакансий заметно больше, и порог входа заметно ниже, в том числе для Automation QA.
Да, пока разработчики в абсолютных цифрах получают/зарабатывают больше, судя по рынку, раза в полтора.
Но в пересчете на объемы работ и требуемых знаний и скиллов ситуация сильно не в пользу разработчиков.
Однако, если говорить по теме статьи, то мои наблюдения рынка вакансий и коллег показывают, что QA _уже_ ценятся больше больше, чем разработчики.
И это неудивительно, учитывая сдвиг разработки в сторону составления кейсов и их проверки (есть и множество других факторов).
При этом есть ощущение, что и QA-вакансий заметно больше, и порог входа заметно ниже, в том числе для Automation QA.
Да, пока разработчики в абсолютных цифрах получают/зарабатывают больше, судя по рынку, раза в полтора.
Но в пересчете на объемы работ и требуемых знаний и скиллов ситуация сильно не в пользу разработчиков.
Почему нельзя автоматизировать тестирование?
Вы про какой-то конкретный комментарий или "в принципе"?
В принципе. Вроде бы здесь когда-то читал, что нейросеть учат тестировать. Видимо, не получилось.
Пока не получилось, наверное.
Лично моё мнение, что в довольно близкой перпективе вполне можно будет научить нейросеть писать автотесты или юнит-тесты.
Ручное тестирование / QA- немного другая вещь, тут больше работы с материальными объектами и общения с людьми, чем непосредственного взаимодействия с кодом.
Sign up to leave a comment.
Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста