Профессия «qa-инженер»

Quality Assurance Approaches

Failure Testing: Also referred to as stress testing, failure testing is a way to push a product to its limits by increasing vibration, temperature, humidity, etc., to expose inherent weaknesses, and then use those findings to improve the product to uphold a higher standard.
Statistical Control: This type of quality assurance is based on analyses of objective and subjective data to track quality data, and then chart it against a common cause variance.
Total Quality Management: Here the quality of the product is dependent on the participating constituents, some sustainable and controllable, others not. If the specification does not match its true quality requirements, then the quality is not guaranteed.
Models and Standards: This is an international standard that has general requirements for competence. There are tests to carry out, 15 management requirements and 10 technical requirements, in a laboratory that is accredited.
Company Quality: This concept came about in the 1980s and focuses on all departments approaching quality lead by management to develop a quality improvement process. This is done through controls, job management, process, performance, knowledge, skills and experience, integrity, confidence and infrastructure.

«Непроактивность»

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

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

Субъективно, я был достаточно неплохо подготовлен для джуна, но не имел большого практического опыта. Это плюс пара ошибок по теории привело к тому, что на первом собесе мне сказали: «Не быть тебе QA!». Но! Я почти сразу попросил дать мне второй шанс. Следующие 2 недели я не только зубрил почти всё что можно, но и активно практиковался в тестировании полей, оплат, покупок, а также составлял тест-кейсы, чек-листы и тому подобное.

Но! Придя второй раз, я столкнулся далеко не с джуниорскими вопросами: спрашивали про пентестинг и всё такое. Кажется, со мной не захотели возиться. Но! Я написал другому тимлиду тестирования и сразу договорился о третьем собеседовании.

Мы просто по-человечески общались: я ответил на все вопросы, кроме одного, и был точно уверен, что меня возьмут! А в итоге «Прости, но взяли человека с опытом». Если до этого момента я не понимал, что такое «мораль ниже плинтуса», то вот тогда вкусил это в полной мере.

Моя проактивность резко упала. Я даже почти перегорел. Однако… Через месяц я попросил о четвёртом собеседовании. И в этот раз решил пойти на отчаянный шаг — попросился работать в QA на парт-тайме, хотя бы бесплатно. И ребята согласились. Теперь моей задачей было совмещать работу в техподдержке (8 часов в день) и параллельно работать Trainee QA на подхвате (4 часа в день). Я начал писать тест-кейсы, майндмэпы, тестировать что-то простое вроде правок в вёрстке, проходить тест-ран из 4000 кейсов. Сказать, что я был счастлив, — ничего не сказать.

Приходилось потеть по 12 часов в день 5 (а иногда и 6) дней в неделю на протяжении месяца, но это того стоило. Когда испытательный срок длиною в месяц подошёл к концу, меня взяли в QA! Я даже был удивлён, потому что успел продолбать один критикал, но ребята сказали, что я не знал продукт, и поэтому они дали мне шанс всё исправить.

QA для меня было неизведанной областью, глаз не успел замылиться — и я тут же увидел колоссальный фронт для нововведений. Естественно, процентов 90 моих предложений выкидывали в мусорку. Но хотя бы аргументированно 🙂 Именно конструктив добавлял ещё больше сил генерировать идеи, к которым в итоге нельзя было подкопаться.

Из-за моего рвения постоянно улучшать процессы меня перевели в другой отдел, я стал тимлидом команды тестирования. Около года я «лидил» команду ручного тестирования, но параллельно сам проявил инициативу и совершенствовался в автоматизации, в чём мне очень помогал коллега Андрей AndrewQA777 Шальнев. Ну а год спустя я всё-таки решил идти в хард, поэтому перешёл на фуллтайм автоматизацию. Нетрудно догадаться, что в автоматизации мне тоже сиделось крайне неспокойно: в свободное время я начал обучать других ребят автотестам, ревьюить код коллег, советовался с разработчиками, как лучше что-то написать. В какой-то момент оказалось, что я по факту руководил уже 5 проектами в автоматизации. Я вырос из «суетолога» в лида, который может аргументированно проталкивать хорошие процессы и внедрять их. Конечно, не всё сразу получалось, т.к. в начале были проблемы с расфокусом на задачах, но я научился планировать и приоритизировать их. После этого лиды всей гильдии тестирования пришли к выводу, что пора отдать мне все проекты автоматизации, чтобы улучшения происходили повсеместно.

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

Что такое тест

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

Профессия инженер-проектировщик

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

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

