Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

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

skills
job
testing
Теги: #<Tag:0x00007f7b6429ed20> #<Tag:0x00007f7b6429ebb8> #<Tag:0x00007f7b6429ea78>

(Fuji F) #1

Решил сменить компанию, начал искать работу, предложили 3 вакансии для ароматизатора, но во всех трех были must have навыки мануального тестирования, мануалов на проектах нет и не планируется.

Собственно вопрос как начать “думать”, как мануальный тестировщик, как оценить, что тестировать в первую очередь, как смотреть на продукт ?. Может книга есть именно не по основам тестирования (типа подготовка к сертификации), а именно по “как начать думать как тестировщик”.

К примеру на собесе можно сказать типа -" я начну тестировать основные фичи продукта", но хочется более развернутый ответ.

Если вы уже совмещаете обе области ручное\автомат. тестирование расскажите о своем опыте.
Спасибо.

Нужно ли автоматизатору уметь тестировать ?

  • Да
  • Нет
  • Не знаю

0 участников

Нужно ли прокачивать автоматизатору уже имеющиеся скилы по тестированию ?

  • Да
  • Нет
  • Не знаю

0 участников


(Михаил Братухин) #2

Есть пара книжек + подготовка для всяких сертификатов типа ISTQB FL.
Какой-то необычный путь в тестировании у вас получился. Основ нет, но уже автоматизатор…

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

Причём замечено, что очень часто пытаются все косяки скинуть на последнее звено, т.е. тестировщиков. Типа “почему пропустил баг?”, “почему задерживаете релиз?”, “почему так поздно находите критичные баги и блокеры” и т.д.

У вас какая специфика на проекте? Думать “как мануальные” тестировщики можно диаметрально противоположно в зависимости от проекта и умения требуются зачастую совершенно различные. Ну, и “болячки” и известные проблемы в различных ПО отличаются, например, в вэбе нужно больше внимания уделять одним аспектам, а в десктопе - другим.

Вот тут книги есть и вообще сам сайт содержит много полезной информации:http://software-testing.ru/books и
Какие книги надо бы прочитать “молодым” тестировщикам? либо еще другие сайты и блоги (рус/англ). Еще есть записи со всяких конференций с докладами, тот же SQADays, QAConf, Selenium Camp и т.д.


(Fuji F) #3

это всё забывается если не использовать, насчет теории тестирования, например когда я только устраивался а IT по части мануального тестирования знал больше чем сейчас, потому что готовился к собеседованиям, а сейчас когда работаешь с уже написанными тестами всё забывается.


(Fuji F) #4

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


(Михаил Братухин) #5

То ли я не так прочел, то ли тут взаимоисключающие параграфы:

Если хотите “подмазаться” под собеседование, то хорошо подвешанный язык + немного теории и никто даже и не поймет, что вы почти не работали мануальным тестером. Если же интересна специфика области и хотите в ней развиваться, то тут простых путей не будет. Придется и книжки читать и блоги бывалых, а также форумы типа этого проглядывать, смотреть доклады с конференций/участвовать в них и т.д.

Думать как тестировщик непросто. Самое сложное в его работе - умение заставлять себя перепроверять одну и и туже вещь, даже если уже совсем недавно её проверял.


(ByteSurfer) #6

А почему бы не поискать вакансии без мануального тестирования? Я этот вопрос обычно сразу оговариваю с рекрутёрами - говорю что заинтересован в 100% автоматизации и отсутствии нагрузки ручным тестированием, недостатка в таких вакансиях нет.


(Bolatbek) #7

Ручных требуется больше. А многостаночников - уж тем более.


(Михаил Братухин) #8

Логично. Особенно, если “автоматизаторы” будут только кодить и не хотят в предметную область окунаться (довольно распространенная практика, но мне она кажется ущербной). Ведь для такого автоматизатора какой-то мануальщик должен подготовить ручной сценарий, причем расписать от и до, а потом еще и обратно принять автотест и проверить его на корректность. Итого минимум один ручной на одного автоматизатора выйдет. И это еще не считая проверки ручными новых фич, патчей, поиск багов и т.д. Вот и выходит, что их по определению будет требоваться больше. При этом еще у мануальных отток спецов приличный либо в аналитики, либо в менеджеры, либо в автоматизацию, либо еще куда. Вот и приходится постоянно вести набор. А автоматизация для бизнеса не всегда понятна и далеко не всегда ведет к прибыли. По факту: часто строят автоматизацию непонятно чего и непонятно как, при этом издержки на автотест огромные, а выхлоп не всегда имеется.


(Владислав Иманходжаев) #9

Ушел в автоматизаторы, оставайся там уже… назад возвращаться трудно, а для некоторых практически не возможно xD


(Fuji F) #10

сейчас все больше будет вакансия типа SDET мне кажется, а там придется вспоминать, так или иначе от мануального тестирования не убежишь.


Спор возник касательно функционального тестирования