Профессия тестировщик: разбираемся в qa, qc и testing

Что нужно знать, чтобы стать тестировщиком QA?

QA-тестеру полагается:

• свободно читать по-английски;
• уметь работать с баг-трекером JIRA, Redmine, YouTrack или подобными;
• знать язык запросов SQL, чтобы писать запросы в базы данных;
• тому, кто собирается тестировать сайты, необходимо освоить HTML/CSS верстку, JavaScript, jQuery и HTTP, а тому, кому нравится работать с мобильными приложениями — системы Genymotion, VirtualBox и iOS Simulator;
• владеть приемами тест-дизайна;
• знать особенности клиент-серверного взаимодействия.

Это не все, что нужно освоить начинающему тестировщику: для успешного развития в профессии он должен обладать определенными навыками (Soft skills):

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

Из Телеграм-каналов для новичков будут полезными QA_ru (русскоязычный чат тестеров), QA Channel (общая разноплановая информация для QA специалистов) и Серьезный тестировщик (интересные статьи и забавные гифки по теме). Украинские QA специалисты и консультанты ведут каналы automation-remarks.com, BigQueryInsights и CatOps.

«Хамелеон», которого мы создали и приручили

Речь, конечно, пойдет не о харизматичных ящерках, а о нашем собственном инструменте автоматизированного тестирования. Представляем вашему вниманию кейс создания фреймворка «Хамелеон» и рассказ о его функциональности.

Его появлению предшествовало 15 лет практики тестирования в компании IBS AppLine* (лидера российского рынка аутсорсинга услуг тестирования по версии TAdviser за 2018 год на минуточку!). На базе этих знаний и экспертизы мы задались целью ускорить старт проектов, повысить качество тестирования, упростить введение в работу новичков. Решение должно позволить автоматизировать функциональное тестирование веб, мобильных, десктоп-приложений и различных видов API.

В общем, исследовательский центр IBS AppLine Innovation** суммировал весь опыт компании и создал «Хамелеон» — инструмент для автоматизации функционального тестирования. Делался с использованием языка программирования Java и инструментов Cucucmber, Selenium, Appium, Winium, Spring. Этот фреймворк:

• позволяет сэкономить до 30% времени разработки и сопровождения тестов;
• снижает риск ошибок за счет автоматического заполнения параметров этапов теста;
• помогает обучать и привлекать к разработке тестов стажеров, владеющих только базовыми навыками программирования;
• при переходе с проекта на проект дает возможность использовать одну и ту же библиотеку шагов, а также единый подход к написанию тестов;
• может работать с экзотическими компонентами тестируемых систем благодаря удобству подключения дополнительных расширений.

Теперь подробнее о функционале…

Профессия «Тестировщик» от Нетологии

Длительность: 7 месяцев.

Формат: видео-лекции + практика.

• теоретические основы;
• разработка на языке Java;
• Git – система контроля версий;
• автоматизация тестирования;
• защита диплома.

Полная программа обучения: .

Преподаватели: программа разработана А. Долинским — руководителем группы тестирования Альфа-Банк. Менторы — руководители направлений тестирования Mail.ru Group, Bookmate aims и AB Soft.

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

ИнструментыJava, GitHub, Git, Selenium, SQL, JUnit, IntelliJ IDEA, Docker, Akita, Postman, JIRA, Report Portal.

Цена:

• со скидкой – 46 740 рублей;
• рассрочка без первого взноса – от 3 895 рублей/месяц.

Бонусы: налоговый вычет в 13%.

Итоги: диплом как конкурентное преимущество + содействие в поиске работы.

Получить скидку →

Краудтестинговые платформы – “ясли для тестировщика”

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

Что это такое краудтестинговые платформы? Это такие своеобразные биржи фриланса. С одно стороны на них обитают заказчики, которым нужно что-то протестировать. С другой – специалисты по тестированию ПО.

Работа практически на всех краудтестиновых платформах строится по одному принципу. Есть какое-либо вводное обучение. Далее идет вводные тест. Если все хорошо, Вас допускают к реальным проектам. И Вы можете начать прокачивать свой рейтинг, ведь от этого будет зависеть и Ваша “зарплата”.

А “доход” обычно начисляется в английских тугриках. И в принципе он достаточно неплохой.

Но… Важно знать. На большинстве краудтестинговых платформ оплата идет ТОЛЬКО за найденные ошибки! И причем, Вы должны найти эти ошибки раньше других тестировщиков

Если опоздали или не нашли, чтож… Нет ножек-нет мультиков 🙂

