Тестирование ПО (Тестировщик, QA инженер)

zffman, а поделитесь, без особой конкретики, если можно? просто интересно. а то мы все про джунов, да про джунов. а дев баю доверять можно тоже с оглядкой

DenisN89:

Термины терминами. Но приходит на собеседование человек с 3 годами опыта и говорит, что тестирование обеспечивает качество и цель это обеспечивать качество. Поговоришь с таким и понимаешь, что человек сам до конца не понимает, чем занимается

я как бы не qa ни разу, но
quality assurance - the maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production

DenisN89:

Куда больше это сколько? На 50, 100, 150 процентов?

В зависимости от скиллов разумеется. Ибо это тот же мануальный тестировщик, только с солидными знаниями по автоматизации. Чем знания солиднее, тем выше зп. Крутой синьор автоматизатор получает на уровне синьора джавы.

DenisN89:

Которая поможет ему в чем?

Даже не знаю что на это ответить. Действительно, чем же поможет человеку, занимающемуся разработкой тестовых фреймворков, инструментов и самих тестовых сценариев познания в тестировании...

DenisN89:

Термины терминами. Но приходит на собеседование человек с 3 годами опыта и говорит, что тестирование обеспечивает качество и цель это обеспечивать качество. Поговоришь с таким и понимаешь, что человек сам до конца не понимает, чем занимается

Он занимается тем, что ищет дефекты и по возможности оптимизирует процесс разработки и тестирования в плане эффективности. За что ему и платят. И да, он таки старается обеспечивать качество. Или в минимальном уровне через ловлю багов(работа только на своей стадии), или более глобально через влияние на весь процесс разработки. А болтологией про термины занимаются wanna-be-manager и прочие подобные.

DenisN89:

Для тестера? Вообще предполагается, что их разработчики должны писать. Зачем этот навык тестерам?

Не, если веслать на толстого пендоса в стиле "я тестировщик, мое дело маленькое" то конечно не надо. А если хочется и денег заработать, и работать серьезно - очень пригодится. Например помощь разработке в составлении тесткейсов, ревью юнит-тестов и даже в написании юнит-тестов по фиче в момент аврала - позволяет дофига косяков отлавливать на стадии юнит тестов при сборке билда, и тем самым увеличить общую эффективность цикла разработки. Всякую менеджерскую пургу про цену дефекта в зависимости от фазы разработки, где он был обнаружен - приводить думаю не надо.

DenisN89:

Ну как бы и просто тестировщики без особых технических скиллов (наличие стандартных, которые позволяют выполнять работу) не сильно меньше 2к просят, если вообще меньше. Все последние собеседования - кандидаты в районе 2к просят. 2-3 года опыта у кандидатов

Просить они могут все что угодно.

oOFlyAngelOo:

В зависимости от скиллов разумеется. Ибо это тот же мануальный тестировщик, только с солидными знаниями по автоматизации. Чем знания солиднее, тем выше зп. Крутой синьор автоматизатор получает на уровне синьора джавы.

Крутой тестировщик, с хорошими аналитическими скиллами и отличными знаниями ui/ux тоже будет зарабатывать не мало.

oOFlyAngelOo:

Даже не знаю что на это ответить. Действительно, чем же поможет человеку, занимающемуся разработкой тестовых фреймворков, инструментов и самих тестовых сценариев познания в тестировании...

Так спецификацию для всего этого могут делать сторонние люди. Точно так же, как сценарии для автоматизации может дать тестировщик. А использование в написании кода хорошего тестировщика это просто нерациональное использование этого тестировщика (в большинстве случаев)

oOFlyAngelOo:

Он занимается тем, что ищет дефекты и по возможности оптимизирует процесс разработки и тестирования в плане эффективности. За что ему и платят. И да, он таки старается обеспечивать качество. Или в минимальном уровне через ловлю багов(работа только на своей стадии), или более глобально через влияние на весь процесс разработки

Такой подход приводит к тому, что огромная часть времени тратится на сомнительные случаи, сложно воспроизводимые в реальной жизни, но дающие какое-то количество багов ради рисования статистики по багам.
но даже поиск багов не дает никакого обеспечения качества, а дает записи в баг трекере. Понимание того, что такое тестирование это шаг к тому, чтобы быть хорошим тестировщиком

oOFlyAngelOo:

если веслать на толстого пендоса в стиле "я тестировщик, мое дело маленькое" то конечно не надо. А если хочется и денег заработать, и работать серьезно - очень пригодится. Например помощь разработке в составлении тесткейсов, ревью юнит-тестов и даже в написании юнит-тестов по фиче в момент аврала - позволяет дофига косяков отлавливать на стадии юнит тестов при сборке билда, и тем самым увеличить общую эффективность цикла разработки.

Ну как раз если на толстого работать, то и будет шанс появления unit тестов на проекте. Во всех случаях, когда они требовались, это было требование заказчиков. В целом, крайне редко видел эффективное использование unit тестов, поэтому и не считаю, что тестеру нужно на них тратить время.
Эффективность unit тестов примерно из той же оперы, что и: "Мы сейчас покроем все тест кейсами, напишем кучу автотестов по ним и у нас будет отличный продукт". Хорошее в этом только то, что можно заказчику показывать красивые графики, тестовое покрытие и тому подобное

oOFlyAngelOo:

Просить они могут все что угодно.

