Это проблема не только автоматизаторов\тестировщиков. В программировании дела обстоят еще хуже мне кажется. Это просто сейчас время такое. Люди не хотят думать головой, им надо чтобы все магически работало и им платили бабки IT сейчас в тренде, по этому туда и лезут все кому не лень.
P.S.: Очень часто таких людей держат потому что это чей то сын\зять\сват (спали, бухали вместе и т.п.) либо для массы так сказать, в аутсорс конторах принято набирать людей поболее чтобы для заказчиков показывать мнимую безопасность в случае повышения текучки кадров или различных форс-мажоров.
http://cs6.pikabu.ru/images/previews_comm/2015-05_1/14308382036714.png
Тогда тебе никто вакансии не будет присылать через linkedin
Где есть такой идеальный мир? Где пишут лендинги в одно рыло?
Что-то вы загнули с этим утверждением.
Вот довольно старый пост, интересно читать там комментарии.
Ну по багам в винде видно что результат конкретно у MS не очень. А так да, есть много контор где нет тестеров, просто уровень программистов должен быть соотвествующий, а это не всегда так просто
А откуда у вас инфа, что в мелкософте отказываются от тестеров?
Насколько я помню из ранее прочитанного, ту же винду тестируют больше людей, чем кто ее разрабатывают.
Не согласен. На 10 из коробки глючил жестко трей, и дело не в кривости рук, винда ставилась несколько раз на разные ПК. До аниверсари апдейт проблема повторялась стабильно Но это уже оффтоп.
Да, ставил на свой старый комп, работала она там шустрее 7ки как бы это странно небыло, проблем особых не замечал, но я на винде на работаю, больно очень
В вашу поддержку )
http://asolntsev.github.io/ru/2016/08/05/why-programmer-cannot-be-true-tester/
Но я с ним не согласен.
Тестирование всё ещё остается мета наукой. Обьективно о нём спорить нельзя так как к нему нету отбьективных требований, от него нельзя ждать обьективных результатов.
Допустим вы говорите что нашли 30 ошибок, а сколько это - много или мало никто сказать не сможет, так как сколько ошибок всего в программе тоже никто не в состоянии знать.
Тогда вы скажете что это на 10 ошибок больше чем в прошлый раз, но и это не обьективно, так как цена ошибки может быть разной.
Вы скажете что есть 5 критических, но это возвращает нас к вопросу - а не осталось ли более критичных ошибок в программе исходя из первого пункта.
Теперь посмотрим на тестировщика, который ничего не знает об окружении в котором работает, и на программиста. Снова на тестировщика, и снова на программиста. Да, программист на коне
по скольку он знает что, как где и с чем взаимодействует.
Я не говорю, что тестировщики не нужны, я говорю что тестировщик должен знать больше программиста об окружении, чтобы приносить явную пользу. А пока что в мирских реалиях получается наоборот, тестировщик просто тыкает куда попало.
Ждал что кто-нибудь вам это напишет, но вы сами справились
Для меня идеальный QC инженер - аналитик с техническим бекграундом, способный вовремя увидеть и донести проблемы в бизнес логике. Но только работать он должен в команде разработчиков очень высокого уровня… А пока у нас есть команды состоящие на 70 процентов из джунов, которые учатся писать код - без тестирования никуда.
Я все таки считаю, что главное это не баги, а информация о продукте в целом. Именно за это и платят. А чтобы это знать, нужно видеть всю картину, которую зачастую девы не видят и не хотят, т.к. для этого нужно знать весь процесс (чем больше проект, тем дальше от одной любимой технологии) и чего хочет заказчик. Что ему важно сейчас - уменьшить время отклика на 100 мсек, перейдя на новую технологию, или сдать релиз на неделю раньше … В основном девам это не интересно, они хотят писать классный код без багов на технологиях, которыми они смогут хвастаться потом в курилке
Ну и главное - если это работает, значит на то есть причины
Может вы и правы, и через 2-3 года девы станут всесильны. Но из моего опыта не в IT - там где нет независимого QC, наступает полный хаос.
P.S. Сорри за много букв… чет не мог не поделиться своей кашей в голове )
В том то и проблемма (а наши джуны ведь даже и не джуны). Заказчик говорит, что нужны тестировщики, HR ничего не знающий о технологиях ищет кандидатов используя массовую рассылку, собеседуют, берут первого ответившего на вопросы которые подсказал гугл. Делается плохой релиз, тестирование сделано плохо. Хорошая отмазка - не хватает тестировщиков. Заказчик говорит надо ещё тестировщики. HR повторяет. Первый задает те же вопросы что слышал сам. Получаем второго. Повторяем. Потом первый уходит в другую компанию задавая те же вопросы там. Через Н лет получаем страну с тестировщиками которые наизусть знают 10 вопросов собеседования. И вот так с этим знанием и ходют из компании в компанию. Повышение получается за выслугу лет. Нету повышения - пойду в другую компанию.
Можно назвать такую болезнь синдромом страны аутсорсера. Как лечить глобально - не знаю. Но если хотя бы половина попытается самообразовываться то проблемма должна решиться.
Согласен в одном - тестировщик должен быть не хуже дева. У нас (в СНГ) - это первый попавшийся человек или вчерашний студент. Это и в умных книжках написано.
Но здесь прозвучала мысль, что тестировщики вовсе не нужны, вот я с этим не согласен в корне.
Как вариант, сделать зарплату меньше слесаря, но чет демпинговать самому не очень хочется :)… Не переживай - рынок сам себя сбалансирует, спрос пропадет и выживут сильнейшие. Говорят что сейчас уже что бы на джуна взяли нужно быть обязательно сертифицированным, знать SQL, Java and Python, Selenium, js, HTML5, CSS… и это на десктоп проект
Ну сертификация это бред как по мне. У нас в компании есть куча недалеких людей с сертификатом аналитка, но они даже за заказчиком записать нормально не могут, не то что провести анализ бизнес требований
P.S.: Проблема я бы даже сказал не в этих людях, а в тех кто таких людей принимает.
Согласно современным требованиям тестер должен знать тот же стек(~) на котором работает дев + уметь это тестировать на своих инструментах )
Не уверен связано ли это с местоположением команды (распределена в 5-х странах мира). У нас в команде, QA не комитят (поделитесь опытом зачем и что, не совсем понял), но как правило делают ревью решения. Но не потому что знают код лучше, а просто знают логику продукта и типы использующихся данных лучше девов. И это нормально, т.к. приложение модульное и одна команда понятия не имеет чем занимаются другие, а их больше 15-ти.
А еще некоторые девы не знают как настроить Maven, забыли просто, у них есть интересней задачи. А системный админ вообще не в курсе как на RHEL запустить терминал. Значит я умнее всех их
Я думаю что все таки имелось в виду что “широта” знаний, необходимая QA для выполнения повседневных задач больше чем у девов. Ну а “глубина” несомненно выше у последних.
И вообще пост так хорошо начинался - учиться и еще раз учиться, а перешел в цепляние к словам :(…
Спешу вас разуверить. Девушка друга недавно устроилась в Майкрософт тестировщиком.
В силу того что Миша продвигает эту тему в массы (увидел в фейсбуке и линкедин) удаляю посты своего холивара (либо строки из постов) и оставляю только инфу по теме, советую другим поступить так же
Позвольте и мне вставить свои пять копеек. Тестировщику категорически, просто жизненно необходимо уметь интерпретировать пользовательские нужды, сценарии и возможные недочеты пользовательских сценариев. Исходная точка - это пользовательское начало и эмпатия. Что это дает? правильная формулировка проблемы на обывательском уровне. Промежуточная точка - интерпретация. Здесь очень важно знать, как бизнес требование реализовано. Интерпретировать можно по-разному. Чаще всего для QA-инженера нужно уметь так составить гипотезу\вопрос, чтобы натолкнуть разработчика на минимальное кол-во итераций по решению проблемы. Знание стека технологий это упрощает. Глубина интерпретации может идти до предельной точки, когда разработчику нужно будет скопипастить все то, что есть в тикете. Например: “на кнопках в сайте показывается курсор ввода текста” и “заменить на элементе кнопки атрибут на cursor:pointer”. Как принципиально отличаются такие тестировщики: временем на решение проблемы. Правильная формулировка потом интерпретация задачи в технологическом стеке и интроспекция (единичный случай или закономерность? критичный или пустяковый?) формируют в моем понимании некий уровень QA. и тут каждая фирма решает сама для себя, с каким уровнем QA ей удобнее. Все очень субъективно и в конечном итоге это экономическая задача владельца продуктом - иногда Auto QA не нужны. Иногда нужны только ручные тестировщики.
p.s. Последние полгода я тестирую руками гораздо больше, чем за предыдущие 2 года, где на прошлом месте работы было полно времени самому писать автотесты. И что я понял, так это то, что мануальному тестировщику в целом приходится задаваться куда большими вопросами (и более правильными), чем в основном автоматизатору. И даже больше: если ты auto QA, мануальное тестирование, чем его больше, тем более явно на ум приходит понимание того, что нужно автоматизировать. Auto QA в вакууме, где за тебя выставляют требования - скучная работа. Попытка совладать с регрессией и не стирать до дыр собственные руки при ручном тестировании - до правильного понимания ее автоматизации нужно дорасти.