1FinTech

Если Вы спрашиваете правильных разработчиков, то:
1. Они строят и продумывают архитектуру
2. Читают официальную документацию
3. Оптимизируют стыки, логику, алгоритмы
4. Они отвечают на Тостере

Если про всех остальных, то:
1. Они спрашивают на Тостере
2. Пытаются найти исходники или статьи, похожие на их задачу
3. Пытаются найти тех, кому перепродать проект.

со всего
TestNG и Jenkins - инструменты, остальное - теория

систематическое тестирование начинается с наличия детальной спецификации. Если вы работаете по скраму, то при планировании спринта определяется что должно быть протестировано. Я сам в гибкой разработке не участвовал, но осмелюсь предположить по опыту, что на адекватную документацию тестовых сценариев, если тестировщику их придется писать самому, написание автоматизации к ним и отладку этой автоматизации может потребоваться больше времени чем на спринт. Можно попробовать BDD - т.е тест пишется на "естественном" языке и одновременно является и спецификацией, и приемочным тестом, тогда автоматизатору останется только заимплементировать шаги спецификации в коде. От таких спецификаций польза даже в том случае если вы не будете их автоматизировать. Такие сценарии можно проходить и вручную и вам будет ясно все ли сделано. И пользу от такого подхода можно выразить цифрами, например количество сценариев которые не были окончены к концу спринта.

Переходите на TDD (Test-driven development). Сначала пишутся тесты, потом код. Сложно, нудно, но зато приложение сразу перекрыто автоматическими тестами. Остается лишь следить за "полным" покрытием. Этим может и тестировщик заняться: если ему удалось что-то сломать или найти баг в работе приложения, то ищем где что поломалось и дописываем тесты, исправляем.

В принципе все правильно. Берете и делаете. Серебрянной пули нет.

Особенно порадовало, что "все занимаются тестированием"- это правильно. Лишь бы это не было "все - значит никто". И следите за тем, чтобы тестирование давало результат - либо тикет в системе либо фикс. Если баги находят, но просто говорят о них на кухне - это не тестирование. Если баг фиксится сразу, это не значит что коммит-сообщение можно ляпнуть "fixed some strange bug" - он должен содержать описание сценария в котором он происходит и как он влияет на пользователя.

Улучшайте коммит-сообщения. Так чтобы из них можно было собрать патчноут и красиво показать пользователю. А не куча невнятного "внутряка". Формулируйте с позиции пользы, это заставит разработчиков немного больше гордиться проделанной работой, а следовательно добавит им мотивации. Для примера посмотрите как пишут патчноуты передовые представители игровой индустрии.

По автоматизации .. подводные камни такие:
- если автотестов много - их долго выполнять. Начните с небольшого количества 20-50. На них вы обкатаете внедрение и процесс. Не считайте никакие ROI - это бред. Чем считать ROI лучше написать еще один полезный тест.
- архитектуру тестов старайтесь организовать так, чтобы работу по их написанию можно было распараллелить. Например если у Вас Page Object - один может писать компоненты из которых другой может строить сценарии.
- ваш сервис сильно зависит от доступности источников данных - проверяйте доступность источников регулярно, особенно если эти данные вы получаете не по API, а выковыриваете парсером.
- сделать тестовую базу данных - правильно. Автоматизируйте ее свертывание-развертывание через контейнеры.
- по приоритетам автоматизации - точно так же - по "абстрактной" значимости. Хороший источник для идей - багтрекер. Кластеризуйте ошибки по типам и делайте выводы.
- не делайте автоматизацию ради автоматизации - в первую очередь чините продукт, потом тесты.
- не усложняйте тесты ради того чтобы они справлялись с более сложными условиями, упрощайте условия.
- автотесты будут сыпаться по непонятным причинам. Делайте как можно более полезное логгирование. Если тесты выполняются в произвольном порядке - это тоже может быть одной из причин. Любой рандом в тестировании - зло. Учитывайте это при наполнении тестовой базы данных. Желательно, чтобы тестовая база всегда содержала одинаковые данные. Смотря что у Вас за база. Если это только пользователи это одно, а если у вас там хранятся аггрегированные данные, то нужно время от времени пересобирать тестовую базу из свежих источников и проверять работу тестировочных скриптов с ней.
- автоматизацию тестирования можно применять не только для тестирования конечного продукта, можно тестировать миграции схемы базы данных, восстановление базы из бекапа и прочее.

Можете почитать мои ответы по этому хабу, может найдете там еще ответы на какие-то близкие Вам вопросы.
Вот некоторые из моих советов-ответов более-менее общей направленности:

Как добиться независимости в тестах (phpunit)?
Правильное тестирование Javascript?
Как систематически подойти к тестированию в малой компании разработчиков?
С чего начать изучение на должность QA автоматизатора?
Как создать отдел тестирования?
Какие шаги тестирования сайта?

