Как стать автором
Обновить

Образ современного тестировщика. Что нужно знать и уметь

Время на прочтение20 мин
Количество просмотров159K
Всего голосов 37: ↑33 и ↓4+29
Комментарии33

Комментарии 33

А возможен QA без QC?
QA вполне себе продолжает выполнять функции QC, ну и падаванов для более простой работы никто не отменял. Это естественный ток вещей- от простого к сложному.

Просто QA — это не то же самое, что QC. Странно читать такое от преподавателя QA/QC.

Я в курсе, но QC часть QA, потому человек с компетенциями и знаниями QA вполне может выполнять функции QC. То если человек перешёл на следующий уровень, то это не значит, что предыдущий становится ему недоступным. Ну и в компании всегда есть поросль, которая подхватит пул задач QC.

Я бы вообще не разделял эти понятия. Есть процесс обеспечения качества и есть процесс его проверки. Это просто части одного целого. От размера проекта и компании зависит то, кто чем занимается. В маленьком проекте организацией и выполнением занимается один человек, в большой — уже есть куча ролей, каждая из которых делает какой-то свой кусок.

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

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

Про «не имеет времени» и «переход на следующий уровень» абсолютно не согласен, смотрите пункт про саморазвитие и увлеченность. За последние 8 лет в моих командах развились десятки высококлассных специалистов и управленцев, кто-то начинал вообще без навыков тестирования, у кого-то были первичные знания и небольшой опыт, но сейчас это Профессионалы, работой с каждым из которых я горжусь. Кто-то стал экспертом ручного тестирования, кто-то автоматизатором, кто-то Тим-лидом, некоторые ушли из тестирования и стали руководить разработкой или продуктом. Я и сам когда-то начинал младшим тестировщиком, пройдя длинный путь до директора по качеству. Всё в наших руках;)
Сперва вы пишите:
В своей статье я постараюсь в общих чертах рассказать, что нужно знать и уметь, чтобы работать специалистом в области обеспечения качества в наиболее популярных и востребованных направлениях.
Ключевое слово тут «в общих чертах», то есть идет речь про обязательный, минимальный набор знаний для хорошего специалиста.

Затем идет такое:
А со временем вы уже не сможете обходиться и без bash-скриптов, работы с файловыми дескрипторами, конвейерами и регулярками.

Про bash и регулярки в принципе понятно, но объясните, зачем остальное среднестатистическому, но все же хорошему специалисту по тестированию?

Вообще во многом статья выглядит так:
  1. Налили воды про личные качества, что применимо к любой профессии
  2. Добавили личного опыта, который в прочем очень даже неплох — это плюс
  3. Получилось слишком мало — накидаем еще немного терминов, которые скорее всего не пригодятся, но пусть будут
Я в деталях очерчиваю знания и навыки, что нужны на входе, а для того, чтобы не возникло ощущения, что работа с консолью ограничивается командами чтения файлов и работы с папками набрасываю о перспективах, в которые окунется специалист, выбрав эту дорожку для себя.

Про личные качества бы не писал, если бы за последние несколько сотен собеседований не зафейлил изрядное количество кандидатов именно по этим чертам. Ну и вдобавок, как мне кажется, в статье неплохие приемы для самодиагностики на предмет ответсвенности, увлеченности и т.д. А то ведь на собеседованиях все потом горазды рассказывать какие они ответственные и увлеченные, только последние 5 мест работы они меняли из-за начальства, коллег, проекта и кризиса, а не из-за собственных просчетов. Да и с увлеченность беда такая, что даже хобби нет, а те, что есть в состоянии «нет времени, когда устроюсь на новое место, то снова начну заниматься».
А вы описываете совсем уж ручную макаку в вакууме. В реальности на проектах (хотя, где-то, конечно и не повезёт) будет хватать моментов, когда нужно будет учиться чему-то новому именно чтобы продолжить то самое тестирование ручками.
А как вам такая ситуация: кончился один проект, ручного тестера перебрасывают на другой и говорят, что тут ты будешь автоматизировать тесты на джаве и селениуме, потому что надо!? Такая ситуация у меня однажды возникла. Я, естественно, не возражал и какие-то основы джавы подобрал буквально за 2-3 недели.
Автоматизированные тесты очень дороги в поддержке, и задач, в которых цена ошибки настолько велика чтобы оплачивать поддержку автотестов не так много и все они либо в банковском секторе либо в критическом по типа авиации /медицины/ атомные станции etc.

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


Понятно что просто перевести всё ручное на автоматическое будет сначала дорого. Но зато полная проверка системы которая в ручном режиме занимала N часов может быть проверена за N минут. Это ли не профит для бизнеса?


P.S.
Я не тестировщик, а разработчик если что.

Я начинал с ручной макаки и сейчас занимаюсь автоматизацией в загранице.