2.И, во-вторых, он наблюдает за поведением программы и сравнивает то, что он видит с тем, что ожидается.

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

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

Что делает тестировщик

Профессия инженер по охране труда

Тестировщику дают продукт и требования к нему (документацию). Он всё это изучает и сопоставляет. Придумывает, как это всё тестировать. Его задача — проверить, чтобы продукт исполнял возложенные на него обязанности по документации, а потом — проверить всякие нештатные ситуации и предложить улучшения.

Само тестирование происходит по множеству разных сценариев. Например, так:

Тестировщик открывает продукт как пользователь и проходит все стандартные сценарии — как будет происходить у 80% всех людей. Все баги фиксирует.

Можно попробовать взломать продукт: вместо имени ввести код; добавить в корзину бесконечное количество товаров; добавить в корзину −1 (минус один) товар; добавить в корзину больше 40 тысяч товаров (и перегрузить переменную счётчика товаров); поискать в строке поиска «Войну и мир» (полный текст).

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

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

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

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

Кем лучше быть?

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

Чтобы получить прикладные навыки тестирования, приходи на наши курсы. Преподаватели ИТ-курсов Адукар — это практикующие специалисты, которые с радостью научат всем тонкостям профессии.

Для того, чтобы стать QA тебе необходимо поработать над soft-skills, углубиться в специальную литературу и постоянно учиться у профессионалов

Обрати внимание на подборку книг, которая поможет тебе разобраться в тестировании ПО и QA

Спасибо, что дочитал до конца. Мы рады, что были полезны. Чтобы получить больше информации, посмотри ещё:

Не пропускай важные новости и подписывайся на наш YouTube, ВК, Instagram, и уведомления на adukar.by.

***

Если хотите разместить этот текст на своём сайте или в социальной сети, свяжись с нами по адресу info@adukar.by. Перепечатка материалов возможна только с письменного согласия редакции.

Принципы тестирования

Тестирование программного обеспечения – креативная и интеллектуальная работа. Разработка правильных и эффективных тестов – достаточно непростое занятие. Принципы тестирования, представленные ниже, были разработаны в последние 40 лет и являются общим руководством для тестирования в целом.

1. Тестирование показывает наличие дефектов

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

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

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

2. Исчерпывающее тестирование невозможно

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

3. Раннее тестирование

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

4. Скопление дефектов

Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.

5. Парадокс пестицида

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок.

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

И еще несколько важных принципов:

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

Особенности профессии

Функциональные обязанности QA-инженера:

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

В чем проблема?

Одна из главных причин возникновения ситуации, описанной выше, — это отсутствие культуры разработки, в которой каждый разработчик несет ответственность за написанный им код. А даже минимальная ответственность понимает под собой необходимость удостовериться в работоспособности кода прежде чем радостно восклицать: “Моя работа готова!”.

Eye Driven Development является самым простым способом удостовериться в работоспособности кода, но не самым оптимальным. Прост этот способ тем, что не предполагает практически никакой интеллектуальной работы: мы тестируем руками приложение, сервис, класс и т.д. с точки зрения конечного пользователя, не рассматривая граничные значения, классы эквивалентности, негативные сценарии, сценарии с разными уровнями permissions и прочее. Такой способ не дает быстрой обратной связи при разработке, не позволяет проверить сущность на разнообразной выборке данных, занимает много времени и не улучшает качество продукта.

Наиболее оптимальный способ — это написание автотестов на разрабатываемый код

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

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

О ролях

В отделе качества каждый выполняет свою роль и, если расставить роли по сложности функционала и уровню ответственности, это выглядит так:

Тестировщик отвечает за прохождение чек-листов, тест-кейсов, проверку и документирование дефектов, разработку документации;
Quality Control, в дополнение к обязанностям тестировщика, анализирует результаты тестирования и качество билдов, выявляет причины отклонений;
Quality Assurance анализирует весь проект и процессы, ищет решения, превентивно работает над улучшением качества продукта.

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

Пример “Проект “Коробка”:

Какие бывают

В ИТ-среде в связи с тестированием и качеством принято три обозначения:

QA — quality assurance, самый главный по качеству;QC — quality control, контролёр качества;Tester — тестировщик.

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

QA — это тот, кто думает о качестве продукта в целом, причём не только о конечном коде, но и всего процесса разработки. Например:

