Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Один мой руководитель говорил, что сотрудник в том месте, где надо думать, через год работы только перестает приносить вред, а через два начинается хоть какая-то польза. Не на третий год опыта, а на третий год работы в одном месте.
Я с ним согласен.
Я добавлю еще причин низкого уровня. Например, уход квалифицированных тестировщиков в другие направления, как следствие их неспособности объяснить руководству ценность квалифицированных кадров. Непонимание направлений роста. Странное, непонятное и глупое, но все же бытующее среди тестировщиков поверье, что они делятся на «ручных» или «мануальных» и «автоматизированных».
А еще — самая простая причина. Это просто молодая профессия. Судя по ощущениям, а также опросам, которые я проводил, примерное время старта 2005-2010год. То есть специалистов, которых с трудом еще можно назвать опытными — 10 лет работы — единицы.
Я с ним согласен.
Я добавлю еще причин низкого уровня. Например, уход квалифицированных тестировщиков в другие направления, как следствие их неспособности объяснить руководству ценность квалифицированных кадров. Непонимание направлений роста. Странное, непонятное и глупое, но все же бытующее среди тестировщиков поверье, что они делятся на «ручных» или «мануальных» и «автоматизированных».
А еще — самая простая причина. Это просто молодая профессия. Судя по ощущениям, а также опросам, которые я проводил, примерное время старта 2005-2010год. То есть специалистов, которых с трудом еще можно назвать опытными — 10 лет работы — единицы.
Согласен с Вами относительно молодости отрасли. Как результат: большое количество не доведённых до ума стандартов, методов управления и направлений для роста, что усугубляется большими денежными оборотами в сфере.
Так же согалсен и с наличием текучки кадров. Сейчас реалии таковы, что средний срок работы в одной IT компании — менее двух лет. И это считается нормальным.
В свою очередь не согласен с вашим мнением о пользе спустя год или более. Я думаю это было правдой ещё 5-10 лет назад. Но не сейчас.
Не в это время время и не в мире сверхзвуковой скорости развития технологий и методов, успевать за которыми практически не реально.
И этот мир требует даже от новичков умений быстро включиться, стать эффективными и начать приносить результат уже «на вчера».
Так же согалсен и с наличием текучки кадров. Сейчас реалии таковы, что средний срок работы в одной IT компании — менее двух лет. И это считается нормальным.
В свою очередь не согласен с вашим мнением о пользе спустя год или более. Я думаю это было правдой ещё 5-10 лет назад. Но не сейчас.
Не в это время время и не в мире сверхзвуковой скорости развития технологий и методов, успевать за которыми практически не реально.
И этот мир требует даже от новичков умений быстро включиться, стать эффективными и начать приносить результат уже «на вчера».
От того, что мир требует какой-то навык от новичков, новички не начнут «рождаться» с ним :) Да и речь идет не о владении конкретным прикладным инструментом или технологией, а о нанесении пользы — штуке значительно более сложной и неоднозначной.
И не переходя на личности, но возможно стоит приобрести опыт работы долгосрочной работы в одной компании, сравнить с краткосрочными проектами и провести ретроспективу. Просто это сильно похоже на ту ситуацию, когда единственным доказательством может стать лишь свой собственный опыт.
И не переходя на личности, но возможно стоит приобрести опыт работы долгосрочной работы в одной компании, сравнить с краткосрочными проектами и провести ретроспективу. Просто это сильно похоже на ту ситуацию, когда единственным доказательством может стать лишь свой собственный опыт.
Да чесно говоря, эта публикация основана на опыте не только в тех компаниях, где работал я. Этот вопрос мне интересен в целом, и я, интересовался, как дела обстоят в компаниях у друзей или знакомых.
Опыт мой, как мне кажется, был не таким уж краткосрочным(1.4 в одной, 1 в другой, 0.2 в текущей).
Если быть наблюдательным и небезучастным, поддерждивать связи и интересоваться, этого опыта достаточно, чтобы выводы начинали вырисовываться сами.
Опыт мой, как мне кажется, был не таким уж краткосрочным(1.4 в одной, 1 в другой, 0.2 в текущей).
Если быть наблюдательным и небезучастным, поддерждивать связи и интересоваться, этого опыта достаточно, чтобы выводы начинали вырисовываться сами.
Довольно сомнительная вещь, основываться на чужом опыте в разрезе вопроса «какую пользу я действительно приношу компании», не замечаете? :)
Нельзя говорить, что опыта достаточно, если он не релевантен обсуждаемой проблеме. Wolonter говорил о 3 годах как о переломной точке, следовательно все выводы, сделанные до нее, могут поменяться.
Да и вообще, речь не столько о времени с последней записи в трудовой книжке, сколько о глубине погружения в проблему. Можно искупаться в большинстве ближайших озер, но это не откроет вам тайн океана.
Нельзя говорить, что опыта достаточно, если он не релевантен обсуждаемой проблеме. Wolonter говорил о 3 годах как о переломной точке, следовательно все выводы, сделанные до нее, могут поменяться.
Да и вообще, речь не столько о времени с последней записи в трудовой книжке, сколько о глубине погружения в проблему. Можно искупаться в большинстве ближайших озер, но это не откроет вам тайн океана.
Глен Майерс написал свою книгу в 1978 году. Со временем, эта книга не потеряла своей актуальности, а даже наоборот.
Только вот ведь какая незадача — большинство этих самых свитчеров, прочитав ее, не смогут не то, чтобы начать использовать в реальной работе, а даже банально понять.
Только вот ведь какая незадача — большинство этих самых свитчеров, прочитав ее, не смогут не то, чтобы начать использовать в реальной работе, а даже банально понять.
Интересная теория. Выходит от большинства IT специалистов один вред — в наше время редко кто-то работает на одном месте больше года, а тем более больше трех.
в наше время редко кто-то работает на одном месте больше года, а тем более больше трех
Не стоит так уж обобщать. Мои наблюдения — противоположны. Среднее время работы на одном месте среди тех, кого я знаю и с кем работал — больше двух лет точно и наверняка больше трех. Те, с кем я хотел бы работать, компании меняют в разы реже.
И да, судя по качеству выпускаемых продуктов, сервисов, по кратности продалбывания сроков, по объему трудозатрат на единицу продукции — именно вред.
2.5 года в отрасли и уже судите? Вы сами откуда в QA пришли?
Эта публикация может быть обращением или началом дискуссии. Но она была создана не для осуждения, и старался дать об этом понять.
Я не стремлюсь приписывать себе опыта, которого не имею, или считать себя достаточно опытным для чего бы то ни было.
Сам пришел в отрасль после университета, где получил техническое образование.
Я не стремлюсь приписывать себе опыта, которого не имею, или считать себя достаточно опытным для чего бы то ни было.
Сам пришел в отрасль после университета, где получил техническое образование.
У меня возник вопрос, аналогичный заданному Вам. Имхо было бы хорошо вынести ответ в самое начало статьи, чтобы у читателя не возникало предубеждения.
Я осознаю, что, объективно говоря, мне рановато делать выводы и публиковать наблюдения типа тех, что я описал в этой статье.
Но у меня в свою очередь есть вопрос к вам.
Действительно ли важно кол-во лет опыта, если имеет значение описанное в статье?
Ведь кроме комментариев о недостаточном опыте, никаких дополнений или рассуждений на счёт описанного в публикации я с вашей стороны не увидел.
Но у меня в свою очередь есть вопрос к вам.
Действительно ли важно кол-во лет опыта, если имеет значение описанное в статье?
Ведь кроме комментариев о недостаточном опыте, никаких дополнений или рассуждений на счёт описанного в публикации я с вашей стороны не увидел.
Я считаю, что некоторое кол-во лет опыта — необходимое (но не недостаточное) условие того, чтобы быть профессионалом.
По поводу содержания статьи… Вы подняли очень важный вопрос. Мегаважный, и имеющий отношение не только к тестированию, но и к непосредственно разработке, и к менеджменту. Этот вопрос — недостаток квалифицированных кадров. Из-за свитчеров это происходит или нет, в тестировании или другой отрасли — какая, собственно, разница, если профессионализм определяется количеством вложенных в дело умственных и физических усилий?
По поводу содержания статьи… Вы подняли очень важный вопрос. Мегаважный, и имеющий отношение не только к тестированию, но и к непосредственно разработке, и к менеджменту. Этот вопрос — недостаток квалифицированных кадров. Из-за свитчеров это происходит или нет, в тестировании или другой отрасли — какая, собственно, разница, если профессионализм определяется количеством вложенных в дело умственных и физических усилий?
Уважаемый автор, ответ на все Ваши вопросы (особенно в части Это проблема качественного тестирования и управления качеством.) один — надо пахать.
Учиться.
Потом пахать.
И снова пахать.
И это все — не проблема тестирования. Управление качеством касается всех участников разработки… Вот этого понимания почему-то нет. «Так исторически сложилось»
Не соглашусь с Вами и в том, что недостаточно форумов и прочего. Вот этого как раз навалом. Разговоров и размышлений навалом. Дела мало, факт.
И тогда у меня на правах опытного специалиста вопрос к Вам.
Кто если не Вы?)
Только личным примером и личным участием, уж поверьте.
Учиться.
Потом пахать.
И снова пахать.
И это все — не проблема тестирования. Управление качеством касается всех участников разработки… Вот этого понимания почему-то нет. «Так исторически сложилось»
Не соглашусь с Вами и в том, что недостаточно форумов и прочего. Вот этого как раз навалом. Разговоров и размышлений навалом. Дела мало, факт.
И тогда у меня на правах опытного специалиста вопрос к Вам.
Кто если не Вы?)
Только личным примером и личным участием, уж поверьте.
И еще вопрос. На какие конкретные вопросы/проблемы вы не смогли найти ответы в qa-net?
Да, безусловно согласен с вашим основным посылом — «Кто если не ты?!»
Наверное я пока что нахожусь на этапе ДО точки невозврата, когда ещё есть эмоции, поиски решений, желание не пилить велосипед заново.
Но скорее всего скоро предстиоит «пахать».
Наверное я пока что нахожусь на этапе ДО точки невозврата, когда ещё есть эмоции, поиски решений, желание не пилить велосипед заново.
Но скорее всего скоро предстиоит «пахать».
Эта разница — менталитет.
Да, нет. Те же люди из Украины, России да откуда угодно, перебирающиеся в сторону Запада довольно легко адаптируются к другим условиям. Видел немало примеров.
Такие вещи, кстати, на Западе тоже не редкость. Говноконтор тоже хватает.
Основная проблема всей отрасли — низкое качество управленческих кадров.
Говоря на пальцах, есть разница между Agile и бардаком, между внедрением процессов и микроменеджментом. Дьявол в деталях.
Поэтому часто начинается «адаптация под местные реалии», разговоры про менталитет и прочее.
Все это — только оправдания собственной некомпетентности руководителей в ИТ.
Вы, в принципе, это и описали. Неумение работать с новичками, которые пришли из других отраслей, нежелание вкладывать в развитие команды, плохая коммуникация с разработчиками и т.п.
Есть раница между людьми, перебравшимися на Запад, и теми, кто старается создать Запад здесь.
Если в первом случае это возможно без особых проблем, ведь человеку ничего не остаётся, кроме как приспособится.
То во втором случае менталитет имеет более сильное влияние.
Управляющие кадры не компетентны по той же причине — они когда-то пришли в отрасль, и двигаемые быстро растущей в мире IT иерархией, а не навыками, были задействованы в управлении новыми специалистами. Что из этого выходит мы видим вокруг.
В целом согласен с Вами.
Если в первом случае это возможно без особых проблем, ведь человеку ничего не остаётся, кроме как приспособится.
То во втором случае менталитет имеет более сильное влияние.
Управляющие кадры не компетентны по той же причине — они когда-то пришли в отрасль, и двигаемые быстро растущей в мире IT иерархией, а не навыками, были задействованы в управлении новыми специалистами. Что из этого выходит мы видим вокруг.
В целом согласен с Вами.
И как влияет менталитет, что за особенности такие, которые мешают?
Этот загадочный «менталитет» — всего лишь следствие большого количества нефте-бабла и слабого контроля за результатами его расходования. В итоге «процессов» как таковых нет, и строить их незачем. Нужен деньгооборот и видимость деятельности. Спрашивать качество с менеджера никто не станет — только функциональность. А для этого хватает программеров и тестеров среднего и даже ниже среднего уровня. Предпосылок требовать качество, а не скорости от подчиненных нет никаких.
Короче в индустрии все хорошо. Деньги пилятся, люди учатся, оставляя тонны ошибок в загибающихся проектах. А выучившись те, кому копошиться в говнокоде надоедает… оставляют посты и комментарии на хабре с непониманием как из этой ситуации выбираться…
Короче в индустрии все хорошо. Деньги пилятся, люди учатся, оставляя тонны ошибок в загибающихся проектах. А выучившись те, кому копошиться в говнокоде надоедает… оставляют посты и комментарии на хабре с непониманием как из этой ситуации выбираться…
Есть парочка форумов, которые слабо поддерживаются или по большей части просто содержат копипасты статей западных авторов. Есть парочка онлайн вебинаров, направленных больше уже на сформированные отдеы тестирования и на повышение квалификации тест-менеджеров.
Есть же разные специальные конференции для тестировщиков, типа SeleniumConf, SeleniumCamp и разделы про тестирование на программистских конференциях.
Верно, конференций и форумов — десятки. Речь о содержательности.
Такие мероприятия чаще всего освещают реальные истории команд или конкретных людей, которые могли бы стать поучительными для других. Или же чисто технические вопросы. Но об управлении качеством начального уровня («сегодня мне сказали, что я QA Lead, что дальше?») делается довольно не много толковых докладов.
Такие мероприятия чаще всего освещают реальные истории команд или конкретных людей, которые могли бы стать поучительными для других. Или же чисто технические вопросы. Но об управлении качеством начального уровня («сегодня мне сказали, что я QA Lead, что дальше?») делается довольно не много толковых докладов.
-
Я начал свою QA деятельность около трёх лет назад, к сожалению за эти три года моими руководителями (Head of QA \ QA Lead) побывали: сотрудник банка — прямиком из 90-ых, учительница английского языка, руководитель службы поддержки.
Вполне ожидаемо что никаких знаний от этих людей я само собой не получил. Некое подтверждение слов автора из собственного опыта.
Вполне ожидаемо что никаких знаний от этих людей я само собой не получил. Некое подтверждение слов автора из собственного опыта.
Отсутствие внятных напутствий сподвигло меня в свое время к усиленному набиванию шишек и обучению. Потому как отсутствие учителей, книг и информации не убивает жажду знаний, наоборот усиливает. Но любая практика требует теоретической подложки, а вот ее как раз можно получить в книгах, статьях или на докладах различных конференций. Последние несколько лет занимаюсь проведением тренингов и чтением открытых и полу-открытых курсов по тестированию, но не потому что много знаю, а как раз наоборот, чтобы узнать еще больше. Ведь не даром говорят, что если хочешь что-то узнать, то стоит начать это преподавать;) И когда делишься с кем-то знаниями, то структурируешь собственные мысли, заполняешь белые пятна, фиксируешь знакомое и очерчиваешь новые горизонты.
ps: доклада на тему «начинающему qa lead'у посвящается...» и правда не вспомню с лёту, рекомендую подать заявку и выступить на близлежащей конференции SQADays, уверен, доклад найдет своего слушателя;)
ps: доклада на тему «начинающему qa lead'у посвящается...» и правда не вспомню с лёту, рекомендую подать заявку и выступить на близлежащей конференции SQADays, уверен, доклад найдет своего слушателя;)
Это очень круто, что в подобной затруднительной ситуации вы поступили именно так. Опыт и шишки, но только вперёд.
По поводу идеи о создании доклада для начинающих qa-lead — я уже думал об этом. Но меня остановило отсутсвие практического ответа по этой теме, совета как быть, в завершении доклада. Сейчас у меня есть только мысли, налюдения, эмоции. Но у меня нет решения.
По поводу идеи о создании доклада для начинающих qa-lead — я уже думал об этом. Но меня остановило отсутсвие практического ответа по этой теме, совета как быть, в завершении доклада. Сейчас у меня есть только мысли, налюдения, эмоции. Но у меня нет решения.
Дык может как раз работа над докладом и даст ответы на поставленные вопросы?:) В свое время шуточный вопрос «Почему нет доклада с темой „Я- джуниор. Почему я туплю?“ привел к тому, что Миша Янчиков сделал весьма познавательный и интересный доклад для московского клуба тестировщиков:) Ведь как раз через систематизацию собственных знаний в вопросах управления тестирования, есть шанс заполнить белые пятна;)
Работаю в QA два с половиной года. За это время сменил три компании
Ответ на все вопросы о квалификации.
А какая в стране разница зарплат QA с разработчиками?
Очень зависит от специфики проектов.
Но в среднем(в ОЧЕНЬ среднем) зарплата QA составляет 2/3 зарплаты разработчика.
Но в среднем(в ОЧЕНЬ среднем) зарплата QA составляет 2/3 зарплаты разработчика.
Мне кажется это одна из причин. На мой взгляд хороший тестировщик должен уметь не меньше чем программист, а треть зарплаты — это существенная сумма, вот и уходят в программисты когда освоятся.
Тут не полностью согласен. Проблемы ухода в программисты, на сколько мне удалось пронаблюдать, нет.
Так как порог входа в программирование существенно отличается от порога для тестировщика. И факт этого отличия ещё раз подчёркивает то, что коэффициент некомпетентности уже на входе в сферу очень высок — тестированию не учат углублённо. А пороги к Dev и QA растут пропорционально развитию отрасли в целом.
И даже если человек уже «здесь», то уровень знаний, необходимый для перехода может отпугнуть.
Вообще этот вопрос не менее интересный. Нужно будет когда-нибудь порассуждать.
Так как порог входа в программирование существенно отличается от порога для тестировщика. И факт этого отличия ещё раз подчёркивает то, что коэффициент некомпетентности уже на входе в сферу очень высок — тестированию не учат углублённо. А пороги к Dev и QA растут пропорционально развитию отрасли в целом.
И даже если человек уже «здесь», то уровень знаний, необходимый для перехода может отпугнуть.
Вообще этот вопрос не менее интересный. Нужно будет когда-нибудь порассуждать.
«но у нас они просто не работают»
Скажу по секрету, но эти подходы в западных компаниях работают примерно с такой же долей успеха :)
Одна из самых важных вещей, которую опускают авторы книг «как сделать хорошо и правильно», что это требует значительных усилий для внедрения и адаптации.
И поэтому нет проблемы менталитета, в данном понимании. Есть проблема переизбытка различных «но», которые не дают взять и начать делать.
Пару раз в комментариях у вас проскакивал вопрос, что делать начинающему QA-lead'у.
Берете самую большую проблему и начинаете ее решать. Хочется теории? Берете книжки по управлению командой и те же пресловутые книжки по тестированию. И методично начинаете набивать шишки.
И я бы посоветовал больше не искать доклады и выступления «сегодня мне сказали, что я QA Lead, что дальше?». В них вы найдете какие методики сработали, но вряд ли найдете ответы о самом процессе поиска.
В ожидании серебряной пули вы упустите шанс действовать.
Ну и повысить средний уровень в отрасли можно не только подтягивая джуниоров, но и самому становясь лучше. Работать над собой гораздо эффективнее нежели бороться с призрачным легионом «свитчеров».
Скажу по секрету, но эти подходы в западных компаниях работают примерно с такой же долей успеха :)
Одна из самых важных вещей, которую опускают авторы книг «как сделать хорошо и правильно», что это требует значительных усилий для внедрения и адаптации.
И поэтому нет проблемы менталитета, в данном понимании. Есть проблема переизбытка различных «но», которые не дают взять и начать делать.
Пару раз в комментариях у вас проскакивал вопрос, что делать начинающему QA-lead'у.
Берете самую большую проблему и начинаете ее решать. Хочется теории? Берете книжки по управлению командой и те же пресловутые книжки по тестированию. И методично начинаете набивать шишки.
И я бы посоветовал больше не искать доклады и выступления «сегодня мне сказали, что я QA Lead, что дальше?». В них вы найдете какие методики сработали, но вряд ли найдете ответы о самом процессе поиска.
В ожидании серебряной пули вы упустите шанс действовать.
Ну и повысить средний уровень в отрасли можно не только подтягивая джуниоров, но и самому становясь лучше. Работать над собой гораздо эффективнее нежели бороться с призрачным легионом «свитчеров».
Работать над собой гораздо эффективнее нежели бороться с призрачным легионом «свитчеров».
Отсутствие практического умозаключения в моей публикации оставило место для вывода о том, что я намерен с ними бороться. Я ожидал этого.
На самом деле ни да, ни нет — это просто наблюдения. Но не суть.
Ну и повысить средний уровень в отрасли можно не только подтягивая джуниоров, но и самому становясь лучше.
А вот это суть. Всеми конечностями за.
«Хочешь изменить мир начни с себя.»
В них вы найдете какие методики сработали, но вряд ли найдете ответы о самом процессе поиска.
Да. «Принцип Выживших». Согласен.
В целом спасибо за полезный комментарий. Вы заставили меня ещё раз задуматься о некоторых вещах.
Без обид, но тут одна вода. Никакой конкретики. Затрагивается идея что нужна некая теория и все. При желании за два года работы в QA можно было бы выработать хотя бы наиболее общие правила. Для тестирования создано множество инструментов, хотя они и требуют программирования (если речь идет о тестировании ПО). В других областях есть госты, от которых можно отталкиваться. Как-то не серьезно все ваши доводы выглядят и не содержат какой-то новизны. Да в QA очень часто берут просто чтоб по кнопочкам тыкал… Ну и?
При желании за два года работы в QA можно было бы выработать хотя бы наиболее общие правила. Для тестирования создано множество инструментов, хотя они и требуют программирования (если речь идет о тестировании ПО).
Всё было бы именно так, если бы, как я и описал в этой статье, человек не приходил в сферу некомпетентным. Вы что, думаете люди приходят и начинают сразу налаживать процесс, соблюдать ГОСТы и использовать общепринятые подходы?
...:)
За этим нужно следить, направлять, наблюдать, контролировать. А это подразумевает процесс, или курирование.
Компании, имеющие это у себя, под эту статью не попадают.
Суть в том, что нужна не только теория(хотя и она тоже). Нужен источник опыта или люди, способные делиться навыками. Но из-за общей низкоквалифицированности сферы, это сделать могут еденицы.
Общие правила, желание следовать им, и инструменты в помощь. В чём проблема-то?
В компетенциии.
Это некий цикл. Человек приходит в сферу. Мало кто может «поставить» ему грамотный с точки зрения QA рабочий процесс.
Даже если до трудоустройста были пройдены хорошие курсы, прочитаны умные книги и изучены семинары, ему приходится получать опыт под низкоквалифицированным вниманием или вообще в отсутствие такового.
Следовательно, если он и дойдёт до необходимости придумать себе «велосипед», то только если у него по какой-то причине будет на это мотивация.
Далее «велосипед» начинает придумываться. Сначала поиск готовых решений, затем людей, которые готовых поделиться опытом, далее ошибки, эксперименты, и т.д. И в результате велик шанс, что он сам станет некомпетентным специалистом, курирующим следующее поколение.
В отсутствие поддержки более опытных товарищей это долго и пОлно уже совершённых кем-то ошибок.
Зачастую(нет, даже так — ЗАЧАСТУЮ) процесс QA касается не только команды Тестирования или конкретного человека. Это вопрос уровня процесса разработки ПО в целом, развитом в той или иной компании.
Как очень удачно кто-то выразился в одном из комментариев на эту тему — «Качество ПО? Так до этого нужно ещё дорасти...»
Потому можно говорить, что существование хорошего процесса QA или хотя бы условий для его образования- это вопрос компетенции не только самих Тестировщиков, а IT отрасли в целом. В статье же я упоминал только QA, так как я в этом варюсь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
QA в наше время. «Принцип Свитчера» или почему отрасли критически не хватает компетенции