azShoo

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

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

Первое, что должен сказать, мне кажется вы смотрите немного не в ту сторону.
Если вопрос стоит как "QA не успевает" - вам нужно автоматизировать наиболее ресурсоемкие (с точки зрения тестирования) тест-кейсы, к которым непосредственно верстка относится очень косвенно.

Теперь по инструментам.
Есть автотесты. Например, Selenium. Автотесты штука довольно универсальная и масштабируемая, но к проверке верстки их прикручивать довольно бессмысленно (хотя и можно).
Селениумом, как правило, имеет смысл проверять непосредственно наличие элементов, взаимодействие с ними и их работу.
(Напр. ввел номер телефона -> появилась следующая въюха, но проверять расположение въюхи селениумом - дело не благодарное).
На мой взгляд - это оптимальный вариант, т.к. пройтись по страницам и проверить, что нет "уехавших" или расползшихся элементов - не занимает много времени. Много времени занимают именно функциональные кейсы.

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

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

На почти любом языке можно комфортно писать тесты, фреймворков и библиотек для этого дела навалом.
Например: пайтон - pyunit, py.test, robot framework, selenium
C# - тот же селениум, nunit, тестнг.
Тесты на Javа, как уже говорилось выше, тоже вполне просто пишете.

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

Вопрос из цикла "откуда взять информацию по программированию".
По геймдизайну масса информации в этих ваших интернетах.
В целом, путь к построению баланса примерно таков:
1) Отыграть миллион часов в игры нужного вам жанра. В разные - топовые в своем сегменте, "середнячки", провальные, инди и пр.
Не просто залипать на экран, а вдумчиво разбираться в особенностях игры - куда игровой баланс ведет пользователя, где создаются точки потребности, и все такое прочее.
2) Найти от 3 до 12 тематических порталов, всякие dtf, инди-геймдев и etc.
Почитать мануалы. Да, да. Не вваливаться на борду с тонной вопросов в надежде услышать единый how-to, а въедливо читать мануалы по геймдизайну для новичков, ответы на схожие вопросы, обзоры и прочее.
3) Скачать полгига книг, лекций, обзоров, статей и прочего. Книг по геймдизайну относительно мало, но при умении пользоваться гуглом они находятся очень быстро. Так же обратите внимание на видео-лекции, программы курсов по тематическим специальностям и прочему.
В общем тэг "Game Design" вам в помощь.
4) Проанализировав все написанное создать прототип и прорабатывать детали, отсекая ненужное. 5) Написать более-менее примитивного бота под вашу механику, и запускать игры bot vs bot до бесконечности.
6) Опробовать на себе, коллегах, товарищах.
7) Проанализировать результаты п.5 и п.6, и переделывать пока вас не будет устраивать результат.

