Alexej Simakov

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

И нe смотрите на конкурренцию, смотрите на свои интересы. Нужно заходить с сильной позиции. Люблю тестировать, дотошный, целеустремленный, упорный, люблю технологии, быстро учусь, и т.п по списку. Если им такой не нужен то они себя лишают хорошего сотрудника или сотрудника на вырост. Так им и надо. Следующий.

Второй вопрос:
Может так случиться что применения всему спектру навыков на проекте не найдется. Так что сильно заморачиваться изучением чего-то сильно отстоящего от мейнстрима вероятно не стоит. Но ознакомиться на уровне чтобы понимать о чем и зачем это - стоит. И чем шире спектр осведомленности, тем лучше. Меня например спрашивали на собеседовании, знаю ли я JMeter, сказал знаком, знаю зачем он, пользоваться не приходилось, если надо научусь. И мне много-много чем не приходилось пользоваться о чем я знаю. И это нормально. Сегодня человеку умственного труда важно научиться учиться. И быстро адаптировать свои навыки под новые требования. Гибкость бьет всё. Гибкий кадр это джокер-карта в руках проект-менеджера.

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

Что касается перехода в менеджеры, у меня был момент когда мне предложили перекинуться в разработчики либо пойти в тест-менеджеры. Но я понимал что из крепкого тестировщика-автоматизатора превращаться в нуба разработчика не комильфо. А тест-менеджер, это куча отчетности, а тестировать будут другие. А мне нравится тестировать. Поэтому не пошел ни туда ни туда. А остался дальше тестировщиком-автоматизатором. И оказалось что это дерево растет пока растешь ты.
--
Надеюсь попал своими ответами в ваши вопросы хотя бы на 7/10 :)
Спрашивайте еще, пишите в личку если что, я на хабре есть, а может еще в моих старых комментариях чего-то найдете полезного.

Сначала нужно понять какую информацию мы пытаемся получить от теста, на какой вопрос он должен отвечать. Потом решаем необходимые границы охвата. Будет это приемочный / end-to-end тест, на работающем экземпляре приложения, либо это будет "сухой" юнит или интеграционный тест. Затем думаем как такой тест можно реализовать.

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

Когда ход действий ясен, приступаем к исследованию доступных подсказок. Тут все как обычно.
Первое - смотрим как устроены остальные тесты на проекте, может там будет подсказка.
Второе - смотрим раздел о тестировании той библиотеки или фреймворка который используется.
Третье - беззастенчиво пользуемся опытом других людей с помощью поисковой машины. Думаю по запросу "Laravel API Testing" много чего можно будет найти. Или по запросу "PHP Mock Server"

Баги в готовом функционале называются регрессом, соответственно нужно регрессионное тестирование. А какие слои приложения при этом нужно проверять - ну это от архитектуры приложения зависит. Любой слой может сломаться, после внесения изменений, значит по уму надо все слои проверять на регресс. Но на это жизни не хватит. Значит нужно сконцентрироваться для начала на ключевых самых жизненно важных проверках. Да, все функции жизненно важные, но например если корень апишки не отвечает то это суровее чем если не отвечает какой-то один ресурс. Раскидайте по рискам, и по этой иерархии покрывайте. Риск это насколько огромным будет WTF у пользователя если эта штука отвалится.

Там вкладка History есть. Не оно?

А если эту статистику нужно отдельно как-то выводить, то парсить джейсоны из которых все эти данные собственно в аллюре и отрисовываются.

Богдан Кирий Конечно в "кустарной" мастерской вряд ли будут процессы по учебнику или какие-нибудть стандарты. Они им попросту не нужны. Поэтому пользы от такого опыта для применения в условиях средней или крупной компании ну не чересчур много. Например, полностью отсутствует процесс отчетности. Он там и не нужен, отчитываться не перед кем, кроме своей совести. Интересно вот, пытались ли вы привнести что-то в тестирование чтобы его улучшить. Ведь, как гвоорится "плох тот солдат который не мечтает стать генералом". Может пытались автоматизировать рутину или что-то в этом роде?

Кстати, намедни по Хабру пролетало"FunCorp ищет QA-инженеров: пройди интервью и получ..." - срок еще не вышел, до 3 мая. Дерзайте, попытайте силы на тестовом задании.

брали людей из других команд на пару дней дабы быстро-быстро прогнать функционал что бы не сфейлиться на релизе.

Исходя из этого могу предположить, что тестировали функционал через исследовательское тестирование по методу черной коробки. Значит вам нужно именно end-to-end тестирование.
Раз проект для веба и без дополнительных трат, то очевидный ответ - Selenium. Про него написано-переписано и на конференциях рассказано тоннами. Selenium поддерживает несколько языков Java, C#, Ruby, Python. Самый низкий порог вхождения у Python. Почитать/посмотреть про page object pattern и вперед.
Мне тут как-то на глаза попадался вполне достойный и даже бесплатный курс "Автоматизация тестирования с помощью Selenium и Python".
На будущее, для диагноза затруднений возникающих в процессе внедрения автоматизации и нахождения возможных путей выхода из них на макро и микро уровне могу посоветовать этот ресурс - testautomationpatterns.org - одна из его создателей небезызвестная Dorothy Graham.

airtest, pywinauto, pywin32, sikulix, Winium, WinAppDriver

