К вопросу о том, с какого языка программирования начинать тестировщику

Это проблема не только автоматизаторов\тестировщиков. В программировании дела обстоят еще хуже мне кажется. Это просто сейчас время такое. Люди не хотят думать головой, им надо чтобы все магически работало и им платили бабки :slight_smile: IT сейчас в тренде, по этому туда и лезут все кому не лень.
P.S.: Очень часто таких людей держат потому что это чей то сын\зять\сват (спали, бухали вместе и т.п.) либо для массы так сказать, в аутсорс конторах принято набирать людей поболее чтобы для заказчиков показывать мнимую безопасность в случае повышения текучки кадров или различных форс-мажоров.
http://cs6.pikabu.ru/images/previews_comm/2015-05_1/14308382036714.png

2 лайка

Тогда тебе никто вакансии не будет присылать через linkedin :slight_smile:

Где есть такой идеальный мир? Где пишут лендинги в одно рыло?

Что-то вы загнули с этим утверждением.

Вот довольно старый пост, интересно читать там комментарии.

Ну по багам в винде видно что результат конкретно у MS не очень. А так да, есть много контор где нет тестеров, просто уровень программистов должен быть соотвествующий, а это не всегда так просто :slight_smile:

А откуда у вас инфа, что в мелкософте отказываются от тестеров?
Насколько я помню из ранее прочитанного, ту же винду тестируют больше людей, чем кто ее разрабатывают.

Не согласен. На 10 из коробки глючил жестко трей, и дело не в кривости рук, винда ставилась несколько раз на разные ПК. До аниверсари апдейт проблема повторялась стабильно :slight_smile: Но это уже оффтоп.

Да, ставил на свой старый комп, работала она там шустрее 7ки как бы это странно небыло, проблем особых не замечал, но я на винде на работаю, больно очень :grinning:

В вашу поддержку )
http://asolntsev.github.io/ru/2016/08/05/why-programmer-cannot-be-true-tester/

Но я с ним не согласен.

Тестирование всё ещё остается мета наукой. Обьективно о нём спорить нельзя так как к нему нету отбьективных требований, от него нельзя ждать обьективных результатов.
Допустим вы говорите что нашли 30 ошибок, а сколько это - много или мало никто сказать не сможет, так как сколько ошибок всего в программе тоже никто не в состоянии знать.
Тогда вы скажете что это на 10 ошибок больше чем в прошлый раз, но и это не обьективно, так как цена ошибки может быть разной.
Вы скажете что есть 5 критических, но это возвращает нас к вопросу - а не осталось ли более критичных ошибок в программе исходя из первого пункта.

Теперь посмотрим на тестировщика, который ничего не знает об окружении в котором работает, и на программиста. Снова на тестировщика, и снова на программиста. Да, программист на коне

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

1 лайк

Ждал что кто-нибудь вам это напишет, но вы сами справились :slight_smile:

Для меня идеальный QC инженер - аналитик с техническим бекграундом, способный вовремя увидеть и донести проблемы в бизнес логике. Но только работать он должен в команде разработчиков очень высокого уровня… А пока у нас есть команды состоящие на 70 процентов из джунов, которые учатся писать код - без тестирования никуда.

Я все таки считаю, что главное это не баги, а информация о продукте в целом. Именно за это и платят. А чтобы это знать, нужно видеть всю картину, которую зачастую девы не видят и не хотят, т.к. для этого нужно знать весь процесс (чем больше проект, тем дальше от одной любимой технологии) и чего хочет заказчик. Что ему важно сейчас - уменьшить время отклика на 100 мсек, перейдя на новую технологию, или сдать релиз на неделю раньше … В основном девам это не интересно, они хотят писать классный код без багов на технологиях, которыми они смогут хвастаться потом в курилке :slight_smile:

Ну и главное - если это работает, значит на то есть причины :slight_smile:
Может вы и правы, и через 2-3 года девы станут всесильны. Но из моего опыта не в IT - там где нет независимого QC, наступает полный хаос.

P.S. Сорри за много букв… чет не мог не поделиться своей кашей в голове )

В том то и проблемма (а наши джуны ведь даже и не джуны). Заказчик говорит, что нужны тестировщики, HR ничего не знающий о технологиях ищет кандидатов используя массовую рассылку, собеседуют, берут первого ответившего на вопросы которые подсказал гугл. Делается плохой релиз, тестирование сделано плохо. Хорошая отмазка - не хватает тестировщиков. Заказчик говорит надо ещё тестировщики. HR повторяет. Первый задает те же вопросы что слышал сам. Получаем второго. Повторяем. Потом первый уходит в другую компанию задавая те же вопросы там. Через Н лет получаем страну с тестировщиками которые наизусть знают 10 вопросов собеседования. И вот так с этим знанием и ходют из компании в компанию. Повышение получается за выслугу лет. Нету повышения - пойду в другую компанию.