Ну и получают. Особенно, если около 2к это немного меньше. В таком случае тестеру с 3 годами опыта и головой на плечах найти работу вообще не проблема. Если больше 2к, то немного сложнее, может неделю займет

такое чувство что дискуссия зашла не в то русло ИМХО глупо спорить, какая рука лучше и важнее, правая и левая. они обе нужны. и есть левши и правши

Таки выделяет. Как можно более быстрый и полный фидбек о состоянии продукта - это ключевая вещь в данном случае. А этим занимается не кто-то, а именно тестировщик.
Другие лица на проекте только производят CO2 и повышают энтропию

SpiritMoon:

DenisN89:

По делу? Ну, например, тестировщик в принципе не может обеспечить качество.
Тестировщик может оценить приложение и указать на проблемы. Обеспечивается в таком случае качество? Нет, не обеспечивается

Виртуальный "дай пять", но не все это понимают.

Как уже отмечали, часто смешивается QA и тестирование. Но так или иначе, обеспечить качество - это в интересах тестировщика. Т.е. условно говоря - не только отрепортить баги, но и выесть мозг программисту, например, чтобы он закрыл все мейджоры до закрытия стори.
И вообще, процессы ставить на проекте, если их нету, - задача не тестировщика, конечно, но сильно в его интересах.

oOFlyAngelOo:

Конечно, но спектр рабочих предложений поменьше. А про аналитические скиллы - имхо у каждого уважающего себя тестировщика они должны быть.

Точно так же, как и у супер крутого автоматизатора.
И то, и то будет встречаться редко. Но если судить по таким случаям, то можно любую профессию назвать высокооплачиваемой. Хороший сантехник с рекомендацией и 300 usd в день может делать.

oOFlyAngelOo:

Работайте на продуктовой конторе, и будет вам счастье.

я и работаю

oOFlyAngelOo:

Если же цель вашей работы качественный продукт, который приносит компании бабос, из которого вам перепадает ваш кусочек - подход совершенно иной. И да, хорошие юнит тесты и автотесты имеют огромное значение. Скорость доставки фичи папример, и все такое.

Качественный бабос и принесение денег вообще не зависит от наличия автотестов. Бабос будет приносить проект, который востребован на рынке, хорошо рекламируется и у которого хорошо проработана монетизация.
Сколько там автотестов - вообще побоку. В случае мобильных проектов и многих веб проектов написание таких тестов займет больше времени чем тестирование фичи, а пользы принесет меньше.

zffman:

Но так или иначе, обеспечить качество - это в интересах тестировщика. Т.е. условно говоря - не только отрепортить баги, но и выесть мозг программисту, например, чтобы он закрыл все мейджоры до закрытия стори.

Выносить мозг программисту вообще не дело тестировщика. За релиз отвечает определенный человек и он решает с чем идти, а с чем не идти. Но даже не в этом суть. Наличие или отсутствие багов это так себе критерий качества. Качественный продукт - это тот, который удовлетворяет запросы заказчика и пользователей и за который готовы буду платить деньги. Можно показать менеджеру проблемы продукта, можно высказывать свое мнение по багам и по релизу. Но это не обеспечение качества, это попытки повлиять на решения, которые могут повлиять на качество.

oOFlyAngelOo:

Мое мнение простое - любой тестировщик должен стараться обеспечивать качество, в том числе и через настройку процессов.

Так настройка процессов тоже не обеспечит качество. Оптимизированные процессы в тестировании обеспечат качество работы тестировщиков, а не качество продукта

Выносить мозг программисту вообще не дело тестировщика. За релиз отвечает определенный человек и он решает с чем идти, а с чем не идти.

In an ideal world

Но даже не в этом суть. Наличие или отсутствие багов это так себе критерий качества. Качественный продукт - это тот, который удовлетворяет запросы заказчика и пользователей и за который готовы буду платить деньги. Можно показать менеджеру проблемы продукта, можно высказывать свое мнение по багам и по релизу. Но это не обеспечение качества, это попытки повлиять на решения, которые могут повлиять на качество.

Если заходить с этой точки зрения, то безусловно - обеспечить качество мы не можем (только лишь косвенно повлиять). Но вы сами смешиваете качество с технической точки зрения, и качество продукта в целом с точки зрения конечного пользователя (где уже играют роль менеджерские решения, стратегия развития, понимание аудитории и тд).

oOFlyAngelOo:

Тогда откуда пассажи про графики для заказчика и прочее?

Потому что насмотрелся на всякое, не первый год работаю. И бывает, что на аутсорсе любят рисовать графики разыне, чтобы заказчику показать

oOFlyAngelOo:

А потом включатся факторы скорости доставки фич(конкуренты не дремлют)

И как на это влияют автотесты? Новая фича, написать их нужно, время уходит.
Тестирование фичи без автотестов будет быстрее чем с ними.

oOFlyAngelOo:

стабильности версий(конкуренты все еще не дремлют)

Опять таки, имеет смысл, когда функциональность легко ломается, но мало меняется при этом. Тогда часть проверок может быть вынесено на автоматизацию
Я говорю не только о проектах на 3 месяца. В принципе написание автоматических проверок далеко не всегда имеет смысл. Зачастую просто трата времени, а иногда еще и ухудшение тестирования (когда люди уверены, что тестирование можно автоматизировать и заменяют тестирование проверками)