А можно побольше раскрыть тему понятий «слабого» и «сильного» комбинирования, а так же «нормального» и «надежного».
Просто тоже пользуюсь PICT, и мне интересна уже более техническая сторона.
В чём принципиальное различие между ними, и чем обуславливается использование тех, или иных сочетаний этих подходов?
При желании за два года работы в QA можно было бы выработать хотя бы наиболее общие правила. Для тестирования создано множество инструментов, хотя они и требуют программирования (если речь идет о тестировании ПО).
Всё было бы именно так, если бы, как я и описал в этой статье, человек не приходил в сферу некомпетентным. Вы что, думаете люди приходят и начинают сразу налаживать процесс, соблюдать ГОСТы и использовать общепринятые подходы?
...:)
За этим нужно следить, направлять, наблюдать, контролировать. А это подразумевает процесс, или курирование.
Компании, имеющие это у себя, под эту статью не попадают.
Суть в том, что нужна не только теория(хотя и она тоже). Нужен источник опыта или люди, способные делиться навыками. Но из-за общей низкоквалифицированности сферы, это сделать могут еденицы.
Общие правила, желание следовать им, и инструменты в помощь. В чём проблема-то?
В компетенциии.
Это некий цикл. Человек приходит в сферу. Мало кто может «поставить» ему грамотный с точки зрения QA рабочий процесс.
Даже если до трудоустройста были пройдены хорошие курсы, прочитаны умные книги и изучены семинары, ему приходится получать опыт под низкоквалифицированным вниманием или вообще в отсутствие такового.
Следовательно, если он и дойдёт до необходимости придумать себе «велосипед», то только если у него по какой-то причине будет на это мотивация.
Далее «велосипед» начинает придумываться. Сначала поиск готовых решений, затем людей, которые готовых поделиться опытом, далее ошибки, эксперименты, и т.д. И в результате велик шанс, что он сам станет некомпетентным специалистом, курирующим следующее поколение.
В отсутствие поддержки более опытных товарищей это долго и пОлно уже совершённых кем-то ошибок.
Зачастую(нет, даже так — ЗАЧАСТУЮ) процесс QA касается не только команды Тестирования или конкретного человека. Это вопрос уровня процесса разработки ПО в целом, развитом в той или иной компании.
Как очень удачно кто-то выразился в одном из комментариев на эту тему — «Качество ПО? Так до этого нужно ещё дорасти...»
Потому можно говорить, что существование хорошего процесса QA или хотя бы условий для его образования- это вопрос компетенции не только самих Тестировщиков, а IT отрасли в целом. В статье же я упоминал только QA, так как я в этом варюсь.
Тут не полностью согласен. Проблемы ухода в программисты, на сколько мне удалось пронаблюдать, нет.
Так как порог входа в программирование существенно отличается от порога для тестировщика. И факт этого отличия ещё раз подчёркивает то, что коэффициент некомпетентности уже на входе в сферу очень высок — тестированию не учат углублённо. А пороги к Dev и QA растут пропорционально развитию отрасли в целом.
И даже если человек уже «здесь», то уровень знаний, необходимый для перехода может отпугнуть.
Вообще этот вопрос не менее интересный. Нужно будет когда-нибудь порассуждать.
Работать над собой гораздо эффективнее нежели бороться с призрачным легионом «свитчеров».
Отсутствие практического умозаключения в моей публикации оставило место для вывода о том, что я намерен с ними бороться. Я ожидал этого.
На самом деле ни да, ни нет — это просто наблюдения. Но не суть.
Ну и повысить средний уровень в отрасли можно не только подтягивая джуниоров, но и самому становясь лучше.
А вот это суть. Всеми конечностями за.
«Хочешь изменить мир начни с себя.»
В них вы найдете какие методики сработали, но вряд ли найдете ответы о самом процессе поиска.
Да. «Принцип Выживших». Согласен.
В целом спасибо за полезный комментарий. Вы заставили меня ещё раз задуматься о некоторых вещах.
Да чесно говоря, эта публикация основана на опыте не только в тех компаниях, где работал я. Этот вопрос мне интересен в целом, и я, интересовался, как дела обстоят в компаниях у друзей или знакомых.
Опыт мой, как мне кажется, был не таким уж краткосрочным(1.4 в одной, 1 в другой, 0.2 в текущей).
Если быть наблюдательным и небезучастным, поддерждивать связи и интересоваться, этого опыта достаточно, чтобы выводы начинали вырисовываться сами.
Это очень круто, что в подобной затруднительной ситуации вы поступили именно так. Опыт и шишки, но только вперёд.
По поводу идеи о создании доклада для начинающих qa-lead — я уже думал об этом. Но меня остановило отсутсвие практического ответа по этой теме, совета как быть, в завершении доклада. Сейчас у меня есть только мысли, налюдения, эмоции. Но у меня нет решения.
Да, безусловно согласен с вашим основным посылом — «Кто если не ты?!»
Наверное я пока что нахожусь на этапе ДО точки невозврата, когда ещё есть эмоции, поиски решений, желание не пилить велосипед заново.
Верно, конференций и форумов — десятки. Речь о содержательности.
Такие мероприятия чаще всего освещают реальные истории команд или конкретных людей, которые могли бы стать поучительными для других. Или же чисто технические вопросы. Но об управлении качеством начального уровня («сегодня мне сказали, что я QA Lead, что дальше?») делается довольно не много толковых докладов.
Есть раница между людьми, перебравшимися на Запад, и теми, кто старается создать Запад здесь.
Если в первом случае это возможно без особых проблем, ведь человеку ничего не остаётся, кроме как приспособится.
То во втором случае менталитет имеет более сильное влияние.
Управляющие кадры не компетентны по той же причине — они когда-то пришли в отрасль, и двигаемые быстро растущей в мире IT иерархией, а не навыками, были задействованы в управлении новыми специалистами. Что из этого выходит мы видим вокруг.
Эта публикация может быть обращением или началом дискуссии. Но она была создана не для осуждения, и старался дать об этом понять.
Я не стремлюсь приписывать себе опыта, которого не имею, или считать себя достаточно опытным для чего бы то ни было.
Сам пришел в отрасль после университета, где получил техническое образование.
Согласен с Вами относительно молодости отрасли. Как результат: большое количество не доведённых до ума стандартов, методов управления и направлений для роста, что усугубляется большими денежными оборотами в сфере.
Так же согалсен и с наличием текучки кадров. Сейчас реалии таковы, что средний срок работы в одной IT компании — менее двух лет. И это считается нормальным.
В свою очередь не согласен с вашим мнением о пользе спустя год или более. Я думаю это было правдой ещё 5-10 лет назад. Но не сейчас.
Не в это время время и не в мире сверхзвуковой скорости развития технологий и методов, успевать за которыми практически не реально.
И этот мир требует даже от новичков умений быстро включиться, стать эффективными и начать приносить результат уже «на вчера».
Просто тоже пользуюсь PICT, и мне интересна уже более техническая сторона.
В чём принципиальное различие между ними, и чем обуславливается использование тех, или иных сочетаний этих подходов?
Всё было бы именно так, если бы, как я и описал в этой статье, человек не приходил в сферу некомпетентным. Вы что, думаете люди приходят и начинают сразу налаживать процесс, соблюдать ГОСТы и использовать общепринятые подходы?
...:)
За этим нужно следить, направлять, наблюдать, контролировать. А это подразумевает процесс, или курирование.
Компании, имеющие это у себя, под эту статью не попадают.
Суть в том, что нужна не только теория(хотя и она тоже). Нужен источник опыта или люди, способные делиться навыками. Но из-за общей низкоквалифицированности сферы, это сделать могут еденицы.
Общие правила, желание следовать им, и инструменты в помощь. В чём проблема-то?
В компетенциии.
Это некий цикл. Человек приходит в сферу. Мало кто может «поставить» ему грамотный с точки зрения QA рабочий процесс.
Даже если до трудоустройста были пройдены хорошие курсы, прочитаны умные книги и изучены семинары, ему приходится получать опыт под низкоквалифицированным вниманием или вообще в отсутствие такового.
Следовательно, если он и дойдёт до необходимости придумать себе «велосипед», то только если у него по какой-то причине будет на это мотивация.
Далее «велосипед» начинает придумываться. Сначала поиск готовых решений, затем людей, которые готовых поделиться опытом, далее ошибки, эксперименты, и т.д. И в результате велик шанс, что он сам станет некомпетентным специалистом, курирующим следующее поколение.
В отсутствие поддержки более опытных товарищей это долго и пОлно уже совершённых кем-то ошибок.
Зачастую(нет, даже так — ЗАЧАСТУЮ) процесс QA касается не только команды Тестирования или конкретного человека. Это вопрос уровня процесса разработки ПО в целом, развитом в той или иной компании.
Как очень удачно кто-то выразился в одном из комментариев на эту тему — «Качество ПО? Так до этого нужно ещё дорасти...»
Потому можно говорить, что существование хорошего процесса QA или хотя бы условий для его образования- это вопрос компетенции не только самих Тестировщиков, а IT отрасли в целом. В статье же я упоминал только QA, так как я в этом варюсь.
Так как порог входа в программирование существенно отличается от порога для тестировщика. И факт этого отличия ещё раз подчёркивает то, что коэффициент некомпетентности уже на входе в сферу очень высок — тестированию не учат углублённо. А пороги к Dev и QA растут пропорционально развитию отрасли в целом.
И даже если человек уже «здесь», то уровень знаний, необходимый для перехода может отпугнуть.
Вообще этот вопрос не менее интересный. Нужно будет когда-нибудь порассуждать.
Есть хаос.
«Наведи прядок»
:(
Плюсую.
Отсутствие практического умозаключения в моей публикации оставило место для вывода о том, что я намерен с ними бороться. Я ожидал этого.
На самом деле ни да, ни нет — это просто наблюдения. Но не суть.
А вот это суть. Всеми конечностями за.
«Хочешь изменить мир начни с себя.»
Да. «Принцип Выживших». Согласен.
В целом спасибо за полезный комментарий. Вы заставили меня ещё раз задуматься о некоторых вещах.
Наверное будет правильнее уточнить:
1.4 года — одна компания
1 год вторая
2 месяца третья.
Я не правильно выразился, сказав «сменил» три компании. Получается сменил две.
Опыт мой, как мне кажется, был не таким уж краткосрочным(1.4 в одной, 1 в другой, 0.2 в текущей).
Если быть наблюдательным и небезучастным, поддерждивать связи и интересоваться, этого опыта достаточно, чтобы выводы начинали вырисовываться сами.
Но в среднем(в ОЧЕНЬ среднем) зарплата QA составляет 2/3 зарплаты разработчика.
По поводу идеи о создании доклада для начинающих qa-lead — я уже думал об этом. Но меня остановило отсутсвие практического ответа по этой теме, совета как быть, в завершении доклада. Сейчас у меня есть только мысли, налюдения, эмоции. Но у меня нет решения.
Наверное я пока что нахожусь на этапе ДО точки невозврата, когда ещё есть эмоции, поиски решений, желание не пилить велосипед заново.
Но скорее всего скоро предстиоит «пахать».
Но у меня в свою очередь есть вопрос к вам.
Действительно ли важно кол-во лет опыта, если имеет значение описанное в статье?
Ведь кроме комментариев о недостаточном опыте, никаких дополнений или рассуждений на счёт описанного в публикации я с вашей стороны не увидел.
Такие мероприятия чаще всего освещают реальные истории команд или конкретных людей, которые могли бы стать поучительными для других. Или же чисто технические вопросы. Но об управлении качеством начального уровня («сегодня мне сказали, что я QA Lead, что дальше?») делается довольно не много толковых докладов.
Если в первом случае это возможно без особых проблем, ведь человеку ничего не остаётся, кроме как приспособится.
То во втором случае менталитет имеет более сильное влияние.
Управляющие кадры не компетентны по той же причине — они когда-то пришли в отрасль, и двигаемые быстро растущей в мире IT иерархией, а не навыками, были задействованы в управлении новыми специалистами. Что из этого выходит мы видим вокруг.
В целом согласен с Вами.
Я не стремлюсь приписывать себе опыта, которого не имею, или считать себя достаточно опытным для чего бы то ни было.
Сам пришел в отрасль после университета, где получил техническое образование.
Так же согалсен и с наличием текучки кадров. Сейчас реалии таковы, что средний срок работы в одной IT компании — менее двух лет. И это считается нормальным.
В свою очередь не согласен с вашим мнением о пользе спустя год или более. Я думаю это было правдой ещё 5-10 лет назад. Но не сейчас.
Не в это время время и не в мире сверхзвуковой скорости развития технологий и методов, успевать за которыми практически не реально.
И этот мир требует даже от новичков умений быстро включиться, стать эффективными и начать приносить результат уже «на вчера».