testomat.io управление авто тестамиНу сертификация это бред как по мне. У нас в компании есть куча недалеких людей с сертификатом аналитка, но они даже за заказчиком записать нормально не могут, не то что провести анализ бизнес требований 
P.S.: Проблема я бы даже сказал не в этих людях, а в тех кто таких людей принимает.
Согласно современным требованиям тестер должен знать тот же стек(~) на котором работает дев + уметь это тестировать на своих инструментах )
1 лайк
Не уверен связано ли это с местоположением команды (распределена в 5-х странах мира). У нас в команде, QA не комитят (поделитесь опытом зачем и что, не совсем понял), но как правило делают ревью решения. Но не потому что знают код лучше, а просто знают логику продукта и типы использующихся данных лучше девов. И это нормально, т.к. приложение модульное и одна команда понятия не имеет чем занимаются другие, а их больше 15-ти.
А еще некоторые девы не знают как настроить Maven, забыли просто, у них есть интересней задачи. А системный админ вообще не в курсе как на RHEL запустить терминал. Значит я умнее всех их
Я думаю что все таки имелось в виду что “широта” знаний, необходимая QA для выполнения повседневных задач больше чем у девов. Ну а “глубина” несомненно выше у последних.
И вообще пост так хорошо начинался - учиться и еще раз учиться, а перешел в цепляние к словам :(…
Спешу вас разуверить. Девушка друга недавно устроилась в Майкрософт тестировщиком.
В силу того что Миша продвигает эту тему в массы (увидел в фейсбуке и линкедин) удаляю посты своего холивара (либо строки из постов) и оставляю только инфу по теме, советую другим поступить так же
Позвольте и мне вставить свои пять копеек. Тестировщику категорически, просто жизненно необходимо уметь интерпретировать пользовательские нужды, сценарии и возможные недочеты пользовательских сценариев. Исходная точка - это пользовательское начало и эмпатия. Что это дает? правильная формулировка проблемы на обывательском уровне. Промежуточная точка - интерпретация. Здесь очень важно знать, как бизнес требование реализовано. Интерпретировать можно по-разному. Чаще всего для QA-инженера нужно уметь так составить гипотезу\вопрос, чтобы натолкнуть разработчика на минимальное кол-во итераций по решению проблемы. Знание стека технологий это упрощает. Глубина интерпретации может идти до предельной точки, когда разработчику нужно будет скопипастить все то, что есть в тикете. Например: “на кнопках в сайте показывается курсор ввода текста” и “заменить на элементе кнопки атрибут на cursor:pointer”. Как принципиально отличаются такие тестировщики: временем на решение проблемы. Правильная формулировка потом интерпретация задачи в технологическом стеке и интроспекция (единичный случай или закономерность? критичный или пустяковый?) формируют в моем понимании некий уровень QA. и тут каждая фирма решает сама для себя, с каким уровнем QA ей удобнее. Все очень субъективно и в конечном итоге это экономическая задача владельца продуктом - иногда Auto QA не нужны. Иногда нужны только ручные тестировщики.
p.s. Последние полгода я тестирую руками гораздо больше, чем за предыдущие 2 года, где на прошлом месте работы было полно времени самому писать автотесты. И что я понял, так это то, что мануальному тестировщику в целом приходится задаваться куда большими вопросами (и более правильными), чем в основном автоматизатору. И даже больше: если ты auto QA, мануальное тестирование, чем его больше, тем более явно на ум приходит понимание того, что нужно автоматизировать. Auto QA в вакууме, где за тебя выставляют требования - скучная работа. Попытка совладать с регрессией и не стирать до дыр собственные руки при ручном тестировании - до правильного понимания ее автоматизации нужно дорасти.
4 лайка