Как понять пользовательские сценарии, в которых вероятнее всего возникнут ошибки? Как их собрать? Как систематизировать? Как ничего не упустить? (Например, как понять, какие именно предметы люди могут догадаться засунуть в микроволновку, и как защититься от идиотов, которые засунут туда динамит?)Как соединить запросы людей, требования бизнеса и реальные возможности продукта с точки зрения качества? Что если наш продукт совсем не делает то, чего пользователи могут ожидать? Например, если они будут сушить в микроволновке кошку — это чья проблема? Будем ли мы с этим что-то делать?Кто, как и в каком порядке будет исправлять ошибки? Как мы будем повторно тестировать места с ошибками?Что и как тестировать от версии к версии программы, чтобы это было достаточно быстро, но не в ущерб качеству?

Можно представить, что QA — это директор по качеству, главный человек на пути у багов. Он не менее важен, чем главный архитектор или ИТ-директор. Многие его функции могут пересекаться с функциями других ИТ-директоров.

QC — это тот, кто сфокусирован на тестировании самого продукта:

Что именно тестируем? Какие функции, кнопки, состояния, сценарии?Какие результаты тестирования нам нужны? Какие исходы правильные, а какие — ошибки?Как автоматизируем тесты? Что нужно обязательно пройти ручками?Как синхронизировать работу нескольких тестировщиков? Как распределить задачи, области, слои?

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

Тестировщик — это тот, кто тестирует продукт: проходит его ручками или пишет автоматические тесты; описывает баги; общается с разработчиком по поводу этих багов; заново тестирует исправленное.

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

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:1. Обзоры (Review)2. Статический анализ (Static Analysis)

Обзоры

Обзоры (Review) – проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Это могут быть требования, дизайн, тестовые случаи и так далее.

В свою очередь обзоры делятся на:

Неформальные. При неофициальном рассмотрении создатель документов показывает содержание документов аудитории. Каждый присутствующий высказывает свое мнение, что позволяет выявить недостатки на ранней стадии.
Сквозные просмотры (Walkthroughs). Выполняются опытным человеком или экспертом для проверки отсутствия дефектов, с целью предупреждения возникновения проблем на этапе разработки или тестирования.
Экспертная оценка. Означает проверку документов для выявления и исправления дефектов. В основном это делается в команде.
Инспектирование ПО. Это, в большинстве, проверка документа вышестоящим органом, например, проверка требований к программному обеспечению.

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

Статический анализ состоит из 3-х частей:

Поток данных.
Контроль потока (как выполняются операторы или инструкции).
Цикломатическая сложность (измерение сложности программы, которое в основном связано с количеством независимых путей в графе потоков управления программы).

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

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

Примерами ошибок, которые потенциально можно выявить с помощью автоматического статического тестирования, могут быть:— утечки ресурсов (утечки памяти, неосвобождаемые файловые дескрипторы и т.д.),— возможность переполнения буфера (buffer overflows),— ситуации частичной (неполной) обработки ошибок.

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

В рамках этого подхода тестированию могут подвергаться:

Документы (требования, тест-кейсы, описания архитектуры приложения, схемы баз данных и т.д.).
Графические прототипы (например, эскизы пользовательского интерфейса).
Код приложения (что часто выполняется самими программистами в рамках аудита кода (code review), являющегося специфической вариацией взаимного просмотра в применении к исходному коду). Код приложения также можно проверять с использованием техник тестирования на основе структур кода.
Параметры (настройки) среды исполнения приложения.
Подготовленные тестовые данные.

Плюсы и минусы

Преимущества статического тестирования

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

Недостатки статического тестирования

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

Недооценка себя

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

Полгода я усердно работал, изучал что-то новое, уже мог довести какие-то проектные задачи до логического завершения. Потихоньку вставал вопрос о зарплате, потому что я выполнял задачи быстрее, чем раньше, брал более сложные кейсы, уже немного менторил (обучал сотрудника автоматизации тестирования). Мы договорились с моим лидом, что составим мне PDP (план личного развития) на 3 месяца и после его выполнения обсудим зарплату.

PDP заключался в доработке фреймворка автотестов (внедрение API-тестов в код), адаптации автотестов под тестовые окружения и расширении покрытия проекта автотестами. Я предоставил подробный отчёт, что покрыл, как это сделал, где добавил стабильности. Но после очередного 1-на-1 с тимлидом я узнал неприятную новость для всего проекта: нам жестко урезают бюджет, полностью останавливают найм новых сотрудников и, естественно, на повышение зарплаты средств нет и подавно. Я расстроился, но решил попробовать снова договориться о новом PDP, тоже сроком на 3 месяца. Все пункты я сделал ещё до конца срока PDP, но в итоге снова узнал, что бюджета на повышение ЗП не было.

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