Книг по Java масса, зависит от пожеланий, интересных тем и предпочтений к формату текста.
Начиная от o`Reily "Изучаем Java", "Java, полное руководство" (Шилдт) и упомянутой выше Философии.

Можете не привязываться к среде разработки (нетбинс), от любых других IDE он слабо отличается.

Тут, по сути, стоит несколько последовательных задач:
1) Первоначальное наполнение контентом.
Если речь идет о контентном сервисе (напр. блогоферме, вроде жежешечки), то пользователю не интересен "пустой" портал.
Следовательно надо "налить" первоначального контента.
Это можно делать самому, если позволяют ресурсы, либо, что оптимальнее - привлекать сторонних авторов. Сёрфите аналогичные по тематике порталы, ищете интересных вам авторов, связываетесь и предлагаете сотрудничество.
В зависимости от автора, объемов необходимого контента и тематики - расценки будут меняться от минимальных до заоблачных.
Многие площадки злоупотребляют кросс-постами (тянут и ре-постят посты с других источников), но тут стоит понимать, что при отсутствии уникального контента привлечь аудиторию будет сложнее.

2) Когда первоначальный контент сформирован - привлечение первого круга ЦА -> здесь уже идет чистый SMM. В помощь - опять же договоренности с авторами на платные посты, кросс-посты в тематических соц.сетях, всяческая пиарщина. Опять же все зависит от тематики.

3) Удержание и преувеличение аудитории. Когда первая волна аудитории получена - начинается самый ад. Надо удерживать аудиторию и максимально стимулировать её к шарингу с кругом знакомых. Плюс, конечно же, привлечение новых людей по модели из шага 2.
Нужно мониторить показатели и при необходимости стимулировать генерацию контента, запускать холи-вары и прочее.

В целом, этим занимаются целые отделы пиарщиков и SMM-щиков, так что просто так взять и сказать "сделай вот это и все будет ок" - нельзя.

btw, в первую очередь нужно определиться с:
1) Целевой аудиторией. Без понимания типичной целевой аудитории делать социальный проект - заранее провальная идея.
2) Исходя из п.1 определитесь с основными конкурентами за вашу ЦА, заранее выделите популярных авторов и "сердце" данного сообщества. В общем всячески анализируйте конкурентов.
3) Подумайте, реально подумайте, что вы можете предложить своей ЦА. На мой взгляд, рынок блого-платформ сейчас прибывает в убытке. Большинство блоговых платформ было убито либо соц.сетями, либо лидерами отрасли. Что бы пользователи к вам шли - они должны понимать, зачем это им нужно.

А дальше скачиваете гигабайт книжек по тэгам "Продвижение проектов", "SMM" и прочее, выкидываете оттуда 90% воды, вычерпываете 10% полезных мыслей и стараетесь остаться после этого на плаву.

Вариантов довольно много, на самом деле.
Тут нужен ряд уточняющий вопросов:
1) Вам нужно проверять _регулярно_ или единоразово (сдаешь проект - проверил - забыл)?
2) Какие браузеры и разрешения вам реально нужны? Тут надо определить две вещи:
Под какие браузеры вы разрабатываете, и готовы обеспечивать поддержку, и нужно ли это вашим пользователям? Первое определяется исходя из ваших ресурсов, второе - исходя из статистики посещений сайта и прочего.
Поддерживать "ВСЕ БРАУЗЕРЫ" и "ВСЕ РАЗРЕШЕНИЯ!!" - бессмысленный кейс. Вы потратите много времени на поддержку древних браузеров и разрешений, существующих на двух нетбуках в мире, но не получите ничего.
3) Сколько вы готовы тратить времени, сил и денег на подобные тесты?
4) Какая "погрешность" в результатах тестирования вас устроит?

Вариант 1) Виртуалки. Много разных, с разными версиями браузеров, осей и пр.
Разрешения экранов там отлично настраиваются, масштабируется все соответственно.
Плюсы:
- Высокая вероятность воспроизведения багов с реальных устройств.
- Кастомизируемость - все, что нужно сделать, это развернуть N виртуалок, и накачать на них нужные вам версии браузеров.
Минусы:
- Миллиард виртуалок, которые надо создать и актуализировать.
Вариант 2) Специализированные сервисы. Упомянутый выше BrowserStack и прочее.
Аналогичные сервисы есть и для мобильных и MacOS устройств отдельно.
Плюсы:
- Простота - купил, открыл, проверил.
Минусы:
- Низкое соответствие. Часто вместо реальных старых версий используются "эмуляторы" старых версий, которые выдают ложные результаты.
- Далеко не везде можно прописать хосты и прочие радости для доступа к "внутренним" стендам.

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

Вариант 3) Собственный "зоопарк" устройств.
Особенно актуально для мобильных устройств. В большинстве случаев проще завести свой парк устройств, к которым настроить доступ "из вне". Для этого, тоже, кстати, есть готовые решения.
Плюсы:
- Реальное железо = реальная работа этого железа, а не псевдосрабатывания эмуляторов.
- Кастомизируемость - только то, что нужно, и настроенное так, как надо.
Минусы:
- Дорого.
- Необходимо постоянно пополнять "коллекцию" устройств.

Ну, или отдать на откуп индийским аутсорсерам.

Для начала давайте разберемся, что же такое QA? Понятие это довольно абстрактное, и в СНГ применяется зачастую в ином понимании, нежели в краях более отдаленных.
QA - это обеспечение качества продукта, причем, в идеальном случае, на всех этапах разработки.
Самое первое, с чем придется в большинстве случаев столкнуться QA Engineer`у это функциональное тестирование.
Написание тестов по задачам и прохождение этих тестов., прохождение уже написанных, апдейт, заведение багов и прочее. В этом случае QA Engineer = Тестировщик. Для этого самое важное - хорошо работающая голова, умение читать задачи и задавать правильные вопросы: "А что если так? А если этак?".
В зависимости от продукта требуются дополнительные скиллы -> в вебе своя специфика, в мобильных своя, в по - своя, в железе - своя. Ну и соответственно базовое понимание кода, работа с базой данных и прочее - тоже периодически понадобятся.

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

Отдельная часть - автоматизация тестирования. Здесь от компании к компании все по разному, и роль автотестера варьируется от "тестера который научился использовать тестовый фреймворк" до "полноценного разработчика, который автоматизирует то, что ему говорят тестировщики".
Требования отличаются соответственно.

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

Что в итоге?
Мне кажется, что QA-инженер это тестировщик, который вышел в своей работе за рамки тестирования. Который работает над качеством продукта не только в плане "Требования выполнены - к продакшену готовы", а старается делать продукт лучше во всех отношениях, в первую очередь - для бизнеса, во вторую - для пользователя, в третью - для тех, кто этот продукт делает.
Следовательно, я считаю что путь QA лучше всего начинать именно с тестирования (кстати говоря, в России понятия QA и тестирования почти всегда тождественны в умах не-тестировщиков).
Что важно для тестировщика?
Способность и желание разбираться в том, как это [продукт\фича\пр] работает сейчас, и как это должно работать.
Так же стоит приготовиться много говорить "нет, так не пойдет" менеджерам и разработчикам.
Ну и вообще, смириться с тем, что другие стороны процесса очень часто готовы действовать в ущерб качеству.

Что хотят, что бы знал джуниор?
1) представление о процессе разработки. Этапы, когда пора тестировать и все такое.
2) представление о написании тестов: что представляет из себя тест-план, тест-сьют, тест-кейс, тест-степ, Definition of Done, Ожидаемый результат и тд.
3) представление о том, что такое дефект: Severity и Priority дефектов, какие бывают; из чего состоит описание дефекта, и все такое.
4) хотя бы общее представление о тест-дизайне: что такое, зачем нужен, какие есть практики.
5) Базовые навыки SQL - селект, упдейт, работа с несколькими таблицами и все такое.
А ещё хотят, что бы человек умел думать. Будь готов к задачкам на логику (которые туфта и ненужны) и к задачкам типа "Есть окно с кнопкой, посылает запрос: напиши тесткейсы" или "Протестируй карандаш".

Как-то так.
К сожалению, больше рассказал именно о тестировании, чем о QA в целом. :)