Alexej Simakov

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

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

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

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

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

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

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

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

Правильно конечно отлавливать значения, но для быстрого дебаггинга можно сделать и так

caption="<b>" + str(name) + "<b>\n<i>" + str(price) + f"<i>\n<a href='{url}'> Ссылка на сайт</a>",

Т.е. просто при конкатенации ковертировать значения в строковые, и тогда если переменная получит значение None, то оно в строке будет прописано как None. Будет сразу видно откуда пустое значение приходит.

Ищите готовые решения в open source сегменте. Что-то типа Magento.
Вы правильно делаете, что не переоцениваете свои силы. Написать работающую безопасную систему вам никаких ресурсов не хватит и опыта, ведь придется параллельно поддерживать старое решение.
У готовых решений есть пользовательская база, они проверены временем, многие типовые задачи уже были кем-то решены. А магента сейчас вообще под крыло адобе перешла, и они например вкладываются в образовательные ресурсы по платформе. Я вижу одни преимущества. Ну есть еще OpenCart, она вроде более легковесная, их часто сравнивают.
А потом просто ищите как залить туда свои данные, уж импорт данных есть в таких системах, через XLS там, или CSV.

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

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

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

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

Ведь мобильное приложение может, например, пользоваться железом мобильного телефона, как то, захват изображений с камеры и их удобная загрузка "в два касания". Или можно через шеринг передать файл в приложение. Это также и GPS, отслеживание маршрута и передача данных о твоем передвижении на сервер, для улучшения пользовательского опыта. Например, такси может видеть на карте где ты и быстрее и удобнее к тебе подъехать. Это и использование голосовых сервисов, и сервисов искусственного интеллекта, например, захват изображения с камеры распознавание текста на нем и произнесение "вслух". Или ты делаешь приложение для управления бюджетом и с помощью камеры и искусственного интеллекта даешь пользователю удобную возможность просто засканировать всю корзину и продукты автоматически добавятся в список и распределятся по категориям и так далее и тому подобное.

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

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

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

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

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

def calc(op,*args):
  if op=="add":
    return sum(i for i in args)
  elif op=="square":
    return args[0]*args[0]

print calc("add", 3,12,45) #60
print calc("square", 12, 32, 7) # 144

find_element_by_link_text
см. документацию

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

Конечный пользователь платит за продукт, а не за язык на котором он написан. Заказчику в принципе все равно на чем написан продукт, лишь бы было дешево, быстро и качественно. А исполнителю быстрее и дешевле нанять разработчиков на яве чем на мало распространенном языке.

Можно просто задать себе вопрос: "Я готов получать меньше денег за радость работать с новой, более продвинутой технологией?".

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