На новом месте я сразу сказал, что для меня важны обязательства не только со своей стороны, но и со стороны проекта, в котором я работаю. И на меня сразу заложили бюджет на повышение ЗП на год. Я знал, что, выполнив поставленные задачи, получу то, что заслужил. Так и случилось. Happy end 🙂

Мораль этой истории следующая: надо любить то, что ты делаешь, но и не забывать любить себя.

Как стать QA-аналитиком

Итак, потолок достигнут, вы проработали мануальным тестировщиком один-два года и ощутили, что ваше предназначение — это именно аналитика, а не DevQA. Предлагаем действовать по такому плану:

1. Возьмите ознакомительный курс по аналитике и почитайте литературу:

К. Вигерс, Д. Битти «Разработка требований к программному обеспечению»;
А. Коберн «Современные методы описания функциональных требований к системам»;
Д. Леффингуэлл «Принципы работы с требованиями к программному обеспечению. Унифицированный подход».

2. Проанализируйте проект, на котором работаете сейчас.

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

3. Подойдите к менеджеру проекта с конкретным предложением: «Я хочу развиваться как QA-аналитик, в связи с этим готов взять на себя следующие задачи…»

Именно такой подход — самый правильный. Часто сотрудники — и не только из QA — ставят вопрос иначе: «Я хочу развиваться, скажите мне, как». Это плохое начало.

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

Во-вторых, формулируя вопрос открыто, вы вообще ставите под сомнение свою способность к аналитике, ведь в этой профессии очень важно четко строить вопрос таким образом, чтобы менеджеру (а в будущем — клиенту) оставалось ответить лишь «да» или «нет».

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

Итак, аналитика — это путь, открытый мануальному тестировщику при следующих условиях:

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

Оплата труда

Ступеньки карьеры и перспективы

Существует 4 уровня квалификации:

Trainee QA Engineer — начинающий специалист.
Junior QA Engineer — специалист, проработавший в должности от 1 до 6 месяцев и имеющий определённые навыки в работе. Знающий, что такое тест-план, тест-кейс, тест-сьют, тест-степ, тест-дизайн в общих чертах, Definition of Done. Имеющий представление о дефектах Severity и Priority. Базовые навыки SQL — селект, упдейт.
Middle QA Engineer — специалист среднего уровня квалификации, со стажем работы от 1 до 3 лет, умеющий работать самостоятельно и консультирующий младший персонал.
Senior QA Engineer — специалист высшей квалификации, выполняющий самые сложные технические задачи широкого спектра, используя разные виды тестирования.

Пройдя эти 4 этапа, работники повышают профессиональный уровень, осваивая новые технологии. Далее профессиональный рост возможен:

в направлении QA team lead — QA-manager — Head of QA department, то есть до позиции начальника смены или направления внутри отдела;
до позиции разработчика, руководителя разработчиков, аналитика, архитектора вплоть до руководителя проекта внутри компании.

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

В ходе карьерного роста можно переквалифицироваться в бизнес-аналитики или программисты, развиваться как управленец в направлении senior project manager — CTO.

Автор статьи Флюра Ягофарова

Как дальше жить?

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

View the discussion thread.

blog comments powered by DISQUS

Как стать QA-инженером?

Среди представителей профессии немало самоучек. Все же для успешного старта карьеры рекомендуется получить высшее образование по профилю «Автоматизация систем обработки информации и управления» или «Информационные системы и технологии». Сотруднику понадобится владение техническим английским языком на уровне Upper-intermediate. Также обязательны навыки работы в Unix/Linux системах, владение SQL. QA-инженер должен знать разные методы тестирования, иметь навыки программирования Java, опыт работы с программой Silk Test или Rational Robot.

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

Quality Assurance Testing

Testing is the process used to execute a system of quality assurance. It is used to detect the problems in a product or service. The importance of testing is obvious: the product or service that is completed improperly is going to dissatisfy the stakeholder, but there can also be safety issues that will put people in harm’s way if not addressed.

Testing requires the following:

Analysis and definition
Design architecture and description
Coding a logic analysis
Change and configuration management
Testing and standard compliance
Release management and release control

The difference between quality assurance and testing is that quality assurance is about the activities designed to make sure the project is conforming to the expectations of the stakeholders, while test is a process to explore a system to find defects. Testing is focused on system inspection and finding bugs, with a product orientation and corrective activity. Testing’s aim is to control the quality, while quality assurance is to assure the quality.