Да. Помните. Чем “крупнее” ошибки Вы находите, тем выше Ваше вознаграждение!

Краудтестинговые платформы в основном “буржуинские”. Вот некоторые из них. Часть только на английском (или немецком языках). Часть переведена (не полностью) на русский. Но велика вероятность получения задания на английском языке.

Если Вы работали на одной их них, оцените ниже, какая понравилась больше.

https://test.io/ – одна из старейших платформ краудтестинга

Мне нравится4Не нравится

https://www.testbirds.com/ – есть вариант для русскоязычных пользователей.

Мне нравится4Не нравится1

https://www.passbrains.com/ – еще один сайт для тестирования ПО

Мне нравитсяНе нравится

https://www.globalapptesting.com/ – еще краудтестинговый сайт

Мне нравитсяНе нравится

https://ubertesters.com/ – еще одна (немецкая) платформа для тестирования

Мне нравится1Не нравится

https://testlio.com/ – еще ловите сайтик для тех, кто ищет работу тестировщика ПО без опыта

Мне нравится1Не нравится

https://www.crowdtesting.ru/ – и еще. Это уже на русском языке, что является редкостью в мире тестировочных платформ.

Мне нравится1Не нравится

Про условия работы на этих сервисах лучше сами посмотрите у них. Заодно и с платформами ознакомитесь.

Тестирование методом черного и белого ящика

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

Полнота тестирования

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

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

Когда мы собираем полное собрание сочинений, то у нас нет цели скупить все книги, полностью весь тираж, нам нужно чтобы в нашу коллекцию попало по одной книжке каждого вида.

И вот когда мы собираем с вами эту коллекцию бабочек, мы можем, конечно же, ориентироваться только на раскраску крыльев

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

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

И вот это как раз и есть разница между тестированием методом черного ящика и тестированием методом белого ящика.

При тестировании методом черного ящика мы не видим, что внутри ящика, мы не принимаем во внимание внутреннее устройство программы.

При тестировании методом белого ящика, или правильнее говорить, наверное, «прозрачного ящика», мы смотрим, как программа устроена внутри, и эту информацию используем при выполнении и особенно при проектировании тестов.

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

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

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

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

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

Когда вам нужен QA?

В этой части статьи мы опишем, что и когда делают QA. Этапы, описанные ниже, являются общими (и обобщёнными) частями цикла тестирования программного обеспечения (software testing life cycle, STLC).

Сбор требований

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

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

1. Анализ и принятие решения о том, совместимы ли между собой требования, и могут ли они быть реализованы в рамках одной системы.
2. Оценка того, какие решения будут работать, а какие — нет.
3. Планирование необходимых методов тестирования (подробнее об этом ниже).

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

До прохождения валидации продукт может и не дойти до потребителя, даже если он отлично сделан с технической точки зрения. Также на этом этапе проверяется, принесёт ли продукт пользу клиенту. Иначе зачем вообще этим заниматься?

Планирование тестирования

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

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

Разработка тестов

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

Выполнение тестов

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

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

Отчёт о результатах

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

Что такое цикл тестирования? Это частота, с которой мы проводим эти пять этапов тестирования.

Роль 1: Качественник

Наша цель — выпустить качественный продукт, поэтому QA специалист принимает участие на каждом этапе жизненного цикла продукта:

1. Проверяем функционал на соответствие техническим и бизнес-требованиям, чтобы продукт решал определенные бизнес-задачи;
2. Выявляем архитектурные несоответствия: что можно реализовать, а что нереализуемо. Сразу обсуждаем с разработчиками, как будем внедрять идеи из технического задания;
3. Составляем тестовую документацию, в которой разберется новый член команды;
4. Информируем всех заинтересованных о состоянии продукта и сроках релиза;
5. Организуем демонстрации продукта.

Итак, мы поняли, что, кроме недоделанного продукта, на проекте нет ничего…
Я начала с анализа и обновления устаревшей документации, которая не соответствовала текущим требованиям. Когда наша команда выросла, документация помогла новым сотрудникам включаться в проект быстрее.
После этого я перешла к тестовой документации, покрыла тест-кейсами весь функционал. Тест-кейсы сэкономили мне время на тестирование: то, что раньше проверяли неделю, мы делали за пару дней.

Международный образовательный центр QA Academy

Курс «Основы тестирования ПО» рассчитан на быстрое погружение в профессию. Программа курса содержит всю необходимую для новичка теорию, а также большое количество практического материала и включает обучение работе с основными инструментами тестировщика. Все преподаватели курса — специалисты компании a1qa с большим опытом в тестировании. Пройдя двухмесячное обучение, выпускники курса получают достаточно знаний и навыков, чтобы начать работать на позиции Junior Tester в IT-компании. Студенты, показавшие лучшие результаты, будут рекомендованы на стажировку с дальнейшим трудоустройством в компании-партнеры QA Academy.

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

