KiT Maverik

Если в конторе бардак, то:

1. В ней может не быть описания позиции.
   
2. Требования может составлять некомпетентный человек.
   

Что до требования к ВУЗ’у, то часто эту графу добавляют для галочки - чтобы потом похвастаться клиенту: "вот, такие вот у нас требования, ага!" (вслушайтесь в музыку слов - не выпускники работают, а требования :) ).
Сам такое видел, сам такое делал. Рекомендую просто игнорировать такие странные требования и слать резюмеху несмотря ни на что.

Spira Team от inflectra. Громадная апликуха, может все, а платить нужно за количество одновременно залоганных юзеров.
Дешево и сердито.

Техническое задание: выведи сайт в топ за три дня или умри без воды в переговорке.

ОБМАН! ВЕЗДЕ ОБМАН!
О, друг Горацио, что делать нам с тобою этом мире?

СОВЕТЫ

1. Делегировать интервьюирование.
   
2. Поиск по рекомендациям.
   
3. Испытательный срок с четкими KPI.
   
4. Нанять дорогого профи и пусть он превозмогает.
   
5. Возможно, человек участвовал в проектах с открытым исходным кодом или имеет какой-то демо проект на GitHub.
   

Я правильно понял, у тебя проблема в том, что работы много, а времени мало? И ты думаешь, что смена направления решит эту проблему?
А мне вот наоборот, кажется, что ты пашешь на проекте, где из вас выжимают все соки и ложат (УДАЛИЛ ПОСЛЕ ДОЛГОЙ ВНУТРЕННЕЙ БОРЬБЫ) на ваши перспективы и развитие. Настолько ложат (отвали красная линия - не буду я писать "кладут"), что даже не хотят использовать в серьезном и дорогом направлении специалиста с хорошей стартовой позицией.
Ищи компанию и проект по себе. Пентест это дорогое направление - найдешь правильный проект - тренить будут на ура.

Вообще-то странно, что ты задаешь такие вопросы на ресурсе посвященном IT-технологиям. Я надеюсь ты понимаешь, что предметная область, методики, подходы, стандарты, да и сам объект тестирования слегка различаются. Но, если ты хочешь получить ответ на свой вопрос в контексте тестирования ПО, то вот тебе:

Smoke-test это базовый тест жизнеспособности системы. Если мы включили прибор в розетку и из него не пошел дым, то smoke-test пройден (да, отсюда и название). Соответственно, если данный конкретный пистолет способен выстрелить, то он проходит smoke-test.
Требования к документации обычно описываются в стандартах, но так как твой тестовый объект весьма специфичен, то в данном конкретном примере я буду руководствоваться стандартными для моей индустрии практиками:

• ID: 101
  
• Название: базовое тестирование боевого пистолета "frondEnd-1" #AS1902
  
• Предусловие:
  
  1. В распоряжении имеется: тестовый образец боевого пистолета "frondEnd-1", пистолет 1 патрон .357 калибра, тестовый стенд, смертник 1шт..
     
  2. Тестовый стенд оборудован должным образом и соответствует стандарту безопасности "noWotafak-1313"
     
  3. Тестовый рубеж оборудован должным образом и соответствует стандарту безопасности "bezZevakIOlenej-666"
     
  
  
• Протокол: последовательность шагов для выполнения выстрела в виде нумерованного списка.
  
• Ожидаемый результат: пистолет выстрелил
  
• Фактический результат: записывать уже некому
  
• Постусловие: структура и функциональность пистолета сохранена.
  

Когда бизнес заказывает программный продукт, он преследует определенные цели.
Когда кодер пишет продукт он создает скрипт для удовлетворения этих целей (логику).
Из этого получаем:
Бизнес логика - скрипт выполняющий бизнес цели.

А зачем для тестирования REST-API использовать SOAPUI?
Есть же мегакрутые REST-клиенты вроде POSTMAN!

• WBD4. Команды .end и endAll позволяют завершать сессии.
  
• WBD5. Команда .deleteSession закрывает соединение и завершает текущую сессию.
  

А вообще, насколько я знаю, WebdriverIO после прохождения теста сам автоматом закрывает сессию.

Цитаты великих людей:
Если у вас на проекте бардак и вы решаете заняться автоматизацией, то у вас будет автоматизированный бардак.
Мой друг Леха.

Прочитав описание вашего проекта я пришел к следующим выводам.

1. С процессами у вас беда.
   
2. QA мертво.
   
3. Жизнь дала вам леща за п1 и п2.
   

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

Предлагаю вам следующее:

1. Перестаньте воспринимать тестирование как недоразумение.
   
2. Наймите толкового QA и слушайте его.
   

Услуги аутстаффа для тестирования предоставляются многими компаниями. Можешь поискать здесь: Clutch.

А что, ментор не может посоветовать? Странная ситуация...
------------
По делу. Я использовал Toad. Он мне нравился и с функциональной и с эстетической стороны.
Я не рекомендую тебе учить определенную программу. Она всего лишь дает тебе графический интерфейс (необходимость в котором может и отпасть), а также визуализирует некоторые вещи.
Гораздо эффективнее будет разобраться с принципами работы реляционных баз данных. Качай понимание технологии, с этим тебе помогут адекватные источники. Например вот этот: SQL Database Fundamentals. Я когда-то проходил этот курс и остался очень доволен - работа баз данных и особенности их организации объясняются на высшем уровне.

Это сложное решение, которое принимается на основе анализа множества факторов.
Пример:

• JS. Быстро тестит вебморду; Слабо типизирован - команда должна быть шарящей.
  
• Java. Более универсальна; Строго типизированный язык - у индусов меньше шансов натворить херни.
  

Если же ты пытаешься понять, где больше рынок - выбирай Java.

Я правильно понял, ты хочешь делегировать кому-то генерирование тестовых случаев?
Если так, то я уверен тестирование будет некачественным - ведь ты не будешь контролировать процесс.

Оу мэн, у меня для тебя есть отличный вебинарчик по этому поводу.
Го сюда, тут лежит мой обзор и конспект вебинара.

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

Интересный вопрос. Не менее интересный чем: "А что такого в вашей жизни случилось если вы задаетесь таким вопросом".

• Если вы джун и вам дали "несправедливое" задание, то просто поверьте на слово более взрослому дяде.
  
• Если вы сеньор и до сих пор верите, что "тестирование эт дело лишнее, все тестеры абизяны", то у вас все плохо. Рекомендую почитать литературу о жизненном цикле продукта и прочее подобное.

По сути:

1. ГУЙ это инкремент
   
2. Чтобы сделать инкремент нужно приложить усилия
   
3. Прилагая усилия можно ошибиться
   
4. Тестировать нужно чтобы избежать этих ошибок.