Специальность QA Software Tester или кто такой Quality Assurance Engineer
QA (Software Testing and Quality Assurance) или тестировщик – это специалист по обеспечению качества программного обеспечения. Тестировщик во многом похож на следователя или детектива. Он идёт по горячим следам программиста и выискивает баги, использует различные дедуктивные методы и скрытые приёмы. Без тщательного тестирования невозможно добиться высокого качества программного продукта – вот почему QA-специалисты очень востребованы в IT-компаниях, занятых разработкой.
Всех тестировщиков можно разделить на 2 большие группы по уровню подготовки — Manual QA Engineer и Automation QA Engineer.
Manual QA Engineer или мануальный тестировщик – это инженер, который фокусирует внимание на процессах разработки ПО, улучшает их, предотвращает появление дефектов и проблем. Все рабочие процессы проходят «вручную»: он планирует процесс тестирования, пишет тест-кейсы, выявляет проблемные места, заносит полученные данные в базу, проводит ре-тесты ошибок после доработки программистами. QA-мануальщик анализирует процесс тестирования для его оптимизации в дальнейшем.
Automation QA Engineer – это специалист, который использует программные средства для создания тестов и проверки результатов выполнения. Основная задача QA-автоматизатора — создавать автоматические скрипты, которые будут проверять работу программы на основании тест-кейсов, написанных QA-мануальщиками. Это помогает сократить время тестирования рутинных задач и упростить весь процесс в целом. QA Automation Engineer обладает навыками программиста и логикой тестировщика одновременно: автоматизатор проверяет качество продукта на различных этапах его разработки, тестирования и эксплуатации, а также он занимается разработкой продукта, который проверит написанное программистами.
Профессия тестировщика идеально подойдет очень ответственным, внимательным людям, которые придают значение деталям, отличаются усидчивостью и немного «страдают» перфекционизмом. Для начала работы в этой сфере необходимо владеть знаниями цикла разработки ПО, изучить теорию и основные инструменты тестирования и иметь хороший уровень английского.
Программа QA курса на ресурсе ITVDN разработана таким образом, что студент получает все необходимые знания и практические навыки для начала своей карьеры тестировщика. Курс позволит изучить основы, которые являются «must have» для всех тестировщиков, независимо от сферы тестирования и продукта, который предстоит тестировать. Закончив его, вы уже сможете начать карьеру и получать реальный опыт на фрилансе или позиции Trainee/Junior QA.
Требования к QA-специалисту:
- Знание этапов жизненного цикла ПО
- Отличное знание теории (основы, методы, виды и типы тестирования) и умение применять эти знания на практике
- Знание баг-трекинговых систем (Jira/YouTrack), опыт работы с ними
- Уверенные знания web-технологий (HTTP, DOM, HTML, JSON, Server response codes, cookie & session)
- Базовые знания SQL, ООП
- Опыт ведения тестовой документации
- Базовые знания языка программирования, который используется в проекте
- Понимание Agile/SCRUM методологии, умение и желание работать в команде
Тестировщик может занимать такие должности:
QA Engineer
QA Manual
Automation QA Engineer
Junior/Middle Test Engineer
Mobile QA Engineer
QA Functional Manager
Junior/Middle QA Game Tester
QA Lead
Кто такие QA и почему выпуск забагованной iOS 13 — это нормально
Onliner вместе с компанией ISsoft добрался до одной из самых стереотипных специальностей в IT-сфере. Порой можно встретить мнение, что через профессию тестировщика легче всего попасть в то самое «айти», причем работа, в общем-то, довольно простая. На деле, конечно, все немного не так. QA-специалист с десятилетним опытом Роман Романчук рассказал, как же устроена эта работа и к чему тестировщику нужно быть готовым.
Что должен уметь тестировщик и QA
— QA и тестировщик — это одно и то же?
— Некоторые говорят «тестирование», а некоторые — «обеспечение качества», то есть QA. Второе понятие более широкое, ведь тестирование — это просто проверка (валидация и верификация). А обеспечение качества — целый процесс внутри команды.
— Какие перспективы у тестировщика?
— Он может развиваться как технически, то есть расти в автоматизацию, так и прокачивать софт-скиллы, расти в QA-лида, QA-менеджера и так далее. В техническом плане кроме автоматизации можно идти в архитектуру — это уже сложный уровень. Если совсем глобально смотреть, тестировщик может перебраться в разработку.
— Насколько нужно знать технические вещи? Достаточно просто сказать «это не работает» или еще нужно понимать причину?
— С минимальным опытом тестировщику сложно понимать, как устроена серверная архитектура или веб-приложение, что на бэкэнде, какие сервисы. То есть описание багов идет поверхностное, как со стороны обычного пользователя: кнопка не работает на сайте — так и пишет. Более опытный тестировщик должен понять, почему кнопка не нажимается. Смотрит консоль: может, JavaScript, а может, запрос пошел, но в ответе ошибка — значит, бэкэнд упал. Чем опытнее тестировщик, тем глубже он копает причину бага. Следовательно, он умеет лучше ее описать, и разработчики смогут быстрее найти и исправить ошибку.
— То есть идеальный тестировщик — это еще и разработчик в душе?
— Хороший тестировщик, опытный, высокого уровня — он немного и разработчик, и бизнес-аналитик, и UX/UI-дизайнер, и проектный менеджер.
— И вы ищете изъяны в их работе, получается.
— Здесь важно понимание целей. Это ведь командная работа, и глобальная задача — сделать качественный продукт вовремя и чтобы клиент был доволен. Когда команда понимает, что работает на общий результат, а не на поиски ошибок конкретного разработчика, тогда все друг другу доверяют.
— Если бы те же разработчики идеально выполняли работу, то тестировщики остались бы без дела?
— Не думаю. В простых системах и продуктах это было бы возможно. Например, при разработке какого-нибудь сайта-визитки QA зачастую и не нужен, проекты сдаются без его привлечения. А когда речь идет о сложных продуктах по автоматизации бизнес-процессов, решению конкретных проблем заказчика — там всегда есть вещи, которые никогда не смогут на 100% учесть ни разработчики, ни дизайнеры. Есть много ниш для проверок: безопасность, стабильность работы. Если пишешь код, держать в голове все эти аспекты невозможно.
Почему выходят забагованные продукты
— Иногда видишь такое: выходит крупное мобильное приложение версии 1.0, и уже через неделю — версия 1.0.1, в описании которой говорится об «исправлении ошибок». Значит, продукт плохо тестировали?
— Часто первая версия продукта — просто проверка рынка, отреагирует он или нет. Для этого надо сделать приложение быстрее других и чтобы оно кое-как работало. Если задача именно такая — то ничего страшного в выпуске сырой версии нет. Конечно, когда все согласовано и заказчика устраивает этот вариант. А баги уже потом можно дофиксить.
Другое дело — например, банковское приложение. Здесь уже непозволительно выпускать забагованный продукт, репутация очень важна.
— За два месяца iOS 13 получила около пяти обновлений, и большинство из них касались не добавления новых функций, а правок существующих. Почему такое происходит? Вряд ли Apple не хватило средств на тестирование.
— У Apple есть четкие циклы выпуска продуктов: нужно в год уложить разработку нового железа и софта, а затем поддерживать совместимость ПО с прошлыми устройствами. Не всегда получается за один год заложить и новые фичи, и новое железо, отсюда и возникают проблемы. Понятно, что это сложнейшие проекты, и регулярно идет «процентовка» — проверка вида «успеваем / не успеваем». Где-то возникли проблемы с производителем железа, где-то споткнулись на какой-нибудь фишке. Тогда принимается осознанное решение: да, будут недоработки, но нужно выходить в любом случае.
Падение стоимости акций компании значительно хуже при невыходе нового iPhone, чем при выпуске забагованной операционной системы.
Представьте варианты использования одного и того же смартфона: разные операторы, типы подключений, стандарты беспроводных сетей. Проверить такое многообразие невозможно даже с помощью автотестов. Поэтому всегда будут возникать какие-то специфические баги, и нужно быть готовым быстро их исправить в случае обнаружения.
О разных типах тестирования
— Есть «тестирование низкого уровня». Что это и какие уровни, методы еще бывают?
— Существует большое количество классификаций тестирования по уровням, типам, методам и подходам. Если мы говорим о тестировании на низком уровне, то сюда больше подходит понятие «тестирование методом серого ящика». Например, есть проекты, где разработка ведется на низком уровне. Это написание кода, который взаимодействует непосредственно с железом. В последние годы понятие используется в связи с развитием интернета вещей — всевозможные кофеварки и чайники, которые подключаются к интернету. И чтобы это маленькое устройство могло соединиться с Wi-Fi-точкой, смартфоном по Bluetooth и так далее, нужен софт. Но не в обычном понимании, а без UI. Вот это и есть «низкий уровень». К примеру, измерение температуры воды в чайнике, передача этих данных на смартфон — программирование низкого уровня. Сейчас у этой сферы прямо новое дыхание.
А поскольку разработка ведется на низком уровне, то и тестирование должно быть на нем же. Тестировщик должен понимать, что здесь идет проверка не только софта, но и железа. Допустим, нужно проверить новую модель слухового аппарата. Надо понимать, что у устройства есть встроенная память, она делится на энергозависимую и независимую и так далее. Чем больше тестировщик знает таких деталей, тем эффективнее будет проходить испытание.
— Как выглядит мануальное тестирование? Допустим, нужно проверить сайт. Берете и прокликиваете каждую кнопку, смотрите, куда ведут ссылки?
— Все думают, что именно так это и выглядит. На самом деле описанное — уровень джуниора. Действительно, они могут проводить такое тестирование: проверять работоспособность каждой функции и так далее.
А если мы говорим про обеспечение качества (QA), то сперва нужно посмотреть на сам сайт, узнать у клиента необходимые функциональные и нефункциональные требования, процесс работы, приоритеты. Например, важны ли UI-требования, соответствия палитры и другие вещи. Дальше мы создаем тест-план, в котором, скажем, в рамках UI-тестирования смотрим четкие аспекты — цвет, разрешение (для поддержки различных форм-факторов устройств: ноутбуки, планшеты, телефоны), наличие прототипа интерфейса и так далее.
Некоторые клиенты, к примеру, хотят конкретный цвет, и мы проверяем на полное совпадение по коду оттенка. И так проходим по каждому из типов тестирования. В тест-плане важно правильно описать и согласовать с клиентом наше видение процессов, подходов и планов по тестированию, ведь от этого зависит бюджет, размер команды и необходимая квалификация тестировщиков. В QA масса всего: какие браузеры как отображают сайт; есть ли у него интеграции, например, с банковскими сервисами; под какой нагрузкой он будет работать и так далее. Отдельная и одна из самых сложных граней — безопасность и проверка на наличие уязвимостей.
— Что, если тестировщик заметит проблему в UX? Что-то показалось неудобным, нелогичным. Это его сфера ответственности?
— Думаю, да. Если делаем аналог Booking, то понимаем, что сервисом будут пользоваться миллионы людей. И, например, есть список со множеством фильтров. Когда разработчики добавили популярный фильтр куда-то вниз страницы и до него нужно скролить или он просто малозаметный, тестировщик наверняка это увидит — и такое, я считаю, нужно отправлять на доработку.
Хотя, опять же, предварительно нужно обговорить с клиентом, обращать внимание на подобные вещи при тестировании или нет. Но базовое понимание юзабилити у хорошего тестировщика должно быть.
Как обстоят дела с подготовкой людей, из каких отраслей переходят в QA и что вообще высшее образование может дать тестировщику, мы узнали в Институте информационных технологий БГУИРа. Декан факультета повышения квалификации и переподготовки кандидат технических наук, доцент Андрей Говин, кандидат физико-математических наук, доцент Инна Кашникова и кандидат технических наук, доцент Валерий Мухаметов рассказали, почему тестировщики в 35 лет становятся «пенсионерами» и куда они идут дальше.
Век такого тестировщика после курсов — 30—35 лет
— Есть мнение, что попасть в IT через тестирование проще всего. Согласны ли с этим и почему?
Андрей Говин: Да, такое мнение действительно есть. Скорее всего, оно складывается из-за малого времени обучения, особенно если говорим о внутренних курсах IT-компаний. Но есть опасность. Вы получите знания в узконаправленной компетенции, то есть то, что нужно заказчикам здесь и сейчас. Дальнейшее развитие специалиста — его личная забота, заказчика это не интересует.
Примерно в 35 лет тестировщик подходит к пенсионному возрасту в IT-сфере. Так же с другими профессиями. Например, программист к этому времени достигает пика по зарплате, а потом она плавно снижается. Затем он становится менее креативным и к 35 годам понимает, что должен что-то делать: или открывать свою компанию, переходить на управленческие позиции, или идти в преподаватели. Молодежь в Беларуси очень способная и дышит в спину очень активно. По крайней мере, у меня такое мнение сложилось о рынке.
— Тестировщик должен быть каждым понемногу: и программистом, и бизнес-аналитиком, и дизайнером. Значит, одного образования может не хватить?
Инна Кашникова: Наверное, сейчас в нашей жизни одного образования никому не хватит. Вам ведь понадобятся знания в той области, в которой вы работаете. Тестируете проекты, которые представлены на финансовых рынках, — значит, нужно иметь представление о том, что такое финансовый рынок. Поэтому да, узконаправленные специалисты, наверное, просто не могут работать.
— Как часто обновляете программы подготовки?
Валерий Мухаметов: Специальность тестировщика для нас относительно молодая. Мы обновляем программы каждый год. По своим дисциплинам могу за год сделать пять-шесть версий материалов. Все действительно быстро меняется.
Инна Кашникова: Фактически к каждому набору преподаватели пересматривают лабораторные работы, практикумы, и все постоянно обновляется.
Кандидат медицинских наук пошел учиться на айтишника
— Из каких сфер приходят к вам на курсы? Врачи, учителя, айтишники других специальностей?
Валерий Мухаметов: Люди очень разные. Входного барьера у нас нет, нужен только диплом о высшем образовании, никаких вступительных экзаменов. Поэтому к упомянутым учителям и врачам можно добавить кого угодно. К примеру, на специальность «Программное обеспечение информационных систем» пришла врач-гинеколог с десятилетним стажем.
Андрей Говин: Недавно у нас закончил обучение кандидат медицинских наук, а сейчас учится кандидат юридических наук. Представляете, насколько люди решили поменять свою жизнь? Ведь у них хорошая база уже была в своей сфере. Но специалисты захотели идти дальше.
Валерий Мухаметов: Однажды по совету мужа пришла женщина. У нее образование было связано с биологией, и мы сказали, что перечень специальностей не позволяет ей учиться у нас — он хоть и широкий, но ограничен все же. Тогда она пошла в Министерство образования, добилась от них разрешения на учебу у нас, закончила курс с отличием и сейчас работает в крупной IT-компании.
— Дайте напоследок по одному совету для тестировщика.
Андрей Говин: Обращусь к школьникам: ходите на курсы по профильной ориентации, которых сейчас становится много. Посмотрите на программирование, тестирование, дизайн — поймете, что к чему.
Инна Кашникова: Задача современного человека — постоянно развиваться и оставаться в тренде. Профессия тестировщика хоть и востребована, но, на мой взгляд, не должна быть одной на всю жизнь. Вам понадобятся новые знания и развитие.
Валерий Мухаметов: Я сказал бы о важности стыков двух наук. Как правило, специалистов в одной области всегда много, а вот в смежных отраслях таковых уже гораздо меньше. Поэтому совет — выжимать максимум из своего образования, и лучше не одного, а минимум двух.
Компания ISsoft — один из крупнейших белорусских разработчиков IT-решений для рынков США и Западной Европы. Основана в Минске в 2004 году как дочерняя компания корпорации Coherent Solutions, Inc. (США). Резидент Парка высоких технологий с 2007 года. Центры разработки ISsoft в Минске и Бресте насчитывают более 1000 квалифицированных сотрудников. Компания ежегодно входит в рейтинги Inc.5000 и Software 500.
Спецпроект подготовлен при поддержке иностранного производственного унитарного предприятия «ИССОФТ СОЛЮШЕНЗ», УНП 190819327.
Читайте также:
Библиотека Onliner: лучшие материалы и циклы статей
Наш канал в Telegram. Присоединяйтесь!
Быстрая связь с редакцией: читайте паблик-чат Onliner и пишите нам в Viber!
Перепечатка текста и фотографий Onliner без разрешения редакции запрещена. [email protected]
Зачем нужны тестировщики
Начем с того, что QA-инженер — одна из самых недооценённых профессий в нашей индустрии. Зарплаты тестировщиков обычно намного меньше, чем зарплаты программистов. Соответственно, эта сфера меньше привлекает талантливых людей. А если уж они и попадают в неё, то стремятся как можно быстрее продвинуться в разработку или управление проектами, чтобы зарабатывать больше.
Всё это приводит к тому, что найти хорошего тестировщика гораздо сложнее, чем хорошего программиста. При этом количество технических знаний, необходимых QA-инженеру, никак не меньше, чем разработчику. Кроме того, тестировщик должен обладать набором уникальных скилов, которых зачастую нет у кодеров. Поэтому хороший QA-специалист сегодня на вес золота.
Чтобы понять эту мысль, давайте разберём, как в теории должен происходить процесс разработки.
- Идеальный product-manager создает максимально детализированный спек продукта и передаёт его идеальному дизайнеру.
- Идеальный дизайнер, в свою очередь, рисует продуманные до мельчайших деталей UI- и UX-мокапы.
- Техлид компании распределяет работу между разработчиками.
- Идеальные разработчики в кратчайшие сроки (и, разумеется, без багов) имплементируют спек, тщательно проверяя и документируя свой код.
- Идеальные QA-инженеры пишут тест-план на основе детального спека и сверяются с UI-диаграммами, полученными от дизайнера.
- Проверка продукта становится тривиальной задачей и он выходит в продакшн.
Если это описание вызвало у вас слёзы умиления, то я с вами. Потому что хороших продюсеров вообще очень мало, а тех, кто способен написать детальный спек, — единицы. Программисты редко видят картину настолько, чтобы уже на стадии имплементации замечать в спеках ошибки. Особенно если они не находятся внутри одного конкретного модуля, над которым сейчас работают.
Так что вернёмся теперь в реальность и попробуем разобраться, как в действительности выглядит проверка ПО и какие роли в организации исполняют тестировщики.
Тестовое задание QA / Хабр
Некоторое время назад я проходил собеседование на позицию QA инженера в одной известной российской IT-компании. Мне была предложена задача, свое решение которой с позволения компании я опубликовал в своем блоге. Пост оказался очень популярным, за короткое время набрав несколько тысяч просмотров, и мне показалась светлой мысль продублировать его на Хабре. По правилам Хабра текст публикуется без смайликов.
Итак, задача звучала следующим образом: необходимо описать шаги для всестороннего тестирования простого карандаша с резинкой на одном из концов.
Решение — под катом.
Поскольку карандаши — вообще замечательнейшая и любимая тема, я получил несказанное удовольствие от этого задания. В процессе размышления и поиска информации открыто много нового и интересного, о чем раньше я и не подозревал…
Итак, имеем карандаш:
По условию задачи, поскольку никаких дополнительных условий не задано, поэтому полагаем, что:
1. Карандаш не механический, а именно простой — деревянный или пластиковый. Про цвет ничего не сказано — т.о. карандаш может быть цветным. По-сути, данное условие говорит только о том, что данный карандаш более пригоден для рисования, чем для простых записей и черчения; конечно, не факт, но положим данное условие несущественным — намеренно не будем рассматривать тестирование карандашей разных цветов. При желании рассмотрим этот вопрос отдельно.
2. Изначально неизвестно, заточил ли производитель карандаш на фабрике или нет — рассмотрим оба случая.
3. Резинка несъемная и расположена на противоположном конце карандаша.
4. Если предположить, что у нас в наличии имеется только один экземпляр карандаша, то тестирование можно провести не по всем пунктам — функционал тестирования заметно сузится, т.к. карандаш, увы, ресурс не восстанавливаемый — его нужно точить, им надо писать, а также делать с ним разные другие интересные вещи.
5. Ничего не сказано про упаковку, производителя и параметры карандаша. Предполагаем, что мы их все-таки имеем/знаем/видим. При обратном функционал тестирования будет несколько меньше.
Общие критерии оценки тестов:
Основными критериями оценки будем считать выполнение / невыполнение условий указанных тестов. В случае если тест выполняется, можно оценить результат по неким заранее заданным правилам (например, по десятибалльной шкале, 0 — ужасно, 10 — превосходно; а в целом критерий оценки может быть задан как угодно). Некоторые параметры дополнительно попытаемся представить в числовом выражении. На основе полученных данных можно создавать сводные характеристики различных моделей карандашей.
Основные Test Cases для тестирования карандаша будут выглядеть примерно так.
Начальные свойства «из коробки» или «беглый осмотр» (primary testing):
— Если карандаш изначально заточен: удостоверимся, что им можно писать «by default». Некоторые производители карандашей умудряются заточить их таким образом, что их необходимо предварительно затачивать еще раз, ибо при заточке по умолчанию они попросту не пишут.
— Если карандаш изначально не заточен: удобно ли нам в текущих условиях иметь не заточенный «по умолчанию» карандаш (например, когда под рукой нет точилки или канцелярского ножа)? Т.е. потребуется ли дополнительная «инициализация» карандаша в виде его предварительной заточки.
— Убеждаемся, что резинка на конце карандаша не отрывается при первом прикосновении к ней и держится крепко — хотя бы визуально.
— Есть ли на карандаше маркировка, обозначающая (степень твердости, диаметр стержня, назначение, специфические параметры)? Указан ли производитель?
— Какая форма стержня: круглый, шестиугольный, треугольный, овальный с широким грифелем? На практике карандаши с круглым стержнем больше подходят для рисования, шестиугольные — для письма и черчения (при рисовании рука меньше устает при круглой форме, при письме и черчении — при шестиугольной). Карандаши с треугольным стволом удобны для детей и людей с ограниченными возможностями — в случае когда рука плохо держит карандаш.
— Стержень из древесины или из пластика?
— Есть ли на карандаше лаковое покрытие?
— Обращаем внимание на коробку и упаковку, а также маркировку на них: производитель и все параметры карандаша.
Качество изделия (quality estimation):
— На карандаше нет заусениц, неровностей, потеков от лака, прочих неопрятностей и заводских браков.
— Маркировка (если она есть) нанесена качественно, надписи не расплываются и четко читаются.
— Держатель резинки ровный, не цепляется за одежду и кожу.
Удобство использования (usability testing):
— Карандаш удобно держать в руке. При работе он не выскальзывает и не выпадает.
— Есть ли на карандаше «зона захвата» (gripp zone) — специальные шашечки из краски, не позволяющие карандашу скользить в руке ( 2001, Faber Castell). См. предыдущий пункт.
— Для слабовидящих: актуально использование карандашей с шестигранным или треугольным стволом. Карандаш с круглым стволом, укатившийся под стол, часто представляет для слабовидящего человека серьезную проблему.
Использование (functional testing):
Порисуем на бумаге.
— Убеждаемся, что карандаш вообще рисует.
— Убеждаемся, что цвет текста / качество рисунка / чертежа соответствует твердости карандаша (насыщенный, бледный, ретушь, etc…
— Проверим поведение карандаша при сильном надавливании грифелем карандаша на бумагу. Убедиться, что карандаш не сломается.
— Потянем за грифель карандаша. Он не должен выходить из ствола.
— Постучим карандашом по столу несколько раз. Грифель не должен раскрошиться или сломаться, вывалиться из ствола, расколоться.
— Грифель не ломается и не крошится и непосредственно при рисовании.
— Карандаш не пачкает руки и одежду, не оставляет дополнительных следов на рисунке.
— При рисовании ствол карандаша чистый, он не собирает на себя микробы и грязь с рук. Лучше всего в этом смысле карандаши с лакированным стволом.
Используем резинку на карандаше.
— Насколько резинка на конце карандаша вообще имеет смысл — она больше в работе или же больше мешает?
— Резинка стирает записи/рисунки, не размазывает и не «грязнит».
— Резинка со временем не «дубеет» и продолжает исполнять свои функции.
— После использования резинка не отстает от карандаша, не отслаивается и не выпадает; держатель не гнется и не оставляет следов и царапин на бумаге и руках.
— Карандаш пишет на тех местах, на которых были стерты записи резинкой.
— То же самое проделаем с резинкой, взятой не от карандаша.
— Теперь будем чертить, а затем писать карандашом: все те же действия, но в немного других исходных условиях (до этого мы рисовали). Разные карандаши предназначены для различных целей: школьные, канцелярские, чертежные, рисовальные (в мире выпускается более 370 (!) разных типов и видов карандашей, так что простор для фантазии весьма богатый).
— Далее попробуем рисовать/чертить/писать не на бумаге, а на альтернативных материалах — плотная бумага, картон, газета, деревянный брусок, стены, пол (актуально при ремонтных и строительных работах).
— Порисуем через копирку. Не должно возникнуть каких-либо специфических проблем.
— Хранение и транспортировка: помещается ли карандаш в подставку для карандашей (соответствуют ли параметры)? Насколько удобно он помещается и переносится в кармане, в сумке? Не колется ли при этом, не ломается, не крошится?..
Экологичность (ECO testing):
— Если ствол карандаша покрыт лаком: используется лак на полимерной или на водной основе?
Этот пункт также можно отнести к тестированию безопасности изделия. К сожалению, выяснить на 100% для всех карандашей невозможно — на коробке это пишется далеко не всегда. Разве что химический анализ поможет.
Это требование весьма актуально, ибо очень часто дети (и не только!) попросту «съедают» карандаши. По моим подсчетам, я сам съедаю по несколько карандашей в год. Сколько при этом я получу вредных веществ от такой привычки, если карандаш не безопасен — науке доподлинно неизвестно. При желании можно было бы попытаться подсчитать, но что-то не хочется…
С точки зрения экологичности самые лучшие карандаши — нелакированные и без резинки (они, кстати в великом множестве встречаются в магазинах Ikea, Leroy Merlen и т.п.). И именно по этой причине лично я недолюбливаю карандаши с резинкой на конце — ИМХО есть ее, а особенно железный держатель есть неудобно вдвойне.
Безопасность (security testing):
— Можно ли пораниться карандашом (поцарапаться, порезаться при заточке, опасен ли карандаш для глаз)?
— Можно ли дать карандаш ребенку? Существуют «безопасные» виды карандашей (например, специальные «детские», часто — с треугольным стволом), которые можно давать детям без опаски (естественно, руководствуясь возрастом, общим развитием и особенностями ребенка).
— Безопасен ли карандаш для людей с ограниченными возможностями (например, для слабовидящих)?
— Соответствует ли карандаш принятым стандартам (ISO, ГОСТ, etc…).
Внеший вид (appearance, ergonomic and usability testing):
— Цвет карандаша. «Классический» ствол желтого цвета в стиле «Koh-I-Noor» или же альтернативная не-классика? При выборе карандаша люди руководствуются разными соображениями.
— Общая привлекательность, оформление и дизайн.
— Ствол круглый, треугольный или шестигранный.
— Упаковка/дизайн приносит или не приносит эстетическое удовлетворение и в целом радует глаз или нет.
Здесь можно иметь дополнительные данные и сделать дополнительные выводы: какова потенциальная целевая аудитория покупателей данной модели, насколько хорошо он будет продаваться и в каких местах, каковы его основные маркетинговые свойства, нужно ли рекламировать, каким образом и сколько денег тратить на рекламу и т.п. Я не маркетолог, но могу предположить, что за этим скрывается отдельная большая тема, которую здесь трудно будет раскрыть.
Заточка карандаша.
Возможные вариации заточки:
— Затачиваем точилкой для карандашей.
— Затачиваем шкуркой (актуально для мягких карандашей и карандашей для ретуширования).
— Затачиваем опасной бритвой.
— Затачиваем канцелярским ножом.
— Затачиваем кухонным ножом (тесаком, медицинским скальпелем, etc.)
— В отсутствии инструментов заточки затачиваем (пытаемся) неподходящими для этого средствами (например, зубами, куском стекла или вилкой). В результате, вероятнее всего, будет epic fail, но тем не менее имеет место быть.
Критерии оценки заточки (для каждого инструмента):
— Карандаш вообще затачивается данным инструментом. Например, заточить карандаш с пластиковым стволом с помощью шкурки или опасной бритвы будет весьма затруднительно. Заточить маленький (сточенный) карандаш с помощью охотничьего тесака также будет проблематично.
— Карандаш затачивается легко. Очень актуальный тест: некоторые карандаши при заточке оказываются абсолютно «железными» и заточке не поддаются в принципе (лично наблюдал такой пример на карандашах одного известного производителя).
— В процессе заточки и после нее грифель не нарушил свою целостность.
— В процессе заточки и после нее карандаш не ломается и не крошится.
— Ствол карандаша не расслаивается, после заточки нет заусениц, неровностей и других повреждений.
— Грифель не выпадает из ствола.
— Для залакированных карандашей: лак не отслаивается кусками от ствола и не крошится.
— Заточенный карандаш успешно функционирует (можно писать, рисовать, чертить).
— Коэффициент успешности заточки K = M / N, где M — количество удачных заточек, N — количество неудачных заточек. Чем меньше K, тем хуже карандаш затачивается с помощью данного инструмента.
Далее действуем по принципу «Пытаемся поломать все, что ломается» (чтобы потом все правильно работало, конечно).
Использование в экстремальных условиях (stress testing):
— Уронить карандаш на пол несколько раз. В идеале грифель не должен сломаться или раскрошиться. Ствол карандаша не должен иметь повреждений.
— Попытаться согнуть карандаш, приложив усилие: сломается или нет?
— Будем грызть карандаш с особым усердием. Конец карандаша не должен быть «съеден». Многие производители уделяют этому моменту особое внимание.
Мы любим карандаши Ikea!
Они маленькие — помещаются в маленькую сумку.
Они крепкие — можно уронить несколько раз.
Они вкусные — можно погрызть
— Поместим карандаш в воду, затем высушим.
— Поместим карандаш в кислотную, щелочную среду ненадолго.
— Заморозим, а затем отогреем. Вариант — положить в снег на морозе.
— Нагреем карандаш, затем охладим. Но поджигать все-таки не станем. Это, конечно, тоже можно, хотя вряд ли после такой процедуры им можно будет пользоваться, если только не представить себе карандаш Джеймса Бонда, который в огне не горит и в воде не тонет.
— Если бюджет тестирования не ограничен или тестирование хорошо оплачивается производителем в рекламных целях — проведем испытания в условиях невесомости. Космонавты на МКС по специфическим причинам, возникающим в невесомости, кстати, пользуются обычными грифельными карандашами…
Каждая из манипуляций, описанных выше, так или иначе окажет определенное воздействие на карандаш. После каждой из итераций тестируем использование карандаша (см. functional testing), производим заточку. Внешний вид тестировать больше не будем — есть подозрения, что если произвести над карандашом все перечисленные манипуляции, то это будет уже не карандаш, а в лучшем случае некое его подобие.
Тестирование производительности (performance testing, или напоследок немного простейшей математики):
Попытаемся измерить производительность карандаша: на сколько страниц текста/рисунков его хватит. Можно это сделать вручную, однако проблема заключается в том, что это будет весьма долгий и трудоемкий процесс, поскольку «изрисовать» целый (особенно качественно сделанный) карандаш достаточно трудно. Можно проделать все операции вручную, а можно воспользоваться элементарной математикой.
Представим, что есть некие эмпирически подсчитанные усредненные показатели: сколько страниц текста/рисунков можно нарисовать карандашом определенной длины, твердости, определенной формы и с определенным диаметром стержня. Пусть это будет называться «КПД карандаша» и будет составлять X страниц A4 (или X километров текста) для карандаша длины Y см. (данные берем: у производителя, в Google, в библиотечных источниках — нужное подчеркнуть). Допустим также, что эмпирические расчеты немного неточны и используют длину карандаша «под ноль», а так как пользоваться карандашом длиной менее 4 см весьма затруднительно, плюс 1 см на резинку с держателем, то на «реальную» работу у нас остается (Y — 5) см. Одно затачивание «отнимает» у карандаша около 1 см длины, поэтому на один карандаш стандартной длины 18 см. у нас есть приблизительно 13 заточек. При заточке карандаш может сломаться. Считаем, сколько было неудачных заточек за время работы карандаша; пусть это число будет равно N. Пусть длина карандаша равна L см. Тогда:
Реальный КПД карандаша = (L — 5 — N) * (X/Y)
Можно предположить, что после того, как карандаш уже сточен наполовину, число неудачных заточек некоторым образом увеличится, например с коэффициентом K. Тогда:
Реальный КПД карандаша = ((L — 5 — N)/2 + (L — 5 — K*N)/2) * (X/Y)
Можно и по-другому: посчитаем количество удачных заточек, исходя из реальных данных, полученных опытным путем в ходе заточки карандаша. Пусть это будет V. Тогда:
Реальный КПД карандаша = V * X / Y
Понятно, что расчеты весьма условны, и при желании можно усложнить расчеты, придумать более точные критерии — этот пример не делает целью точно подсчитать КПД карандаша, а попросту показывает, что данное измерение подвержено математическим расчетам.
P.S.:
Можно придумать еще много чего. Наверняка.
В процессе раздумий над данными действиями я активно пользовался обычным карандашом. Правда, без резинки.
Результат тестирования можно представить в графическом виде.
Кто ты, QA-инженер или тестировщик?
Оригинальная публикация
Автор: Евгений Иванченко
QA и QC — как камыш и рогоз. Конечно, есть ботаники, которые их различают, но большинство людей всё-таки путают. Иногда самим QA и QC легче согласиться с представлением обывателей, чем пускаться в долгие объяснения, в чём же всё-таки разница. Предлагаю сделать усилие над собой, разобраться с терминами и понятиями, увидеть отличия и больше никогда их не путать.
Больше трёх лет я занимаюсь обеспечением качества продуктов. И всё это время наблюдаю за эволюцией процессов тестирования в компании.
От момента зарождения, когда в команду нанимали первых двух человек. Полгода они тестировали продукт руками, а после становились бизнес-аналитиками, а за ними уже стояли следующие два человека.
До текущих процессов с блэкджеком Scrum-Less и автотестами на Selenium.
Накопленный опыт и черты характера типичные для моей профессии привели к размышлениям о том, кто такие тестировщики, QA и QC. Разные это суть сущности или пересекающиеся? В статьях и конференциях я часто сталкиваюсь с какой-то путаницей, мне это не нравится. Поэтому я решил поделиться своими мыслями на этот счёт. Осторожно, данная статья не является истиной в первой инстанции. Данная статья — мысли вслух и желание найти единомышленников.
QA, QC и тестировщики: три большие разницы?
Начнём наши поиски и копания с обращения к Международному стандарту системы менеджмента качества ISO 9000:2015. В каждой статье, в каждом видео на тему отличия этих понятий есть ссылка на этот документ, моя статья не исключение.
В пункте 3.2 стандарта раскрываются два определения:
- Обеспечение качества (3.2.10) — часть управления качеством, направленная на обеспечение уверенности в том, что требования к качеству будут выполнены.
ОригиналQuality assurance (3.2.10) — part of quality management focused on providing confidence that quality requirements will be fulfilled.
- Контроль качества (3.2.11) — часть управления качеством, ориентированная на выполнение требований к качеству.
ОригиналQuality control (3.2.11) — part of quality management focused on fulfilling quality requirements.
Из этих определений следует, что мы либо обеспечиваем качественный продукт, либо проверяем продукт на соответствие качеству.
Отмечу, что в стандарте ISO 9000:2015 вообще нет понятия tester как такового. Я искал.
Так каким же образом взаимосвязаны понятия Quality assurance, Quality control и Тестирование между собой?
Часто можно встретить такого рода иллюстрации со слоёной структурой качества, где тестирование — часть контроля качества, контроль качества — часть обеспечения качества.
Но лично мне кажется, что раз в стандарте нет понятия tester или testing, а QC — это и есть разного рода тестирование, то и иллюстрации должны быть такими:
Однако стандарт есть стандарт, а у нас тут реальная жизнь. И в реальной жизни IT-индустрии встречаются только два названия нашей профессии:
- QA-инженер.
- Тестировщик Программного обеспечения (ПО).
Причём очень часто эти понятия взаимозаменяются и путаются. Неразбериха начинается ещё на этапе описания вакансий.
Ищу Тестировщика ПО (QA-инженера)
Я бы не писал эту статью, если бы в индустрии не смешивали эти роли и не называли тестировщиков QA-инженерами и наоборот. По моим наблюдениям, в России не разделяют две профессии. Всех для простоты (а может по незнанию) называют тестировщиками. И ладно бы таким грешили только работодатели, но путаницу поддерживают и сами тестировщики. Например, на Хабре можно встретить статьи, где авторы на протяжении всего текста называют одних и тех же людей тестировщиками, QC-инженерами, QA-специалистами, инженерами по тестированию и тестерами.
Масла в огонь подливают HR-менеджеры: часто для увеличения охвата аудитории они пишут в названии вакансии «Тестировщик ПО (QA инженер)». Шапкой вакансии дело не заканчивается, винегрет продолжается и в самом описании.
Давайте обратимся к вакансиям QA-инженеров:
Все задачи связаны с тестированием и нацелены на поиск багов, хотя компания ищет «QA-инженера».
Или ещё один красочный пример:
И ещё:
И на сладкое:
По факту многие работодатели ищут тестировщика ПО (если ориентироваться по описанию обязанностей), но в названии обозначают, что находятся в поисках QA-инженера.
Если вы помните, в ISO 9000:2015 есть QA и QC. Что будет, если выполнить запрос на hh.ru по ключевому слову QC? А ничего не будет. Вы не увидите вакансий ни QA, ни тестировщика. По такому запросу появятся вакансии, связанные с производством и контролем качества выпускаемой продукции.
Получается, что в IT-индустрии нет профессий QC, их заменили на тестировщиков ПО, а в других сферах деятельности нет QA-специалистов, зато есть QC. В описании вакансий QA-инженеров не указывают обязанности по улучшению качества продуктов и недопущению багов, наверное, считают это само собой разумеющимся.
Что такое обеспечение качества
Прежде чем продолжить, давайте замутим небольшой интерактив. Перейдите по ссылке и посмотрите на сайт конференции QualityConf. Побродите пару минут по темам выступлений и ответьте для себя на несколько вопросов:
- Для кого эта конференция?
- С чем она у вас ассоциируется?
Конференция QualityConf целиком и полностью посвящена качеству, а не тестированию. Однако при подготовке очередной конференции организаторы провели исследование и задали вопрос своим посетителям: «С чем у вас ассоциируется конференция?».
Как вы все уже, наверное, догадались, главные ассоциации были исключительно с тестированием.
Получается, что сегодня, говоря слово «качество», многие слышат «тестирование», и очень часто это функциональное тестирование, хотя понятие качество гораздо шире.
Качество — это определение потребителя, а не определение инженера, не определение маркетинга и не общее определение менеджмента. Оно основано на фактическом опыте клиента в отношении продукта или услуги, измеряется в соответствии с его требованиями — заявленными или неустановленными, осознанными или просто ощущаемыми, технически действующими или полностью субъективными. Качество всегда представляет собой движущуюся цель на конкурентном рынке.
Оригинал
Quality is a customer determination, not an engineer’s determination, not a marketing determination, nor a general management determination. It is based on the customer’s actual experience with the product or service, measured against his or her requirements — stated or unstated, conscious or merely sensed, technically operational or entirely subjective — and always representing a moving target in a competitive market (Armand Feigenbaum «Total quality control»).
Тестирование — один из способов обеспечить качество продукта. Кроме этого повысить качество продукта можно вводя стандарты кодирования, внедряя новые инженерные практики, дизайн ревью и так далее. Способов обеспечить качество много, но на разных этапах зрелости команд и процессов в компании эти способы дадут разный эффект, об этом необходимо помнить. Но это уже совсем другая история.
QA ≠ QC: как их различить
QC: кто эти люди, какие у них задачи, какие у них ограничения
Кто эти люди? Люди, которых называют тестировщиками, тождественны контролю качества QC. По логике вещей они на последнем этапе разработки проверяют качество продукта (любым видом и типом тестирования — ручным, автоматизированным, нагрузочным, тестированием безопасности и т.д.).
Какая у них задача? Их задача — провести валидацию продукта и предоставить информацию бизнесу и разработчикам о соответствии продукта заявленным требованиям.
Какие у них ограничения? Какие могут быть недостатки, если у вас все сотрудники проверяют продукт на соответствие:
- До взятия фичи в проверку такие сотрудники не влияют на процесс обеспечения качества и разработки, хотя их участие могло бы предотвратить некоторое количество багов и тем самым сократить затраты на тестирование.
- Зачастую такие сотрудники не могут давать рекомендации, как сделать продукт лучше. Потому что поезд ушёл и уже поздно. Им остаётся лишь сверять соответствие продукта требованиям. FYI: хотя на самом деле тестировщикам есть что сказать по поводу улучшений, которые необходимо сделать.
- Эти ребята чаще всего не видят полной картины процесса, поэтому искренне не понимают, почему разработчики дают им код, в котором приложение крашится при попытке запуститься. И, согласно п.1, ничего не могут с этим сделать. Даже если хотят.
- Они не могут взять на себя полную ответственность за качество продукта.
- Очень часто между тестировщиками и разработчиками возникают конфликты. Так бывает, когда разработчики считают свой код самым лучшим и работающим, а в тестировщиках видят лишь попытки его сломать и показать, что код не работает. Такое положение дел порождает всем известные мемы «Это не баг, а фича».
QA: кто эти люди, какие у них задачи, какие у них ограничения
Кто эти люди? Инженеры по обеспечению качества (QA) — это люди, которые помогают командам разработки выпускать качественный продукт, как можно быстрее за как можно меньшие деньги. Ведь все мы знаем, что чем раньше найден баг, тем дешевле его пофиксить. Лучше всего фиксить баги ещё на уровне идеи.
QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это.
Какая у них задача? Задача QA-инженера — не допустить несоответствия продукта предъявляемым требованиям. QA-инженер замеряет качество продукта, знает его актуальное состояние и что нужно сделать, чтобы его поднять не только на этапе тестирования, но и на этапе разработки, дизайна или составления требований.
Какие у них ограничения? Сложно оценить качество работы QA-инженера, потому что если он хорошо выполняет свою работу, то до этапа тестирования будет доходить минимальное количество багов не влияющих на функциональность и запуск продукта в прод.
В отличие от QA, работу QC оценить можно, особенно если отталкиваться от самого простого и оценивать эффективность по количеству багов — сколько багов нашёл и сколько багов пропустил на прод.
Как дальше жить?
Большой штат тестировщиков не сможет существенно улучшить качество продукта. Но сможет улучшить саму проверку качества. Если же вы, коллеги-тестировщики, хотите поднимать именно качество на новый уровень, задумайтесь о переходе в QA-инженеры.
Только не ждите, когда вас позовут на встречу, где обсуждают фичи с разработчиками или дизайнерами, придите на неё сами. Высказывайте своё мнение касательно любого аспекта качества продукта. Не позволяйте сложившимся правилам, должностным инструкциям и прочей фигне мешать вам делать продукт ещё более качественным, чем сейчас.
Я знаю, что большинству из вас не всё равно на то, что вы тестируете. И вы искренне хотите поставлять хороший продукт, которым приятно будет пользоваться.
Обсудить в форуме
Как стать тестировщиком — профессия QA-инженер
Профессия тестировщик ПО — один из вариантов, как попасть в IT-сферу. Опыт работы и уровень тестировщика определяет его зарплату. В Беларуси QA-инженер с опытом 1−3 года может рассчитывать на вознаграждение от 700 USD. Хороший заработок и возможность перейти в эту деятельность из нетехнических профессий привлекают многих соискателей. Но все ли могут стать хорошими тестировщиками? Разберёмся, кому подходит эта профессия и как научиться премудростям тестирования.
Чем занимается тестировщик?
QA-инженер (Quality Assurance engineer) — специалист, который проверяет качество созданного разработчиками продукта и соответствие его изначальным требованиям заказчика. Фактически он берёт на себя ответственность за решение, готов продукт или нет. Чем раньше тестировщик подключится к проекту, тем быстрее будет реализован программный продукт.
Пока разработчики заняты воплощением идеи заказчика, QA-инженер продумывает, что и как он будет тестировать. В идеале заказчик предоставляет спецификацию — список требований к продукту, например, цвет кнопок, всплывающие подсказки, последовательность действий и т. д. На её основе тестировщик создаёт чек-лист для проверки. Затем к каждому из пунктов чек-листа (конкретной функции продукта) он пишет тест-кейсы: перечисляет все шаги, которые необходимо сделать, чтобы проверить работоспособность данной функциональности.
Тестировщик регулярно проверяет работоспособность продукта. Он может это делать с помощью ручного (мануального) или автоматизированного тестирования. Первый способ не требует навыков программирования, в отличие от второго, когда QA-инженер создаёт полноценные программы, предназначенные для тестирования. Все ошибки (баги) он фиксирует в специальной системе, потом передаёт разработчику на исправление. Когда правки внесены, тестировщик снова изучает продукт, ведь пока чинили одно, могли сломать другое. И так до тех пор, пока продукт не будет полностью готов.
Кому подходит профессия тестировщика?
QA-инженер весь рабочий день проводит за компьютером, выискивая баги, и документацией. Усидчивость при такой работе — требование к соискателю номер один. Случается так, что разработчик не исправил указанный баг ни в первый раз, ни во второй. Тестировщику приходится заново писать об этой проблеме, и здесь важно сохранять терпение и самообладание, иначе работать в команде будет тяжело. И, наконец, самое главное качество — ответственность. Именно тестировщик отвечает за качество работы. Если он даст зелёный свет забагованному продукту, то выставит компанию перед заказчиком не в лучшем свете. Так что QA-инженер должен обладать смелостью и решительностью, когда нужно сказать твёрдое «нет» и отправить продукт на доработку, даже если сроки поджимают.
«Почему QA нужны, почему QA важны» рассказывает Татьяна Сандригайло — преподаватель курсов тестирования ПО в Адукар
Что нужно изучить претенденту, если он входит в профессию с нуля?
К слову, существует около 100 видов тестирования. Изучить их все самостоятельно и разобраться в сопутствующей терминологии очень сложно. А ещё почти вся актуальная информация представлена на английском языке. Как быть в таком случае? Обратиться к специалистам, которые научат азам профессии и помогут сделать первый шаг в IT. Но, прежде чем сменить профессию, стоит хорошенько разобраться, подходит ли вам эта работа.
Попробуй найти все баги на картинке. А ответ ищи в видео нижеОксана Скиндер, QA-директор iTechArt, поделится историей тестировщика Аркадия. Ещё спикер поможет протестировать ваши склонности к профессии QA-инженер
Что дают курсы тестирования ПО?
Обычно курс тестирования длится 3−4 месяца. За это время слушатели успевают изучить базовые принципы и стратегии работы с конкретными техниками тестирования, документацией, багами, базами данных, web-сервисами. На выходе человек умеет составлять различную тестовую документацию (тест-планы, чек-листы, тест-кейсы, баг-репорты, отчёты о результатах тестирования), использовать различные методы и приёмы тестирования, анализировать результаты тестирования и оценивать качество ПО, тестировать мобильные, веб-ориентированные приложения и веб-сервисы.
Присмотреться к курсам и преподавателю можно на пробном занятии, которое проводится для будущих слушателей бесплатно.
На вводном занятии мы обсуждаем, какими личностными качествами должен обладать будущий тестировщик, рассказываем о том, какие навыки можем дать в рамках нашего курса и какие навыки необходимы человеку, желающему работать специалистом по тестированию. Также мы рассказываем о том, что такое тестирование и его основные принципы.
Бажена Ровнейко, Team lead, Senior QA Engineer в компании IT Top и преподаватель курсов тестирования ПО Адукар
Чтобы учёба на курсах была продуктивной, мало посещать занятия, ещё придётся выполнять домашнее задание, готовиться к контрольным, а в конце пройти итоговый тест. Зато тех слушателей, которые успешно окончили курс, Адукар рекомендует в компанию-партнёр. Перспектива привлекательная, не так ли? Но когда есть семья и основная работа, не просто сидеть на уроке, а ещё разбираться в том, что говорит преподаватель, удаётся не всем.
Надеемся, этот материал помог составить общее впечатление о профессии тестировщика и соотнести свои качества с требованиями IT. Если вы хотите стать QA-инженером, осталось записаться на пробное занятие в Адукар.
Спасибо, что дочитал до конца. Мы рады, что были полезны. Чтобы получить больше информации, посмотри ещё:
9 сервисов, которые делают работу программиста эффективнее
Тест на профориентацию. Станешь ли ты программистом?
Актуальные вакансии и стажировки в ИТ для джунов
Не пропускай важные новости и подписывайся на наш YouTube, ВК, Instagram, Facebook и уведомления на adukar.by.
***
Если хотите разместить этот текст на своём сайте или в социальной сети, свяжись с нами по адресу [email protected]. Перепечатка материалов возможна только с письменного согласия редакции.
«Стал „тестировщиком“ за два дня» | GeekBrains
Илья Рейзнер — о поиске работы, ожиданиях компаний, тестовых заданиях и профессиональном развитии QA-специалиста
https://d2xzmw6cctk25h.cloudfront.net/post/2088/og_image/07d8f15942d50b724346116b993c6fc3.png
Привет! Меня зовут Илья, и с сентября 2013 года я занимаюсь ручным тестированием. Сейчас работаю ведущим тестировщиком в Bell Integrator. В этой статье я расскажу, как начать карьеру в сфере QA, чем высокооплачиваемый тестировщик отличается от обычного и как прокачаться, чтобы тебя ценили. Главным образом буду говорить о ручном тестировании, но затрону и автоматизированное.
Как я сменил профессию за два дня
Я получил диплом экономиста, пару лет поработал по специальности — и понял, что заниматься этим я себя заставляю. Ушёл. Около года провёл в продажах и параллельно искал, чем заниматься дальше. И вот однажды я вспомнил кое-какую статью про тестирование и разговор со знакомым, который тестировал телефоны Motorola.
В порядке эксперимента я обновил резюме на hh.ru — сменил желаемую должность на «тестировщик». В тот же день получил приглашение на собеседование и совет, что подучить. Основное — виды и уровни тестирования, реляционные базы данных и классы эквивалентности (одна из техник тест-дизайна). Я вбил это в поисковик и попал на сайт protesting.ru. Информация там структурирована и хорошо изложена. Почитал, вник.
На следующий день я успешно прошёл собеседование в компанию с броским названием S&T International. Так начался мой путь в тестирование и IT в целом. Но не всё так просто. Получить работу — ещё не значит стать крутым специалистом. Поэтому самое интересное началось дальше.
Ожидания работодателей
Основная задача тестировщика — дать актуальную информацию о качестве продукта. Это правильный ответ на один из главных вопросов собеседования 🙂
Проверять качество ПО помогают специальные инструкции — тест-кейсы. В них подробно описан каждый шаг и ожидаемый результат. Тестирование по кейсу — работа, которую часто доверяют джуниорам, особенно на крупных проектах.
Чем быстрее ты работаешь и чем лучше понимаешь, в какой последовательности проходить тесты, тем больше тебя ценят.
Чтобы получать высокую зарплату, надо знать теорию тестирования, техники тест-дизайна, терминологию, SQL-запросы. Очень важно представлять себе сферу деятельности компании. Главные заказчики IT-услуг сейчас — банки, страховые фирмы и телеком. Идёшь работать в банк? Подучи банковские термины. А если собираешься тестировать оборудование для нефтегазового сектора, на одной теории далеко не уедешь. Придётся изучать «железо».
Кроме того, нормальный тестировщик умеет пользоваться командной строкой, понимает, что такое клиент-серверная архитектура и реляционные базы данных, зачем нужен XML и какую роль он играет в работе ПО.
О чём спрашивают на собеседовании
Крупные интеграторы любят гонять кандидатов по теории и терминам. Это у них как сито. Чем больше правильных ответов, тем выше твой балл и зарплата, на которую ты можешь претендовать.
Но иногда простые вопросы могут поставить в тупик даже опытного пользователя. Например, какие поля обязательны при заведении бага. Новичку нет смысла такое заучивать — он работает в баг-трекере, где обязательные поля проверяются автоматически. Пока не заполнишь — данные не отправишь. А опытный тестировщик, который всё это вносит уже не глядя, может зависнуть — как автослесарь, которого спросили, что такое машина.
Чтобы войти в профессию, мне хватило материалов с protesting. А в более продвинутых темах я разобрался, обучаясь в GeekBrains по профессии «Тестировщик ПО». Например, освоил более сложные техники тест-дизайна, чем классы эквивалентности. Эти знания пригодились.
Приведу пример «до» и «после». На телефонном собеседовании в крупном банке меня спросили, какие техники тест-дизайна я знаю. Ответ их не устроил, но мне дали ссылку на тест, где надо было набрать от 65% правильных ответов. Увы, в тот раз мне даже поисковик не помог — настолько хитро были поставлены вопросы. А вот после курсов этот же тест на другом собеседовании я уже прошёл и получил предложения от нескольких отделов того же банка. Правда, всё равно к ним не пошёл — отпугнули бюрократией. Но это другая история.
Ясное дело, одной теории мало. Опытный интервьюер спросит, как работает техника на практике и почему в данной ситуации ты предлагаешь именно её. Кроме того, важно уметь пользоваться специализированным ПО. Возможно, кто-нибудь оценит твою обучаемость и поверит, что ты быстро освоишь новые инструменты, но чаще работодатель ищет готового специалиста.
Примеры тестовых заданий
В банке мне дали схему XML-сообщения в виде таблицы с описанием полей и указанием, обязательны ли они. Нужно было проверить все варианты отправки сообщения.
В крупной розничной сети предложили более масштабное задание. Показали схему работы кассового складского оборудования и тестовую БД. Требовалось установить СУБД Firebird, написать несколько SQL-запросов для формирования выборки и составить тестовую модель по схеме работы.
Но обычно на собеседованиях рисуют упрощённую схему и просят описать, как ты будешь это тестировать. Могут предложить нештатную ситуацию: «Не успеваем всё протестировать, но сроки сдачи переносить нельзя». Или: «За день до релиза обнаружены критические баги. Можно ли выходить в продакшен?». На первый вопрос единственного правильного ответа нет, а на второй — «Нельзя».
Другой пример — задание на автотестирование от разработчика ПО. Надо написать на Python класс Deposits, который парсит страничку www.banki.ru и собирает информацию из блока «Предложения месяца > Вклады». Результат должен выглядеть как таблица, где напротив названий вкладов — проценты. Дополнительно просят реализовать дочерний класс, который наследуется от Deposits и подбирает наиболее и наименее выгодный вклад.
Самое обстоятельное собеседование было в HeadHunter. Начали с большого предварительного интервью. Спрашивали, почему занимаюсь тестированием и каким проектом горжусь. Просили рассказать о самом интересном (!) случае из практики, а ещё — в чём состоит тестирование, что такое качество, какой у меня опыт автоматизации, какие пять команд Linux я чаще всего использую в работе. Ещё просили назвать две-три книги или статьи по тестированию и программированию, а затем рассказать, что я из них вынес. На очном собеседовании давали тесты по SQL-запросам и командам Linux.
Кстати, когда вас спросят, какие книги по тестированию вы прочли, рекомендую назвать «Быстрое тестирование» (Калбертсон, Браун, Кобб) и «Тестирование DOT COM» Романа Савина. Чтобы понимать, о чём речь, прочтите хотя бы вступление к каждой из этих книг, а лучше — первую главу 🙂
Этапы развития и как их проходить
Есть несколько уровней мастерства тестировщика.
Джуниор. Ты проходишь подробные тесты, составленные кем-то другим. Задумываешься, на чём они основаны, и внезапно открываешь для себя существование документации. Отныне ориентируйся на неё! Даже если тест-кейс ей противоречит.
Тестировщик. Ты тестируешь программу по документации и ориентируешься на описание функциональности. Тест-дизайнеры как отдельные работники — редкость, поэтому ты сам придумываешь, как протестировать приложение, чтобы отловить все возможные ошибки. Сам пишешь подробный план тестирования и тест-кейсы. Дальше группируешь тест-кейсы логически и раздаёшь джуниорам. Это уровень старшего и ведущего тестировщика.
Исследователь. Самый сложный уровень — exploratory testing. Нет ни тестовой модели, ни подробной документации (в лучшем случае — список задач для разработчиков). Задача — найти все баги ПО. Тут придётся включить фантазию и моделировать работу конечного пользователя. Да не простого, а пользователя-ломателя.
Иногда ты будешь сталкиваться с трудностями тестирования в ограниченной среде. Придётся проверять, как работает твоя программа при получении сообщений из другой системы, к которой у тебя нет доступа. Можно координироваться с коллегами из других систем либо справляться самому. Во втором случае надо уметь пользоваться вспомогательным ПО типа SoapUI и Postman.
Но прежде всего надо разобраться:
- как устроена клиент-серверная архитектура,
- как формировать и обрабатывать интеграционные сообщения,
- как запускать их из командной строки.
Полезно уметь подключаться к серверу или удалённой машине с помощью программ типа WinSCP. Но они только показывают файлы (в том числе логи), а для отправки команд серверу понадобится изучить ещё и Putty либо аналог.
Плюс надо понимать, что такое командная строка, и знать основные команды Linux. Открою секрет: на первых порах можно ограничиться пятью командами, но их придётся запомнить.
Условия карьерного роста
Перефразируем дядю Паркера: «Большая зарплата влечёт большую ответственность» 🙂 В самом начале карьеры, когда что-то не работает, можно поднять лапки и закричать «караул!». Мол, это вопрос не на мою зарплату. Но это плохой способ.
Если хочешь профессионального и зарплатного роста, учись определять, на чьей стороне проблема. Вызвана ошибка сбоем в работе программы или дело в забитом кеше, зависшем сервере, связанном приложении? Порой надо банально проверить соединение с интернетом.
Если «ничего не работает», надо понять, что не работает в первую очередь. И знать, кому звонить и писать, куда бежать с этими неполадками. Я всегда держу под рукой список фамилий и контактов по зонам ответственности.
Важно уметь отвечать на вопросы. Это особенно пригодится, когда придётся вводить в курс дела новичков или подрядчиков-аутсорсеров. А ещё — на презентациях для представителей бизнеса, которые вы наверняка будете проводить (или как минимум в них участвовать).
Горизонталь и вертикаль
Профессиональный рост бывает вертикальным и горизонтальным.
Для вертикального роста надо развивать административные и управленческие навыки, но и про техническую часть не забывать. Пусть ты уже не ловишь баги лично, но как руководитель должен понимать, кому передать задачу и как распознать обман, когда подчинённые говорят: «Сделали всё, что могли, но это надо тестировать четыре дня».
Горизонтальный рост требует выбора. Если ты хочешь развиваться в ручном тестировании, надо глубоко вникнуть в устройство системы и работу программы. Освой все инструменты ручного тестирования — не зацикливайся на одном. Дальше на этом пути возможен рост до аналитика.
Второй вариант — изучить программирование и идти в автоматизацию. Правда, уже есть ПО, где автотесты можно делать без кода. Но привычка решать всё нажатием кнопки снижает потолок развития специалиста. В непонятной ситуации придётся бежать за помощью к тому, кто знает и понимает больше.
В автоматизированном тестировании свой инструментарий, но для успешного роста надо разбираться в системе и архитектуре не хуже «ручника». В дальнейшем с этой дорожки можно свернуть в разработку.
Помимо автоматизации есть ещё нагрузочное тестирование. Тут тоже надо быть немного программистом (писать скрипты) и аналитиком — уметь анализировать результаты.
Третий путь — совместить предыдущие варианты и стать универсальным специалистом. Для этого необходимо подтянуть навыки программиста и аналитика.
Я хочу попробовать себя в Data Science. Тут очень пригодится школьный и университетский курс математики и статистики.
О стереотипах
Некоторые руководители ошибочно полагают, что тестировщик — это личинка программиста или аналитика. Они с недоверием относятся к сотруднику, который «застрял» в тестировщиках. Но всем не угодишь. Тут к месту вспомнить басню про мальчика, мельника, осла и общественное мнение.
О личных качествах тестировщика
Мне запомнилась статья, где сказано, что хороший тестировщик «обладает ломательной психологией» 🙂 Ещё говорят, что он должен понять то, чего не понял разработчик. Лично я считаю, отличие здесь — в направлении внимания к продукту. Разработчик глубоко знает узкую тему, а тестировщик меньше роет вглубь, но смотрит шире.
Ведущий или главный тестировщик представляет, как работает система в целом и как взаимодействуют её компоненты. В этом он похож на архитектора и системного аналитика. Но архитектор знает технические особенности на уровне разработчика и лучше, а аналитик составляет документацию и доносит до разработки требования заказчика.
Очень важное для тестировщика качество — твёрдость характера. В спорах с разработчиками и начальством часто приходится настаивать на своём. Коллеги могут быть недовольны — но если уступить, крайним при проблемах в промышленной эксплуатации всегда будет тестировщик! Об этом стоит помнить.
Как всякий айтишник, тестировщик должен быть любознательным и дотошным, ведь ему предстоит всю жизнь учиться. Немного перфекционизма не повредит.
Хотите узнать больше о выпускниках курсов и факультета тестирования ПО GeekUniversity? Вот их истории:
QA Tester Описание работы — JobHero
Также известные как специалисты по обеспечению качества или инженеры по обеспечению качества программного обеспечения, тестировщики QA в первую очередь отвечают за проверку новых программных продуктов, таких как продукты для игровых систем или мобильных приложений, на наличие дефектов или проблем. Тестировщики QA проводят различные тесты программного обеспечения, чтобы убедиться, что оно соответствует всем стандартам и рекомендациям и готово к продаже потребителям. Они выявляют проблемы и при необходимости запускают программы отладки. Тестировщики QA также создают отчеты, работают с разработчиками программного обеспечения над исправлением проблем и при необходимости обновляют базы данных.
QA-тестеры работают в основном с компаниями, занимающимися разработкой программного обеспечения. Бюро статистики труда (BLS) сообщает, что те, кто работает в области разработки программного обеспечения, в том числе тестировщики QA, могут ожидать увеличения занятости на 24% в период с 2016 по 2026 год. Считается, что продолжающаяся тенденция разработки новых приложений и программного обеспечения играет важную роль в этом прогнозе.
Обязанности и ответственность тестировщика QA
Опыт работы
| Тестировщик QA 2014 — настоящее время Avani Tech Solutions — Cedar Rapids, IA |
|---|
Создал отчеты по контролю качества и зарегистрировал тикеты об ошибках на основе результатов Циклы тестирования QA. |
Предоставление разработчикам и менеджерам продуктов обратной связи по UX на основе результатов тестирования. |
Выполнено Front-end тестирование веб-приложений с использованием Selenium и JMeter. |
Созданные планы тестирования, требования, сценарии и тестовые данные для использования во время тестирования. |
Тестировщики QA должны выполнить несколько задач, чтобы соответствовать ежедневным требованиям этой профессии. Мы внимательно изучили несколько списков вакансий и обнаружили, что следующие обязанности входят в число тех обязанностей, которые наиболее часто указываются для тестировщиков QA:
Запуск тестов для нового программного обеспечения и приложений
В своей основной роли тестировщики QA проводят различные тесты для новых программных продуктов. чтобы обеспечить соответствие программ всем спецификациям и требованиям.Они выявляют любые проблемы и запускают программы отладки для их устранения. После решения проблем тестировщики QA проводят дополнительные тесты, прежде чем продукты будут выпущены для продажи потребителям.
Записывать отчеты о дефектах и проблемах
Тестировщики QA записывают всю информацию о дефектах, создавая и распространяя отчеты, в которых описываются типы обнаруженных дефектов и шаги, предпринятые для решения этих проблем. Ведение документации, такой как журналы изменений, касающейся дефектов программного обеспечения и приложений, помогает тестировщикам QA распознавать подобные проблемы в будущем и обеспечивать быстрое решение.
Помогите разработчикам программного обеспечения в процессе проектирования
Тестировщики QA применяют свои знания на ранних этапах процесса разработки программного обеспечения. Они работают в тесном сотрудничестве с разработчиками, чтобы распознавать потенциальные проблемы в работе, оценивать риски и решать проблемы до того, как новое программное обеспечение будет завершено.
Навыки тестировщика QA
Навыки
Обширный опыт языков сценариев QA и модульных тестов кодирования. |
Знание работы компании-разработчика программного обеспечения и здравоохранения. |
Хорошее понимание показателей процесса и ручного тестирования. |
Владеет тестированием мобильных игр и веб-приложений. |
Тестировщики QA должны продемонстрировать сильные аналитические, организационные навыки, навыки решения проблем и письменного общения для выполнения основных обязанностей в этой профессии. Успешные тестировщики QA — это целеустремленные, целеустремленные люди, которые могут работать в тесном контакте с командами дизайнеров, инженеров и другого соответствующего персонала, а также могут работать независимо по мере необходимости.Они должны демонстрировать здравый смысл и уметь принимать решения, способные проявлять сильные навыки управления временем. В дополнение к этим возможностям тестировщики QA должны обладать следующими навыками и способностями:
- Применение программ тестирования к новому программному обеспечению
- Выявление ошибок в новых системах и понимание того, как их устранять
- Создание отчетов с описанием дефектов и их устранения
- Обеспечение того, чтобы новые программные продукты готовы к использованию потребителями
- Работа с группами разработчиков для предотвращения проблем с новыми продуктами
Профессиональные инструменты тестировщика QA
Для выполнения всех рабочих задач тестировщики QA обычно полагаются на несколько инструментов в течение рабочего дня.Если у вас есть желание работать тестировщиком QA, вы должны хорошо разбираться в следующем:
- Инструменты управления дефектами — важно, чтобы тестировщики QA имели полные знания о различных инструментах управления дефектами, таких как Microsoft Test Manager (MTM) и JIRA
- Системы управления базами данных — используются для написания запросов и обновления баз данных после отладки или исправления дефектов продукта
- Языки программирования — базовое понимание концепций программирования и языков, таких как C # и Java. полезно для тех, кто занимается этой профессией
Обучение и подготовка тестировщиков QA
Большинство работодателей предпочитают, чтобы кандидаты на должность тестировщика QA имели степень бакалавра, особенно в области компьютерной информатики или информатики.Хотя обычно это и не требуется, особые сертификаты, такие как thos
.
| Введение | Отказ от ответственности | |||||||||||||
 | |||||||||||||
 | |||||||||||||
 | |||||||||||||
 |
| ||||||||||||
 | |||||||||||||
 | |||||||||||||
 | |||||||||||||
 |
| ||||||||||||
 | |||||||||||||
 |
| ||||||||||||
— Стены кирпичные есть не случайно | |||||||||||||
 |
| ||||||||||||
 | |||||||||||||
Послесловие | |||||||||||||
Вопросы и ответы о QA | |||||||||||||
.