Кому подходит работа QA и есть ли в ней место для творчества

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

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

Мне кажется, что именно тестирование очень сильно пересекается с нашей повседневной жизнью. Многие из нас уже тестировщики. И если вам не скучно проживать свою жизнь, то и работать QA вам будет не скучно.

Когда я решила пойти на курсы QA — друзья и знакомые очень удивились. Меня считают слишком активной, непоседливой, креативной и творческой личностью. Кто такой творческий человек — не знаю, решайте сами, относитесь вы к ним или нет.

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

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

Давай договоримся: я говорю «тестировщик» просто для удобства. Во всей статье я имею ввиду QA.

Чем тестировщик отличается от QA

Мне всегда интересно, как, почему и когда используются разные слова.

Нас называют тестерами, мануальщиками, ручными, мануальными и еще всякими тестировщиками. Куа, и реже QA. Я не обижаюсь ни на какое из них, так как считаю, что название никак не влияет на мой профессионализм.

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

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

Обеспечение качества начинается с самого начала (документация) и не заканчивается никогда.

Тестирование — вариант, когда думать не хочется или не можется, и задача — просто делать работу и получать за нее деньги.

В вакансиях почти всегда ищут QA, хотя есть позиции, на которые нужен просто тестировщик. Так что работу можно найти по вкусу. Главное понять — каков вкус ваш :)

Тестирование в жизни

Начну с того, что хоть и тестирование считается самым быстрым способ попадания в высококонкурентное и высокооплачиваемое IT, для этой работы нужны мозги. Хорошая новость: если они у тебя есть, и ты умеешь использовать их по назначению, то научиться тестировать тебе будет не так уж и сложно. В конце концов, это не rocket science, хотя, как знать, возможно, ты попадешь работать и туда.

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

Так что же я имею в виду? Разберем на одном примере, над которым я размышляла перед сном.

Классы эквивалентности и граничные значения

Представь, что ты едешь по Южному мосту, на котором установлены камеры.

Разрешенная скорость 50+20. При правильной работе камер, а также твоего спидометра, при скорости 69 км в час — штраф тебе не положен, а 70 — уже прилетит. Верно?

Для простоты примера берем за данность, что при 70 км/час — уже положен штраф. В реальности есть еще +3 км на погрешность приборов.

Тут мы зацепили сразу две техники тест-дизайна — классы эквивалентности и граничные значения.

Классы эквивалентности, если говорить простым языком, это данные, которые поделены на группы (классы). В этой группе данные эквивалентны (взаимозаменяемы) по фактору того, как с ними работает система.

Граничные значения — это пересечения классов эквивалентности.

В нашем примере у нас есть два класса эквивалентности 1 — 69 и 70 — 100 (потом штрафы выше и это будет следующим классом эквивалентности). Внутри же этих классов — любое значение одинаково обрабатывается системой. Для класса «1-69» — 2, 10, 39, 42 — будут обрабатываться одинаково — штраф не положен. Для класса «70-100» — что 73, что 85 — тоже будут обрабатываться одинаково — кому-то придется платить. Поэтому для тестирования достаточно взять любое число из класса, чтоб проверить, что все работает корректно.

Граничные значения для пересечения этих двух классов — 69, 70, 71. Это числа на границе, там, где большая вероятность ошибиться.

Откуда может появиться ошибка?

1. Разработчик по-своему понял документацию и решил, что 70 — штрафа быть еще не должно, а только с 71.
2. Разработчик ошибся в коде и вместо того, чтоб взять все числа меньше 70 «< 70» — взял все числа меньше 70 включительно «<= 70».

Так что наша задача сделать три проверки:

1. 69 — проверяем, что штрафа нет.
2. 70 — что штраф есть.
3. 71 — что он тоже прилетает.

И ноль, конечно, ноль, не важно что, ноль, при любой погоде, ноль — проверяем ноль! =)

Таким образом, проезжая под камерами 69 км/час, ты уже тестируешь правильную работоспособность системы (и своего спидометра).

Предугадывание ошибок

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

Хм. Откуда мы знаем, что опоздаем к закрытию? Потому что это основано на нашем опыте. Мы знаем, что в это время пробка не рассосется раньше, чем через час. Стоять нам в ней 30 минут. Магазин закроется через 40 минут. Соответственно, если останавливаться отдохнуть на заправке, то в магазин мы не успеем.

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

Причина / Следствие

Так что же нам делать? Мы можем составить небольшую диаграмму того, какие у нас есть варианты и к каким последствиям они нас приведут.

Вот мы в пробке. Если мы и дальше в ней будем стоять, то мы останемся голодны, но попадем в магазин. Если мы остановимся на заправке, то мы не будем голодны, не будем мучительно стоять в пробке, но не попадем в магазин. Это наша уже пятая использованная техника. Причина — следствие.

Что ж, на данном этапе оставлю тебя принимать решение. Я б заехала на заправку, магазинов много, а я — одна, голодная, и в пробках стоять не люблю. С другой стороны, если целью поездки было попасть в магазин, то может стоит и постоять.

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

Ах да! Что же по поводу творчества?

Если проект сложный, интересный домен и с адекватным менеджментом, то у тебя будет достаточно места для творчества. Тебе может быть интересно ставить себя на место клиентов, и представлять, чтоб они такого странного могли бы сделать, чего ваша система еще не предусмотрела (это скорее тестирование UX и, возможно, секьюрити (спасибо за исправление)). Либо же тебе интересно, где девы могли накосячить, и ты начинаешь потихоньку смотреть в код, слать странные API-запросы и удивляться найденным багам (это скорее Back-end). Возможно, тебе будет интересно понять, как оно все работает под капотом, как пишется код, и двигаться в автоматизацию (AQA), а может и в разработку. Вариантов развития очень много. В конце концов, может тебе как раз и нужен rocket science, и ты будешь за завтраком пить кофе с Илоном Маском.

Статическое тестирование

Кстати, в статье я умышленно допустила небольшую ошибку. Если ты ее заметишь — значит успешно произведено статическое тестирование документации. Это очень важная часть качественного QA.

Помнишь, я упоминала, что разработчик мог неверно понять требования и из-за этого допустить ошибку? Так вот, чтобы такого не было — должно быть тестирование документации, которое и отлавливает разные проблемы, такие как неточность и двусмысленность формулировок.

Как бы там ни было, мой главный совет — первое место работы выбирай очень тщательно. Не по причине «Мне дали оффер! Урааа!». Пускай это займет больше времени, советую в это время учить то, что требуется на разных проектах, но лучше попасть туда, где тебе будет интересно развиваться.

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

Спасибо за внимание

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