Участники приобретают знания и навыки, необходимые для начала работы в тестировании. Для закрепления материала на курсе предусмотрено 5 практических заданий, по каждому из которых тренер предоставляет подробную обратную связь.

Знания и умения

Что нужно знать будущему QA-инженеру для успешной работы? Прежде всего ему понадобится теория. Кандидат на эту должность может подробно рассказать:

• что собой представляет тестирование ПО и зачем его применяют;
• о существующих разновидностях тестирования;
• о баге и его жизненном цикле;
• о документации, которая заполняется в процессе выполнения тестов.

QA-инженер несет ответственность за оптимизацию процесса разработки, поэтому ему необходимы некоторые умения и навыки, которыми обладают другие члены команды. Он должен быть немного:

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

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

Профессия «Тестировщик» от Skillbox

Длительность: 80 учебных часов.

Формат: онлайн-уроки + практические задания.

Преподаватели: Руководитель направления QA в Samsung NEXT, главный методист технического направления Skillbox, профессиональные практикующие специалисты и сотрудники крупных компаний, каждый из которых обладает профильным образованием и длительным стажем работы.

Полная программа курса включает 5 тематических блоков, более 500 видео-уроков: посмотреть

ИнструментыjMeter, Selenium IDE, Bugzilla, SQL, СУБД Microsoft SQL Server.

Полученные умения: работа с тест-планами, кейсами, сценариями, check-list и task-tracker владение техниками test-design, разными видами тестирования и методами его автоматизации.

Цена:

• полная – 88 500 рублей;
• успейте воспользоваться скидкой 40%!
• рассрочка без первого взноса – от 3 295 рублей в месяц.

Бонусы: первые 20 студентов получат скидку 20%.

Итоги: диплом + помощь в трудоустройстве (уже на защите дипломной работы вы встретитесь с заказчиками).

Прошедший обучение тестировщик QA имеет возможность сразу же продемонстрировать свои навыки.

Важно лишь ваше желание приобрести новую специальность, даже уровень знаний в программировании, близкий к отметке «ноль», не станет помехой в программах «Тестировщик» – обучение с трудоустройством». Получить скидку →

Получить скидку →

Подписывайтесь на наши новости

Одно письмо в неделю с самыми актуальными статьями + обзор digital-профессий!

*Нажимая «Подписаться» вы даете согласие на обработку персональных данных.

Другие классификации видов тестирования

Чаще всего используется разбиение на три уровня, это

1. модульное тестирование,
2. интеграционное тестирование,
3. системное тестирование.

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

Под системным тестированием подразумевается тестирование на уровне пользовательского интерфейса.

Иногда используются также некоторые другие термины, такие, как «компонентное тестирование», но я предпочитаю выделять именно эти три, по причине того, что технологическое разделение на модульное и системное тестирование не имеет большого смысла. На разных уровнях могут использоваться одни и те же инструменты, одни и те же техники. Разделение условно.

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

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

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

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

Само по себе приложение тоже может являться частью какой-то более крупной информационной системы.

В этой матрешке мы должны понять, где, на каком уровне у нас должно находиться модульное тестирование, а на каком должно находиться системное тестирование. И найти еще место для интеграционного.

Глядя на эту матрешку мы можем понять, что разделение на системное и модульное тестирование является чисто условным.

То есть у нас система состоит из каких-то модулей. Модули в свою очередь состоят из других более мелких модулей. Эти мелкие модули состоят еще из более мелких, и так далее.

 И так, получаем в результате:

Классификацию по целям удобно выполнять с использованием «магического квадрата», который был изначально придуман Брайаном Мариком и потом улучшен Эри Тенненом.

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

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

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

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

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

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

Так вот, исходя из классификации по целям, модульное тестирование у нас оказывается в левом нижнем квадранте, а все остальные квадранты — это системное тестирование.

Что нужно, чтобы «войти в айти» младшим тестировщиком (требования к Junior)

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

2. Чтобы развить навык тестирования и анализа, что работает как надо, а что нет, начните искать и описывать все ошибки в работе программ или сайтов, с которыми вы сталкиваетесь в жизни (помните насчет «мыслить как преступник»).

3. Тестировщику необходимо логическое мышление ― тренируйте.

