Sniper

1) Для каждого регрессионного бага проводить разбор причины, почему пропустили: (не покрыт тестами конкретный кейс, не покрыт тестами участок функционала, тестировался на баг не нашли, и т.д.).
2) Написать качественный исчерпывающий набор регрессионных тест кейсов. В первую очередь по результатам работы из п.1
3) Автоматизировать всё, что можно автоматизировать.

Ответ на подобный вопрос зависит от ответственности ПО. Вообще сценарии составляются на основе требований. Не абстрактных лозунгов, которые обычно пишутся в ТЗ, а требований с однозначными техническими характеристиками. Если проект ответственный, требующий сертификации (ПО для транспорта, например), это вопрос регулируется соответствующими стандартами, по которым производится сертификация. В частности для гражданской авиации, есть документ DO-178 (российский перевод - КТ-178 и менее требовательный аналог ГОСТ-51904), определяющий например, что на основе требований к системе, разрабатываются требования верхнего уровня к ПО (параллельно - к железу), на основе которых создаётся дизайн и требования нижнего уровня, на основе которых уже код, а тестировщики пишут тесты верхнего уровня по требованиям верхнего уровня (проверка функционала всего приложения) и тесты нижнего уровня по требованиям нижнего уровня (юнит тесты). Получается реализация и независимая верификация по общим исходным данным для программиста и тестировщика. Причём здесь не нужно полагаться на опыт и изощрённость тестировщика, он просто достигает цели по явным критериям, это прозрачно и управляемо. Но это очень дорого и долго.
В вашем случае, конечно, процессы разработки будут гораздо проще, но здесь вы должны понимать, что усиление процесса верификации неизбежно потребует затрат. Чудес не бывает, как и тестировщиков которые без документации покрывают как боги. Здесь явно требуется бОльшая формализация, а значит хотя бы ещё один уровень детализации после ТЗ. Насколько детализировать - зависит от того, сколько вы готовы на это потратить. Процент выгребания багов будет соответствующий.

Сколько ваших клиентов имеют данный аппарат?
Сколько денег они вам могут принести (вы можете потерять)?
Много? Бегите в Связной и покупайте эту железку.
Мало? Игнорируйте. Всем мил не будешь.

Cem Kaner, James Bach, Lisa Crispin, Dorothy Graham - книги, видео
Наталья Руколь - видео.
Сам пришел в профессию насмотревшись лекций Джеймса. Он очень крутой гуру.

А чем вам не нравится "Мифический человеко-месяц" ?

В Mac OS X с незапамятных времен есть Dashboard (обычно на клаве на F4 висит), в котором многие из этих виджетов есть.

.md
.rst
.txt
.py
.sh

Это делается через систему оконных сообщений windows на любом языке программирования.
Лучший готовый софт - AutoiIt

Easy to learn BASIC-like syntax
Simulate keystrokes and mouse movements
Manipulate windows and processes
Interact with all standard windows controls
Scripts can be compiled into standalone executables
Create Graphical User Interfaces (GUIs)
COM support
Regular expressions
Directly call external DLL and Windows API functions
Scriptable RunAs functions
Detailed helpfile and large community-based support forums
Compatible with Windows XP SP3 / 2003 SP2 / Vista / 2008 / Windows 7 / 2008 R2 / Windows 8 / 2012 R2
Unicode and x64 support
Digitally signed for peace of mind
Works with Windows User Account Control (UAC)

Вроде на AutoHotKey можно такое реализовать, но я не уверен.

" У каждой из меток есть сотни вариантов. Тысячи комбинаций" - 100^4 - это кол-во комбинаций при 4 метках, то-есть сто миллионов. Уверен, что тебе столько нужно? Ну это так, не совсем по теме.

Для твоих целей созданы целые фреймворки для тестирования. Читай документацию, можешь использовать даже встроенный в Laravel тестер. Боже упаси тебя делать скриншоты и проверять вручную по ним =/

Устройтесь работать.
Это самый правильный способ.

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

знания-знания. тестировщику на деле нужна хорошая память, внимание к деталям, дотошность, несгибаемость, добрый нрав и умение расположить собеседника (общаться придется часто и с разными людьми) и чтобы вырваться вперед - умение видеть работу.
Ладно, знания: Хорошо если есть общее представление об устройстве ПО, это позволит не разбираясь подробно в деталях делать предположения о возможных источниках ошибок.

1. Выяснить, по какой причине невозможно вести нормальный документооборот.
   
2. Заменить ответственного
   
3. Подзрезать зар. плату и заставить переделать. Чем раньше, тем лучше.
   

Для особо одаренных, прошу писать видео. Немое кино исключенно!

Все зависимости о потребностей и возможностей:) Разных тулов видимо-невидимо, интернет полон примеров.
Из платных самоcтоятельных тулов для тестов хорош Test Rail, из бесплатных - самый популярный test link, для чеклистов есть TestPad и русский sitechсo
Если у вас JIRA и хочется внутри нее тесты вести - есть кучка плагинов, например XRay,
Kanoah tests, для чеклистов Structure.Testy
Для документации есть куча разных вики, например twiki или Confluence, опять же все индивидуально :) если выбираете продукт - расскажите что с ним хотите делать, может есть какие-то особенности процесса или команды, технологического стека, будет проще что-то советовать

1. В тестах развилок не может быть! Другими словами Вы всегда должны разбивать тестируемый код на участки. До условия это один участок кода. Ветка кода с if-true(т.е. когда условие true). И ветка кода с if-false(т.е. когда условие ложно). Это три разных тестовых сценария. Вам будет проще для сопровождения.

Тесты должны быть как можно проще!!! Было А, нажали что-то, Должно быть Б. Если не так, то заводим багу!

2. Прежде чем писать тест надо задаться вопросом "А если здесь будет бага, то что это будет значить для бизнеса?" ответ "Клиенты массово будут просить денег обратно" - значит надо писать тест "Клиент купит, но будет недоволен" - нужно думать стоит ли писать тест? Вдруг есть более важные участки кода

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

Из минусов:
Ограниченное развитие.
Недооцененность сферы в СНГ.
Постоянные душевные страдания за качества продукта.

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

В целом, минусов больше чем плюсов, потому что подход "этого небыло в тз" для тестировщика не работает. Нужно всегда думать о том, что остальные что-то упустили, забыли, не подумали.
Нужно всегда помнить, что everything is broken. И всегда быть готовым к тому, что за баги на проде, которые неизбежно будут, шишки полетят именно в вас. :)
Но, в то же время, мне, например, вполне нравится. Если перебороть в умах коллег по IT стереотип, что тестировщик это обезъянка, тупо кликающая куда-попало - будет вообще отлично.