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

penetration
security
courses
python
Теги: #<Tag:0x00007fedb9071b20> #<Tag:0x00007fedb90719e0> #<Tag:0x00007fedb90718a0> #<Tag:0x00007fedb9071710>

(rmerkushin) #29

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


(Wojok) #32

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


(Yurij Litvin) #36

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

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

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


(Alexey) #37

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


(Artur Korobeynyk) #38

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


(Евгений Бухгаммер) #39

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

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