Читайте:
"Lessons Learned in Software Testing" (Kaner, Bach, Pettichord)
"Experiences of Test Automation: Case Studies of Software Test Automation" (Graham, Fewster)
и вот эту вики: TestAutomationPatterns (Кстати, ее инициатор и редактор та же Dorothy Graham. Есть даже пару записей ее лекций на ютубе - советую глянуть)
В ней прям шаблоны. Проблема - решение. Бесценная вещь. Мне в свое время очень помогло, чтобы понять "что не так" и как это лечить.

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

Позитивный тест
Дано: первое слагаемое равно 1
и дано: второе слагаемое равно 3
если мы производим операцию сложения данных чисел
тогдарезультат будет равен 4

Вот несколько примеров негативных тестов

Дано: первое слагаемое равно 1.0
и дано: второе слагаемое равно 3
если: мы производим операцию сложения данных чисел
тогда: будет выведена ошибка несоответствия числовых типов

Дано: мета-файл базы данных отстутствует в папке конфигурации
если: мы запускаем базу данных
тогда: в логе будет записана ошибка о недостающем файле.
и тогда: в консоли будет выведена ошибка о недостающем файле.
если: мы нажмем любую клавишу в консоли
тогда: приложение будет завершено.

В общей форме это выглядит так:
Дано: какая-то фигня
если: я делаю какую-то дичь
и если: я делаю какую-то ерунду
тогда: приложение делает так
и тогда: приложение делает эдак.

Автоматизировать сложнее может быть да, как в примере с записью в журнал ошибок, но не невозможно.

Это нормально, другие делают вид что поняли, кивают, а потом выясняется что они не до конца все поняли. Но тогда уже поздно. Лучше сразу дать понять что ты не до конца понимаешь. Переспросить, переформулировать.
Я вообще по жизни угараю с совещаний - всегда такое впечатление что все все поняли - но оказывается что никто ничего до конца не понял, все просто покивали головами чтобы не казаться дураками. Никогда не надо стесняться спрашивать, хоть это и не всегда удобно. Как говорят японцы: "Спросить — стыдно на минуту, а не знать — стыд на всю жизнь"
Не стесняйтесь тормозить разговор. Типа:
- Можно я перескажу своими словами как я это понял.
- Я хотел бы лучше понять для чего это нужно? Какую проблему это решает?
Особенно если вы новичок никто не будет предьявлять к вам завышенных требований, а кто-то даже наборот отметит тягу к знаниям. Нет ничего хуже когда человек до конца не разбираясь делает вид что он шарит и ему все по-плечу (Эффект Даннига-Крюгера).

Есть еще т.н. проблема XY xyproblem.info - обязательно ознакомьтесь. Я однажды с удивлением выяснил, что страдаю этим синдромом. Не обьясняю контекст задачи, а задаю конкретный вопрос. Это ставит людей в тупик, и в этом нет ничего хорошего. Со временем я приучил себя обьяснять проблему так чтобы мне давали развернутый ответ. Главное не бояться перегрузить людей деталями. Они, эти детали, как правило сильно меняют дело.
Вот шаблон с контекстом:
- Я делаю ... у меня есть ... и для того чтобы сделать ... я использую ... . Но если мне нужно ..., например чтобы .... то этот подход не работает. Как можно сделать лучше?

Также я приучил себя всегда стараться дать пример, на примере всегда быстрее и четче доходит. И сразу есть контекст на котором можно проверить ответ. Не жалейте времени составляя хороший пример. Хороший пример всегда можно горизонтально и вертикально расширить, типа:
- А что если у меня этих ... будет N штук.
- А что если у нас нет прямого доступа к .... Ну, например, оно управляется через ...?
Прямо к примеру так и припишите все дополнительные расширяющие вопросы. Перечитайте еще раз. Уберите ненужное. Что-то отвалится само.

Иногда я использую то, что я называю отложенным мышлением (deferred thinking). В том случае если нет времени на обсуждение. Я задаю вопрос, и просто запоминаю ответ, и обдумываю его потом. А человеку говорю "Спасибо за наводку, я еще раз все прокручу в голове. Если мне еще что-то будет не понятно я приду снова, окей?" Обычно никто не отказывает. Главное предупредить что ты возможно придешь еще раз.

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

Если форма заполнена не полностью, то кнопка отправить должна быть неактивна.
Если форма заполнена невалидными данными и/или неполностью - кнопка "Отправить" должна быть неактивна и неверно заполненые поля должны показывать подсказку.
Для каждого поля нужно проверять, что разные ошибочные варианты ввода в это поле распознаются. Переполнение поля тоже.
Если есть необязательные поля, нужно проверить, что их заполнение, незаполнение или неверное заполнение не влияет на результат. Если есть кнопки переключатели (radio buttons) можно проверить выставляется ли значение по умолчанию если должно или не выставляется если не должно. Бывает что выставляется хотя не должно.

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

Не думайте о количестве тесткейсов, думайте о том, в чем вы хотите убедиться.