Секрет успеха прост: «нужно шагать так широко, чтобы штаны трещали, но не рвались»©.

Я менял работодателей. Каждый новый шаг всегда приводил к усложнению задач. Началось с тупого выкликивания кейсов, затем ручная работа с минимумом автоматизации, дальше минимум ручной работы максимум автоматизации и вот сейчас 100% автоматизации.
4 шага, 4 работодателя, ~4 года.

Как пройти такой путь за такой срок в рамках одной, даже крупной, компании я не представляю.
Спасибо, за статью. Заголовки могут служить каркасом оценки кандидатов: «Кандидат коммуникабелен, основ тестирования не знает, обладает знаниями языка Java, претендует на лидирующие позиции». Приведённые факторы встречаются в разном сочетании.

В команде нужны разные люди — весёлый, терпеливая, умный, в платье, с бородой,… и гитарист. Это шутка, в которой лишь доля шутки. А для сложных систем нужны команды.

Благодарю! Рад, что статья пришлась по нраву. Согласен по поводу оценки кандидатов, у меня есть комплексное решение оценки кандидатов, в котором под сотню различных качеств, знаний и компетенций. При случае сделаю статью с рекомендациями по использованию этого решения. Возможно также окажется полезным этот материал. Stay tuned!

Открывая вакансию senior QA engineer компания может искать 3 различных человека:
1 инженер — автоматизатор который большую часть времени будет заниматься написанием автотестов и их поддержкой
2 инженер который будет заниматься ручным тестированием и написанием текстовой документации.
3 инженер который поставит тестирование в данной компании и наладит все связанные с тестированием процессы.
Порой люди сами не знают кого ищут.

Из километрового списка требований невольно сложилось впечатление что тестировщик — чуть ли не самая сложная должность в IT сфере.

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

НЛО прилетело и опубликовало эту надпись здесь
Честно говоря, не увидел здесь системного администратора. ТС описал лишь базовые вещи, которыми должен обладать тестировщик. Если он чего-то не знает — можно изучить в процессе.
нетипизированный Python

С каких пор так? Всегда думал, что Python имеет динамическую — строгую типизацию.
Спасибо, конкретизировал и поправил.
Большое спасибо за отличную статью! Читала и почти на каждом предложении яростно кивала. :)
Благодарю за обратную связь, делитесь с коллегами, уверен, будет полезно :)
Теперь хотя бы понятно, откуда берутся на собеседованиях вопросы обо всём на свете, кроме того, что реально будет нужно в проекте.
В проекте не будет возможности заняться автоматизацией — спросят про основы ООП. Все машины в команде на Винде — спросят про линуксовую командную строку. Написанием тесткейсов занимается отдельная команда — попросят тестировать лифт или карандаш. У тестировщиков нет доступа к БД — обязательно будут просить написать SQL запрос на бумаге.

Не бывает живых людей, которые знают всё и хороши в любой области. Куда важнее понять, куда лично ты хочешь двигаться и развивать именно эти направления. А не бежать за всеми поездами одновременно
Отчасти для конкретизации направлений и писал эту статью, позволит не искать сферического супер-тестировщика-всезнайку, а найти специалиста в нужном профиле.
Образ современного программиста. Что нужно знать и уметь
— Вам нужно быть коммуникабельным, решительным, лидером, верить в свои силы и уметь постоять за себя
— Уметь программировать
— Знать языки программирования
— Знать фреймворки
— Уметь запускать прграммы
Ура! Прекрасная, глубокая статья готова, выкладываю на хабр.
С удовольствием прочитал бы такую статью в разрезе различных специальностей/направлений, ведь разработкой хотят заниматься десятки тысяч людей, но сталкиваются с такой же проблемой, что и тестировщики, то есть не понимают, что именно нужно учить для каждого конкретного профиля в первую очередь, а что можно отложить на потом или не изучать вовсе.
Из праздного любопытства было бы интересно взглянуть на проект, в котором все тестирование организованно «по методичке» — тест-стратегия, тест-кейсы и т.д. Хотя под такой грудой формулярства было бы тяжело работать.

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

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

Выгорание на работе происходит у всех, даже у самых замотивированных, увы. Причем по личному опыту, чем более мотивированным был человек, тем громче и с бОльшими последствиями он демотивируется. В духе поговорки про «чем больше шкаф, тем громче падает»:( Знаю немало кейсов переходов в тестирование из разработки и наоборот, универсальной профессии не существует. Рад, что в итоге обрели свое место и задачи, которые не вызывают печали и ужаса.
Спасибо огромное за статью! Как новичку, очень интересно было прочитать и заиметь определенный вектор.
В 90% вакансий на QA пишут про опыт работы с облаками AWS, Azure
Что именно необходимо знать тестировщику по работе с облаками?

А еще интересно, возможно ли QA/QC инженеру вырасти в DevOps'a?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий