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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Эту статью я решила написать, чтобы показать свой взгляд на работу 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, полезными штуками и идеями. Не очень часто, весело и качественно.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Не по причине «Мне дали оффер! Урааа!».

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

Оставаться в тестировании можно только по двум причинам. Либо это просто дико прет (это может быть 5% от всех тестировщиков и QA. Это когда ты по жизни постоянно тестируешь все вокруг. Причем не используешь, а именно тестируешь.) либо если уже в айти пробился, но мозгов на девелопмент/девопс не хватает. Все.

Когда уже умрет это позорное «причина-следствие» с древнего протестинга и в качестве примеров хотя бы будет использоваться istqb? Вроде как уже не что-то такое неизвестное.

чтоб они такого странного могли бы сделать, чего ваша система еще не предусмотрела (это скорее тестирование UI)

Это скорей UX и, возможно, секьюрити.

Статья, главным образом, написана для начинающего уровня и тех, кто только думает идти в тестирование. На этом уровне

istqb что-то такое неизвестное
Это скорей UX и, возможно, секьюрити.

Тут абсолютно согласна. В процессе написания не исправила, когда изменила пример.

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

istqb

Сертификат от Оракла ценен, потому что они — производители яп Java, например.
Сертификат от MS ценен, потому что они производят свои решения для бизнеса.
Cisco — та же фигня.
Amazon Web Services — не поверишь.

А что производят сертификаторы istqb, кроме впечатления на хомячков?

Якось на початку кар‘єри проводили мітинги з колєгами по матеріалам istqb, і виявилось там повно неоднозначних тез, які на практиці абсолютно непрацювали, з того часу я зрозуміла, що краще я вивчу якусь, мову чи тулзу яка допоможе в роботі аніж витрачатиму час та гроші на той сертифікат

Если теория не работает, то, возможно, вы не умеете ее готовить:) тем более istqb не какая-то волшебная методология, а скорее набор практик.

Да, действительно, забавно. Или грустно. Тут уже как посмотреть.

Здесь вопрос не столько в ценности istqb, сколько в бестолковом ретранслировании «техник тест дизайна» с протестинга. Но если немного даже отвлечься, то сертификация в первую очередь важна знаниями, которые она дает, а не размером компании, которая за ней стоит. Istqb дает хорошую базу и позволяет говорить с коллегами на одном понятийном языке не переживая что тебя не так поймут. Кроме того их набор знаний практик вполне поможет разобраться в новых направлениях, с которыми ты сталкиваешься впервые и структурировать имеющиеся знания. Но даже «впечатление на хомячков» — это вполне себе профит, если это позволит тебе дороже себя продать. А это позволит, пусть и не каждому заказчику. Но в целом не маст хэв, конечно. Как впрочем и практически любой сертификат. Но повторюсь, что изначальный посыл все же не об этом.

сертификация в первую очередь важна знаниями, которые она дает

Слушай, а что круче: пупырь или тинкл-винкл?

Как-то рекрутер на интервью спросил у manual test engineer о том, как называется его профессия, а тот отвечает: «просто тестировщик», при этом дурашливо болтая ножками.
Рекрутер улыбнулся и дал ему палицей по голове.

Этими болтающимися ножками были сами Эйнштейны!

А Эйнштейн этот просто доктором был, мог и лечить, и физикой заниматься, человек и пароход прямо!
Иваном Федоровичем звали. Только он не Эйнштейн. Моргенштерн его фамилия. Его песни на детских утренниках крутят.

Очень крутые и понятные примеры, думаю начинающим будет особенно полезна статья! А вообще очень классно и просто написано, keep on the same way :)

Спасибо большое за комментарий =) Рада что понравилось!

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

Воу воу, погодите. А что, правда где-то такое бывает, что вот есть весь из себя такой куа который занимается нифига себе тест дизайном, а есть отдельный тестировщик, который с 9 до 6 сидит, кем-то написанные тесткейсы прокликивает?

Не знаю или такое присутствует в одной компании. Но что есть люди, задача которых просто идти по чек листу и отмечать pass/fall — есть, это точно.

Работал много лет в весьма консервативной области, но такого не встречал. Где вы с таким столкнулись, расскажите, очень интересно.

Свого часу зустрічав таких людей, але вони працювали не тестувальниками, а щось типу customer support і це була одна з багатьох їхніх активностей.
Компанія економила на куа відділі, тому й таке вийшло..

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

А потом мы удивляемся почему к тестировщикам относятся с насмешкой

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

То, что большинство QA называют тестировщиками, да и я сама использую это слово в статье — это общепринятая история. И само собой никто не вникает в разделение этих терминов.

«Мне дали оффер! Урааа!!!». Саме так обирав першу роботу. Після курсів майже 3 місяці шукав позицію, тому коли запропонували першу вакансію — одразу ж погодився на неї. Як зараз — не знаю

Тут же многое зависит от целей. Если цель найти как можно быстрее первую работу ради опыта / денег / еще чего-то, то, конечно принимается первый оффер и это отлично.
Я пыталась донести, что важно для себя понимать эти цели.
И если цель быстро развиваться, иметь место для творчества и полета ума, то думать о том, в какую компанию / какой домен хочется. С какими людьми работать и т.д.

Замечтательная статья!

А ф кортинке арфа-орфо-орто- ошипко, кароч.

Вот мы и применили pairwise, и Илон Маск будет за завтраком пить кофе с нами. Он тоже хочет узнать, где четвертая техника, которую мы применили сразу между третьей и пятой.

И к кому обращается автор? То множественное «мы», то одиночественное «ты»...

Спасибо за ошипко. Исправлено со скоростью света.
Ну что ж, значит завтра увидимся и там расскажу к кому и как я обращаюсь =)

Підписатись на коментарі