Вениамин Белоусов

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

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

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

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

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

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

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

santaatnas в комментариях правильно написал: "что вам мешает выполнить этот кусок кода в try блоке, и в catch блоке поймать необходимый exception и сделать assertEquals по имени класса объекта?"

От себя добавлю, что есть замечательный метод
fail();
Его используйте для участков кода, которые не должны выполниться в тесте.

Ниже пример для тестирования гарантированного эксепшена:

import org.junit.Test;

import static junit.framework.TestCase.assertEquals;
import static junit.framework.TestCase.fail;

public class ExampleTest {

    private void exceptionMethod() throws Exception {
        throw new RuntimeException("test");
    }

    @Test
    public void test() {
        try {
            exceptionMethod();
            fail("Impossible");
        } catch (Exception e) {
            assertEquals("Checks class", RuntimeException.class, e.getClass());
            assertEquals("Checks message", "test", e.getMessage());
        }
    }
}

Получил ошибку - нормально.
Скрыл её от нас - нехорошо.
Как мы тебе поможем?

Если налоговой все и так ясно - просто начислят налог. Иногда пени и штрафы.

Если не все ясно - пришлют по почте уведомление с просьбой явиться к ним и объяснить непонятное. Не явитесь или не сможете убедительно доказать свою точку зрения - начислят по-максимуму.

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

Теоретически налоговая может провести выездную проверку на дому. Например, убедиться, что покупка квартиры у родной тетки - не уход от налогов, а действительно покупка, то есть тетка оттуда съехала, а вы въехали. Постучатся, вежливо попросят. Если их пустите - заглянут и уйдут. Если не пустите - пойдут в суд. Или просто начислят по-максимуму и уже вам придется бегать по судам.

"Менты стучатся в дверь" - это уже при уголовном деле в "особо крупном размере". Например, при Как перевести большую сумму без ИП?

Существует три способа вычисления квадратных корней: с помощью функции sqrt() модуля math, с помощью выражения ** и с помощью встроенной функции pow(). В данном случае я указал их в порядке снижения скорости вычисления. Т.е. быстрее других считает sqrt(), потом **, потом pow(). С другой стороны, отмечу, что для работы с sqrt() необходимо импортировать модуль math, а ** и pow() доступны сразу:

>>> import math
>>> math.sqrt(9)
3.0
>>> 9 ** .5
3.0
>>> pow(9, .5)
3.0