Тестирование ПО (Тестировщик, QA инженер)

DenisN89:

top_gun:

Нужно ли автоматищатору писать год кейсы и проходить регрессы мануально?

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

Если писать код без понимания для чего он - иного багов не выловишь)

DenisN89, Например у нас мануальщики пишут тест кейс для себя и ревьювают сценарии для автоматизации, а ТА только пишет код под сценарий, апрувнутый мануальщиками.

DoberMan:

Oleg_Svetoslavovich:

у нас мануальщики пишут тест кейс для себя

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

Все верно и логично. Но с недавнего времени мы проставляем статус для кейса для автоматизации (типо может ли быть автоматизирован, если да - пишем сразу так, чтобы можно было заавтоматизировать, если нет - пишет "нет" и делаем проверки, коорый машина никак не чекнет).

DoberMan:

Oleg_Svetoslavovich:

у нас мануальщики пишут тест кейс для себя

Кейсы ваще непонятные. Бегаешь к мануальщикам по каждому степу.

Здесь рискну утвердить .что это проблема конкретного мануальщика.
Тесты обязаны быть понятны всем - и тестерам, и ньюкамерам, и ТА.

top_gun:

Как работает тестиррвание-пончтие ну вот очень растяжимое. Что под этим подразумевается? Как работает тестирование можно за пару дней узнать у Савина, например. Нужно ли автоматищатору писать год кейсы и проходить регрессы мануально?

Мое мнение - да. Иначе не будет понимания по приоритетам покрытия зон функциональности, какие вещи нужно предусматривать для улучшения покрытия, какие проверки и в каком порядке реализовывать и тп.

Если брать автоматизатора без опыта тестирования - это некая малопонятная сущность, к которой нужно пристегивать отдельного QA который будет ему кейсы вырабатывать, и будут еще вопросики по части кода. Зачем, когда можно нанять обычного автоматизатора, выросшего из ручного, которому только выдать фронт работ, кейсы и последовательность покрытия он и сам запилит. Плюс при необходимости он и ручками потыкает, или по задаче, или для понимания кейса.

DenisN89:

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

Проблема в том, что написание "по готовым кейсам" - дело такое. Основной пул задач по вакансиям сейчас - все теже селениумоводы. А там не нужны никакие особые познания в программировании для реализации описанного по моему в каждом бложике бородатого Page Object. Нанимать отдельного кодописателя под такую задачу - не имеет смысла, так как талантливый новичок с прицелом на разработку на таком надолго не задержится, а днарь - никому не нужен.

oOFlyAngelOo:

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

Это самая большая ошибка, которую можно совершить в автоматизации.
Почти всегда переход из тестировщиков в автоматизаторы осуществляется спустя рукава (сотрудник уже знакомый фирме, чего его дополнительно нагружать заданиями по программированию, да и тратить ресурсы на проверки - затратно/не хочется) - в итоге сотрудник с опытом в несколько лет на открытом рынке не дотягивает даже до джуна после лабы, а гонор по достигнутой в тестировании должности остается и на проекте все идет по наклонной.

DenisN89:

oOFlyAngelOo, в селениусоводы я бы даже не советовал подаваться. Спорное решение с неочевидными плюсами.

А большинство автоматизаторов на рынке, и по вакансиям - это оные и есть. Обычный рассказ на собеседе - пилил гуевые тесты на селене с надстройками(селениды, кукумберы и иже с ними). Что еще пилил? Ну наши тесты умели ходить в базу, и у нас был башскрипт для запуска через дженкинс. Хотя даже в селене впринципе есть куда развернуться (параллелизация, комбинирование с хедлесс драйверами, автогенерация тестов и тп).
Впрочем для старта - вполне сгодится.

Darlok:

Это самая большая ошибка, которую можно совершить в автоматизации.
Почти всегда переход из тестировщиков в автоматизаторы осуществляется спустя рукава (сотрудник уже знакомый фирме, чего его дополнительно нагружать заданиями по программированию, да и тратить ресурсы на проверки - затратно/не хочется) - в итоге сотрудник с опытом в несколько лет на открытом рынке не дотягивает даже до джуна после лабы, а гонор по достигнутой в тестировании должности остается и на проекте все идет по наклонной.

Если человек несколько лет занимается автоматизацией, но не дотягивает до джуна из лабы - тут дело не в процессе перехода. Совсем не в процессе.

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

Ну это не самая большая проблема UI-автоматизации. И, кстати, я очень сильно не согласен с утверждением "если этот ui не меняется, то и регрессию проводить смысла особого нет". Багов при регрессии "неменяющегося" UI-ая находили море, очень навернутое приложение было.

Основное условие для проведения автоматизации - наличие обоснованной уверенности, что она даст профит. Но я, конечно, не про ROI.

zffman:

Ну это не самая большая проблема UI-автоматизации. И, кстати, я очень сильно не согласен с утверждением "если этот ui не меняется, то и регрессию проводить смысла особого нет". Багов при регрессии "неменяющегося" UI-ая находили море, очень навернутое приложение было.

Ну ui тесты цепляются за элементы. Нужно сильно постараться, чтобы не меняя ui и не меняя бизнес логику, поломать что-то. Вопрос к архитектуре скорее. А если ui и бизнес логика меняется, зачем писать на это тесты и постоянно переписывать?

Darlok:

DenisN89:

ui не меняется

Это основное условие проводить автоматизацию

Ок, у нас мобильное или веб приложение. Есть экран, на нем ui элементы и какая-то бизнес логика, которая работает только на стороне клиента. Его сделали, больше не трогают. При тестировании было, допустим, 30 проверок. Нужна тут автоматизация и сколько проверок стоит автоматизировать?

zffman:

Основное условие для проведения автоматизации - наличие обоснованной уверенности, что она даст профит. Но я, конечно, не про ROI.

Roi и есть профит.