Комментарии 33
Тестировщики всё чаще становится QA-инженерами
А кто тогда остаётся заниматься QC?
Просто QA — это не то же самое, что QC. Странно читать такое от преподавателя QA/QC.
Я в курсе, но QC часть QA, потому человек с компетенциями и знаниями QA вполне может выполнять функции QC. То если человек перешёл на следующий уровень, то это не значит, что предыдущий становится ему недоступным. Ну и в компании всегда есть поросль, которая подхватит пул задач QC.
Я бы вообще не разделял эти понятия. Есть процесс обеспечения качества и есть процесс его проверки. Это просто части одного целого. От размера проекта и компании зависит то, кто чем занимается. В маленьком проекте организацией и выполнением занимается один человек, в большой — уже есть куча ролей, каждая из которых делает какой-то свой кусок.
И переходить с уровня на уровень практически не возможно- только для очень энергичных электронов — возможно сразу только впрыгивать на потенциальный уровень авто тестировщика например. Но мне кажется это удел ребят которые спрыгнули с энергетического уровня разработчиков кода.
Про автоматизацию, сейчас экономически целесообразная автоматизация тестирования существует в десятках и сотнях компаниях на отечественном рынке, все довольно легко считается и оправдано.
Про «не имеет времени» и «переход на следующий уровень» абсолютно не согласен, смотрите пункт про саморазвитие и увлеченность. За последние 8 лет в моих командах развились десятки высококлассных специалистов и управленцев, кто-то начинал вообще без навыков тестирования, у кого-то были первичные знания и небольшой опыт, но сейчас это Профессионалы, работой с каждым из которых я горжусь. Кто-то стал экспертом ручного тестирования, кто-то автоматизатором, кто-то Тим-лидом, некоторые ушли из тестирования и стали руководить разработкой или продуктом. Я и сам когда-то начинал младшим тестировщиком, пройдя длинный путь до директора по качеству. Всё в наших руках;)
В своей статье я постараюсь в общих чертах рассказать, что нужно знать и уметь, чтобы работать специалистом в области обеспечения качества в наиболее популярных и востребованных направлениях.Ключевое слово тут «в общих чертах», то есть идет речь про обязательный, минимальный набор знаний для хорошего специалиста.
Затем идет такое:
А со временем вы уже не сможете обходиться и без bash-скриптов, работы с файловыми дескрипторами, конвейерами и регулярками.
Про bash и регулярки в принципе понятно, но объясните, зачем остальное среднестатистическому, но все же хорошему специалисту по тестированию?
Вообще во многом статья выглядит так:
- Налили воды про личные качества, что применимо к любой профессии
- Добавили личного опыта, который в прочем очень даже неплох — это плюс
- Получилось слишком мало — накидаем еще немного терминов, которые скорее всего не пригодятся, но пусть будут
Про личные качества бы не писал, если бы за последние несколько сотен собеседований не зафейлил изрядное количество кандидатов именно по этим чертам. Ну и вдобавок, как мне кажется, в статье неплохие приемы для самодиагностики на предмет ответсвенности, увлеченности и т.д. А то ведь на собеседованиях все потом горазды рассказывать какие они ответственные и увлеченные, только последние 5 мест работы они меняли из-за начальства, коллег, проекта и кризиса, а не из-за собственных просчетов. Да и с увлеченность беда такая, что даже хобби нет, а те, что есть в состоянии «нет времени, когда устроюсь на новое место, то снова начну заниматься».
Автоматизированные тесты очень дороги в поддержке, и задач, в которых цена ошибки настолько велика чтобы оплачивать поддержку автотестов не так много и все они либо в банковском секторе либо в критическом по типа авиации /медицины/ атомные станции etc.
У меня мнение обратное: ручное тестирование не масштабируется вообще никак.
Авто-тесты же очень хорошо масштабируются.
Авто-тесты могут быть дороги в поддержке если идёт постоянная и кардинальная смена интерфейсов, которые эти тесты используют. Если интерфейсы меняются хотя бы не кардинально, то и поддержка будет не очень сложной.
Понятно что просто перевести всё ручное на автоматическое будет сначала дорого. Но зато полная проверка системы которая в ручном режиме занимала N часов может быть проверена за N минут. Это ли не профит для бизнеса?
P.S.
Я не тестировщик, а разработчик если что.
Секрет успеха прост: «нужно шагать так широко, чтобы штаны трещали, но не рвались»©.
Я менял работодателей. Каждый новый шаг всегда приводил к усложнению задач. Началось с тупого выкликивания кейсов, затем ручная работа с минимумом автоматизации, дальше минимум ручной работы максимум автоматизации и вот сейчас 100% автоматизации.
4 шага, 4 работодателя, ~4 года.
Как пройти такой путь за такой срок в рамках одной, даже крупной, компании я не представляю.
В команде нужны разные люди — весёлый, терпеливая, умный, в платье, с бородой,… и гитарист. Это шутка, в которой лишь доля шутки. А для сложных систем нужны команды.
Благодарю! Рад, что статья пришлась по нраву. Согласен по поводу оценки кандидатов, у меня есть комплексное решение оценки кандидатов, в котором под сотню различных качеств, знаний и компетенций. При случае сделаю статью с рекомендациями по использованию этого решения. Возможно также окажется полезным этот материал. Stay tuned!
Открывая вакансию senior QA engineer компания может искать 3 различных человека:
1 инженер — автоматизатор который большую часть времени будет заниматься написанием автотестов и их поддержкой
2 инженер который будет заниматься ручным тестированием и написанием текстовой документации.
3 инженер который поставит тестирование в данной компании и наладит все связанные с тестированием процессы.
Порой люди сами не знают кого ищут.
нетипизированный Python
С каких пор так? Всегда думал, что Python имеет динамическую — строгую типизацию.
В проекте не будет возможности заняться автоматизацией — спросят про основы ООП. Все машины в команде на Винде — спросят про линуксовую командную строку. Написанием тесткейсов занимается отдельная команда — попросят тестировать лифт или карандаш. У тестировщиков нет доступа к БД — обязательно будут просить написать SQL запрос на бумаге.
Не бывает живых людей, которые знают всё и хороши в любой области. Куда важнее понять, куда лично ты хочешь двигаться и развивать именно эти направления. А не бежать за всеми поездами одновременно
— Вам нужно быть коммуникабельным, решительным, лидером, верить в свои силы и уметь постоять за себя
— Уметь программировать
— Знать языки программирования
— Знать фреймворки
— Уметь запускать прграммы
Ура! Прекрасная, глубокая статья готова, выкладываю на хабр.
Имхо, по собвественному опыту понял, что главное в тестировщике не увлеченность в саморазвитии (что де факто стандарт для IT-отрасли) и даже не стартовые знания, а некоторый склад ума, позволяющий легко и с интересом относится к обьемным, монотонным и повторяющимся задачам, из которых по сути состоит любой проект, особенно после некоторого времени работы на нём, когда проходит эффект новизны. В свое время подобный формат задач привел меня к выгоранию и потере какого-либо интереса к проекту, команде, нуждам заказчика. И никакие возможности по саморазвитию и повышению скиллов не спасли, просто не тот уровень работы. После чего решил сменить профиль деятельности и не прогадал в итоге, о времени работы тестировщиком, за исключением пары проектов, вспоминаю с ужасом.
Про стандарт, очень хотелось бы, чтобы в профессию приходили замотивированные, увлечённые и склонные к самообучению люди, однако, в индустрии полно и аморфных тюленей с сомнительной денежной или имиджевой мотивации, а то и вовсе людей, которые просто хотят быть на хайпе.
Выгорание на работе происходит у всех, даже у самых замотивированных, увы. Причем по личному опыту, чем более мотивированным был человек, тем громче и с бОльшими последствиями он демотивируется. В духе поговорки про «чем больше шкаф, тем громче падает»:( Знаю немало кейсов переходов в тестирование из разработки и наоборот, универсальной профессии не существует. Рад, что в итоге обрели свое место и задачи, которые не вызывают печали и ужаса.
Что именно необходимо знать тестировщику по работе с облаками?
А еще интересно, возможно ли QA/QC инженеру вырасти в DevOps'a?
Образ современного тестировщика. Что нужно знать и уметь