Вообще не понимаю зачем брать инструмент для нагрузочного тестирования, когда нужно просто автоматизировать взаимодействие с веб страницей. Не приходилось им пользоваться, так что по самому инструменту ничем не помогу.
Сам принцип довольно простой.
Скрипт берет html страницы и выявляет в нем ней нужные элементы. A потом производит нужное действие в зависимости от того какие элементы нашлись. Если это input type=text - вводит в него значение "test", если это input type=radio то выбирает тот в котором значение самое длинное. Для парсинга html есть там всякиe библиотеки например beautifulsoup.

https://github.com/replit однако как это все собрать у себя на машине - понятия не имею.

У вас уже есть сформированый тезис (непонятно откуда взявшийся), теперь вы хотите найти ему подтверждение на основе эмпирических данных? Это халтура, если честно, так научную работу не делают. Но название можно и переделать, а вот сама тема сложная, я бы даже сказал бесперспективная. Давайте разбираться.

"Повышение экономической эффективности ПО" - эксплуатации или производства? Или того и другого? Что вы понимаете под эффективностью? Денежные затраты на производство? Трудозатраты? Можно сделать никому не нужное ПО которое будет очень качественным, но его польза будет равна нулю. Можно напичкать программу никому не нужными функциями и сделать их очень качественно. А можно сделать уникальный продукт, который будет пользоваться огромным спросом, не особо заморачиваясь о его качестве, и потом допиливать его по ходу распространения. Как тут будут обстоять дела с эффективностью? Сколько ПО выпускается в виде альфы или беты на рынок? Как у них дела с эффективностью? Вроде они на тестирование тратят меньше. Как это все посчитать?

Да есть исследования (например The Economics of Unit Testing / M.Ellims J.Bridges & D.Ince), на scholar.google.com можно найти еще больше, там приводят кумулятивные данные нескольких фирм, сравнивают количество строк кода, количество дефектов найденное этими тестами. Но на вопрос об экономическом влиянии тестирования они не отвечают. В статье вообще денежными суммами не оперируют.

Я вам так скажу, невозможно оценить пользу качества, цена качества вариируется от индивидуума к индивидууму. И критерии качества также вариируются. Оценка программного продукта конечным пользователем может оказаться очень разной. А то что продукт выпустили в полном соответствии со спецификацией и это доказано машинными проверками - ну и что? Это никому не интересно если этот продукт оказался невостребованным.

Единственный подход к этой теме, если хотите связать это как-то с деньгами - это смотреть на издержки в связи с дефектами. А о таких жирных дефектах которые попали в газеты - масса статей. Только и тут по большому счету тупик - доказать безошибочность нетривиальной программы невозможно. Это следствие теоремы Райса. Т.е затраты на тестирование могут стремиться в бесконечность, но не найти ошибку которая погубит весь проект. Ну и как тут считать эффективность? Риски, вероятности, предположения, оценки, домыслы.

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

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

Вообще, чтобы расширить свой горизонт, и начать более широко смотреть на свои возможности, рекомендую на ютубе записи Джеймсa Бах (James Bach). Все без исключения. Ну вот например ("A Context-Driven Approach to Automation in Testing"), для затравки видео с демками. Или вот ("Open Lecture by James Bach on Software Testing") - обзорная лекция, о том что такое тестирование. Я после нее заинтересовался тестированием и стал тестировщиком и вот уже 5 лет как тестировщик.

Я видел одну систему "нового типа", это HipTest, там шаги можно переиспользовать. В классических системах, ты просто пишешь/копипастишь текст. Такие системы не нужны, тогда можно и в ворде все хранить.
Когда описания формализованы и имеют семантику, открываются новые возможности чтобы действительно управлять тестами, а не просто их складывать. Тогда ты можешь например ответить на вопрос, сколько тестов у нас проходят через этот экран. Сколько тестов у нас нажимают на эту кнопку. Я считаю, что смысл такой системы в этом. Давать новые возможности работы с данными. А не просто сделать хранилище текста, с аккаунтами, чтобы можно было распределять тексты и собирать галочки проставленные пользователями (тестировщиками). Или еще какие-то там красивые репорты из этого кроить. Т.е. понятно, что это тоже нужно, но не это главное в системе управления тестами. Не это отличает систему управления тестированием, от системы управления <чем-то другим>. Я считаю, что цифровые системы должны не просто быть компьютерной заменой бумаге, а расширять возможности человека. Позволять ему делать то, что ему раньше было не доступно. Тогда это оправдано. Например электронная книга дает возможность полного поиска по тексту, в то время как книги, в лучшем случае, ограничены предметным указателем.

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

Как у вас дела с архитектурой, если не получается добавлять функции не задев при этом значительную часть всей системы?

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

Во время проверки (тестирования) можно написать на этот сценарий приемочный тест. Так у вас потихоньку появятся автоматизированные тесты.

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

Разработчики тоже должны тестировать. Тот кто пишет фичу Х проверят фичу Y и наоборот. Нельзя давать проверять свою собственную работу. Нужна культура качества и открытой коммуникации - чтобы разработчики не замалчивали замеченые проблемы, а открыто писали на них тикет.

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

это не сразу вскрывается

Это вскрывается при первом выполнении тестов на старом билде, но с новой библиотекой.