azShoo

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

Первое осваивается за неделю просмотром базового курса разработки на какой-нибудь курсере.
Второе - осваивается преимущественно за счет опыта. Базовые вещи легко ищутся в гугле, как например:
qatestingtraining.com/mobile-application-testing-o...
www.softwaretestinghelp.com/beginners-guide-to-mob...
www.mobileqazone.com/video/video

В общем дайте товарищу почитать литературу по архитектуре платформы (на базовом уровне, что бы понимал, как что работает).
Дальше по "азам" тестирования (что бы выделил новые типы событий и тестов, которые надо учитывать).
А дальше в бой.

Jmeter вам в помощь.
Примитивнее некуда.

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

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

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

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

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

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

Вариантов довольно много, на самом деле.
Тут нужен ряд уточняющий вопросов:
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 в целом. :)