Можно назвать такую болезнь синдромом страны аутсорсера. Как лечить глобально - не знаю. Но если хотя бы половина попытается самообразовываться то проблемма должна решиться.

Согласен в одном - тестировщик должен быть не хуже дева. У нас (в СНГ) - это первый попавшийся человек или вчерашний студент. Это и в умных книжках написано.

Но здесь прозвучала мысль, что тестировщики вовсе не нужны, вот я с этим не согласен в корне.

Как вариант, сделать зарплату меньше слесаря, но чет демпинговать самому не очень хочется :)… Не переживай - рынок сам себя сбалансирует, спрос пропадет и выживут сильнейшие. Говорят что сейчас уже что бы на джуна взяли нужно быть обязательно сертифицированным, знать SQL, Java and Python, Selenium, js, HTML5, CSS… и это на десктоп проект :slight_smile:

Ну сертификация это бред как по мне. У нас в компании есть куча недалеких людей с сертификатом аналитка, но они даже за заказчиком записать нормально не могут, не то что провести анализ бизнес требований :slight_smile:
P.S.: Проблема я бы даже сказал не в этих людях, а в тех кто таких людей принимает.

Согласно современным требованиям тестер должен знать тот же стек(~) на котором работает дев + уметь это тестировать на своих инструментах )

1 лайк

Не уверен связано ли это с местоположением команды (распределена в 5-х странах мира). У нас в команде, QA не комитят (поделитесь опытом зачем и что, не совсем понял), но как правило делают ревью решения. Но не потому что знают код лучше, а просто знают логику продукта и типы использующихся данных лучше девов. И это нормально, т.к. приложение модульное и одна команда понятия не имеет чем занимаются другие, а их больше 15-ти.
А еще некоторые девы не знают как настроить Maven, забыли просто, у них есть интересней задачи. А системный админ вообще не в курсе как на RHEL запустить терминал. Значит я умнее всех их :slight_smile:

Я думаю что все таки имелось в виду что “широта” знаний, необходимая QA для выполнения повседневных задач больше чем у девов. Ну а “глубина” несомненно выше у последних.

И вообще пост так хорошо начинался - учиться и еще раз учиться, а перешел в цепляние к словам :(…

Спешу вас разуверить. Девушка друга недавно устроилась в Майкрософт тестировщиком.

В силу того что Миша продвигает эту тему в массы (увидел в фейсбуке и линкедин) удаляю посты своего холивара (либо строки из постов) и оставляю только инфу по теме, советую другим поступить так же

Позвольте и мне вставить свои пять копеек. Тестировщику категорически, просто жизненно необходимо уметь интерпретировать пользовательские нужды, сценарии и возможные недочеты пользовательских сценариев. Исходная точка - это пользовательское начало и эмпатия. Что это дает? правильная формулировка проблемы на обывательском уровне. Промежуточная точка - интерпретация. Здесь очень важно знать, как бизнес требование реализовано. Интерпретировать можно по-разному. Чаще всего для QA-инженера нужно уметь так составить гипотезу\вопрос, чтобы натолкнуть разработчика на минимальное кол-во итераций по решению проблемы. Знание стека технологий это упрощает. Глубина интерпретации может идти до предельной точки, когда разработчику нужно будет скопипастить все то, что есть в тикете. Например: “на кнопках в сайте показывается курсор ввода текста” и “заменить на элементе кнопки атрибут на cursor:pointer”. Как принципиально отличаются такие тестировщики: временем на решение проблемы. Правильная формулировка потом интерпретация задачи в технологическом стеке и интроспекция (единичный случай или закономерность? критичный или пустяковый?) формируют в моем понимании некий уровень QA. и тут каждая фирма решает сама для себя, с каким уровнем QA ей удобнее. Все очень субъективно и в конечном итоге это экономическая задача владельца продуктом - иногда Auto QA не нужны. Иногда нужны только ручные тестировщики.

p.s. Последние полгода я тестирую руками гораздо больше, чем за предыдущие 2 года, где на прошлом месте работы было полно времени самому писать автотесты. И что я понял, так это то, что мануальному тестировщику в целом приходится задаваться куда большими вопросами (и более правильными), чем в основном автоматизатору. И даже больше: если ты auto QA, мануальное тестирование, чем его больше, тем более явно на ум приходит понимание того, что нужно автоматизировать. Auto QA в вакууме, где за тебя выставляют требования - скучная работа. Попытка совладать с регрессией и не стирать до дыр собственные руки при ручном тестировании - до правильного понимания ее автоматизации нужно дорасти.

4 лайка