4. Обязательно изучите английский. Вся сфера IT требует отличного знания языка. Тем более что документация и самые толковые обучающие курсы (о них мы расскажем в отдельной статье), как правило, на английском.

5. Изучите пару бесплатных курсов от проверенных компаний или преподавателей (не «инфоцыган»), а еще лучше ― запишитесь на профессиональный курс, где вас будут вести за руку. Так меньше шансов, что вы в своей учебе пойдете не туда, куда нужно.

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

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

7. Когда освоитесь, начинайте изучать основы языка запросов SQL ― он здорово облегчит вам жизнь.

8. Дальнейшее совершенствование навыков, изучение систем для «ловли» ошибок (это называется «баг-трекинг»), языков программирования. Как результат ― переход на новый уровень.

Лучше спешите с системными тестами!

Так что же я предлагаю? А предлагаю я взглянуть на старый рисунок по-новому:

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

Как я уже упоминал выше, системные тесты — это тесты программы в целом. При этом программа представляется именно в том виде, в котором её увидит пользователь. Фактически, системные тесты заставляют нас взглянуть на программу как на законченный продукт (хоть он таким сейчас и не является). Если другими словами, то вместо подхода от «от частного к общему» мы начинаем писать тесты «от общего к частному». А это позволяет нам убить сразу двух зайцев:

1. Прорабатывая системные тесты, мы формализуем и фиксируем требования к программе в виде скриптов, которые или проходят — или нет. Соответственно, будет гораздо меньше споров о том, когда фичу можно считать законченной.
2. Системные тесты позволяют очень четко визуализировать и разложить по полочкам то, как наша программа будет выглядеть для конечного пользователя. Это уже ценно само по себе, но также позволяет обнаружить на ранних этапах несостыковки в требованиях (а они всегда есть). Также становится понятным, какие моменты требуют дальнейшей проработки.

Звучит неплохо, не правда ли? Причём, системные тесты обладают ещё рядом очень приятных бонусов:

1. В условиях зафиксированных требований к программе системные тесты не могут сильно меняться. Это возможно благодаря самой природе системных тестов: они рассматривают программу как «черный ящик» — без какой-либо привязки к архитектуре и особенностям реализации. А это значит, что вы можете свободно менять архитектуру своей программы по первому требованию, и никакие тесты менять не придется! Ну, разве что, немного подкорректировать — если у вас добавилась новая зависимость или что-то в таком духе.
2. Системные тесты могут писать аналитики или даже тестировщики — не отнимая, таким образом, ценное время программистов. Также это позволяет аналитикам дать программистам более четкое понимание, что именно они хотят увидеть в программе. Программистам лишь останется добиться того, чтобы тесты проходили, не ломая голову над вопросом «чего же от меня хотят».
3. Системные тесты — это очень комплексный вид тестов. Если ваша программа проходит сложный комплексный тест — то вы уже с довольно высокой долей вероятности можете быть уверены, что «в целом, наверное, все компоненты нормально работают». В Unit-тестах наоборот — уверенность в одном классе не дает абсолютно никакой уверенности в работоспособности программы в целом.

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

Впрочем, сейчас на этом фронте не всё так уж и плохо — существует очень много коммерческих решений, которые позволяют в том или ином виде решить эту проблему: Testcomplete, Squish, Ranorex, Eggplant — это лишь самые известные примеры таких систем. У всех у них есть свои достоинства и недостатки, но в целом со своей задачей по автоматизации системных тестов они справляются (хоть и стоят очень немалых денег).

А вот среди бесплатных решений выбора особо нет. По крайней мере не было.

Совсем недавно я выпустил инструмент, который должен немного исправить вселенскую несправедливость и дать людям возможность бесплатно автоматизировать системные тесты. Этот инструмент называется платформой Testo — и поподробнее про него можно почитать тут.

Как стать тестировщиком

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

Однако в вузах нет специальности «тестировщик». Если рассматривать государственное образование, то проведение тестов изучается только в рамках программирования. Минус в том, что практики при обучении в вузе всё равно не получить, если не работать параллельно на реальных проектах.

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

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

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

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

Если говорить об обучении уже практикующего специалиста, например, ручного тестировщика, то здесь тоже немало вариантов: от специализированных курсов до самостоятельного изучения языков и инструментов, которые понадобятся в новом направлении. Как пример, если интересно тестирование веб-приложений, можно начать с изучения Selenium или Katalon Studio и Java.

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

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

Обеспечение качества сейчас — бурно развивающаяся перспективная сфера, особенно в России и СНГ, и это очень радует и вдохновляет постоянно развиваться в этом направлении.