«Недотестированный билдец — всегда печалька». ©
Сократ.
Первая статья на русском языке из серии «Software Development Team Roles» расскажет о QA-инженерах. Профессия этих специалистов в Беларуси молода и все еще находится на стадии формирования. Для того, чтобы узнать о некоторых тонкостях и превратностях данной профессии, мы попросили наших специалистов поделиться с нами жизненными историями, цитатами и личным мнением о своей профессии.
Узнайте больше о QA-инженерах компании Oxagile
Я с детства был тестировщиком.
Как-то на работе я рассказал историю, что в детстве я разбирал все свои игрушки, только чтобы посмотреть, что у них внутри.
Мой коллега программист признался, что делал то же самое.
Тогда я спросил:
— Так почему же ты стал программистом, а не тестировщиком?
— Потому что я потом собирал их обратно, — сказал программист.©
Начнем с того, что тестирование — мегаважная активность в процессе разработки программного обеспечения. Каждый человек, который в ней задействован — целиком и полностью отвечает за качество выпускаемого продукта. Краткая вики-справка:
Тести́рование програ́ммного обеспе́че́ния — процесс исследования, испытания программного продукта, имеющий две различные цели:
• продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;
• выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.
В достижении основной цели QA задействованы как минимум 3 типа специалистов.
QA-engineer — это специалист, деятельность которого направлена на улучшение процесса разработки ПО, на предотвращение дефектов и выявление ошибок в работе продукта.
Внутри процесса QA выделяют процесс Quality Control — контроль качества продукта. QC-специалисты анализируют результаты тестирования и отвечают за выявление и уничтожение дефектов в продукте.
Еще более узкая специальность в рамках QA/QC — тестировщик ПО, который ведет поиск вероятных ошибок и сбоев в функционировании программы, моделирует различные ситуации, которые могут возникнуть в процессе использования программы, и затем документирует найденные дефекты и пути их воспроизведения.
Должность QA-engineer — одна из важнейших ролей в IT, ведь именно QA-engineer решает: готов продукт или нет?
Quality Assurance — это исследование, другой способ мышления, возможность менять продукт и воплощать свои идеи в нем, это упорство и терпение, это быть на страже интересов пользователя, это гибкость.
Даже без технического бэкграунда и с гуманитарным складом ума — при должном усердии можно стать хорошим QA.
По данным dev.by в Беларуси в последние годы увеличилось число специалистов по тестированию и QA. Согласно статистике, из 100% женщин в IT-сфере 34% — QA, в то время как среди мужчин — 11% из тех же 100%.
Один из ведущих специалистов отдела тестирования компании Oxagile отметил основные достоинства QA-инженера:
1) Хороший QA является также хорошим психологом как для заказчика, так и для PM/девелоперов. Поэтому чтение литературы по психологии/языку жестов/невербальном общении — только плюс.
2) Он же владеет информацией/читал о функционировании памяти и различных техниках лучшего запоминания информации (мнемотехники и т д), умеет вовремя остановить свой деструктивизм во благо проекта.
3) Хороший QA понимает, зачем он тестирует каждый конкретный проект, учитывая цели проекта и четко осознает, что разработчик не враг, а друг, что он — это основной базис проекта, без которого не было бы и QA. И, что не маловажно, признает свои ошибки.
Прочитав вышесказанное можно сделать вывод о том, что работа тестировщика местами скучна и не разнообразна. Мы расспросили сотрудников, которые не первый год «варятся» в этой сфере и профессии, и как оказалось, скучать совсем не приходится.
История № 1
Во время активной приемки проекта, суть которого — продажа видео-контента, Лорена (ответственная за приемку приложения) начала проверять работу приложения на production, где и хранился реальный контент. Она выслала баг с описанием: залогинить, открыть adult content и купить фильм. Проблема, по ее словам, заключалась в том, что на 8-й минуте кино для взрослых прерывается… и я начинаю его проверять. Дожидаясь 8-й минуты фильма, я вызвала неподдельный интерес у всех сидящих рядом ребят. Заметив это, развернула монитор СТБ бокса ПМ-у и попросила его активно следить, чтобы видео проигрывалось, а на 8-й минуте я посмотрю что с ним. Итог: проигрывание фильма продлилось более восьми минут, вся.NET команда активно (до сих пор) интересуется моими проектами, а мы поняли, что Лорена — профессионал, потому что ей пришлось просмотреть все видео в том числе и adult, а там не только гомо-фильмы, но и… с животными.
История № 2
Периодически у нас случались проблемы с серверами и тестирование на СТБ боксе блокировалось на несколько дней. В результате я начала печатать на листиках «Зайцев Несудьбы» и приклеивать их к СТБ боксу. Например, «Стейдж упал… не судьба!». «Зайцы» грели и радовали нас все это время, и таким образом мы справлялись с перипетиями на нашем проекте. К сожалению, всю бесценную кипу листиков наш офис-менеджер выкинула через пару лет в своем неудержимом желании почистить мою верхнюю полочку.
История № 3
Сроки спринтов на одном из проектов были довольно жесткие и нам часто приходилось оставаться допоздна. Для того, чтобы намекнуть на наше негодование всем присутствующим, мы включали и слушали музыку на весь офис во время acceptance-тестирования. Чем раньше нам отдавали релиз-кандидат, тем веселее и тише была музыка. Любые задержки в необходимых фиксах, деплоях тестового окружения и тому подобном сказывались на музыке, которая становилась все громче и суровее. Случалось так, что мы заканчивали работу поздней ночью под звучащие на весь офис песни в стиле «наколи мне купола…». Вот таким странным образом мы боролись с системой.
История № 4
Работая над одним проектом от начала и до конца в команде из 5 разработчиков и меня — одного тестировщика, я столкнулся с коммуникационной проблемой в команде. Все мы знаем, что если постоянно указываешь человеку на его ошибки, то волей-неволей к тебе начнут относится предвзято. Поэтому я начал активно налаживать отношения с программистами: начал подкармливать вкусняшками, сообщал каждому о хороших достижениях в работе, о снижающемся числе найденных багов, о том, что быстро реализовал (а) фичу. Напоминал о неравнодушном отношении к проекту; просил сообщать мне о найденных багах. Мы так увлеклись нашим проектом, что у нас появилось название нашей команды и свои шутки. Припоминаю, как наш офис-менеджер часто нервничала, когда приходила к нам в комнату, потому что у нас всегда было тихо во время работы и очень шумно во время брейнсторминга.
«Пойду в девелоперы, пока не подтяну себя как тестировщик». ©
Тестировщики и разработчики
Автоматизированное тестирование ПО — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
В наше время нередко можно услышать фразу о желании «пойти в тестировщики», потому что уровень навыков программирования специалиста пока что недостаточно высокий.
Во-первых, некорректно рассматривать профессию как «проходной двор» и «несамостоятельную», «неполноценную». Во-вторых, таким людям можно посоветовать посмотреть в сторону автоматизированного тестирования. Именно здесь можно насладиться и паттернами, и фреймворками, и 1000+ различными другими технологиями.
Более того, очень часто весьма проблематично найти автоматизатора с хорошим знанием языка программирования, ибо разница в зарплате с девелоперами может быть в 1,5-2 раза выше среднего по рынку.
Преимущества позиции автоматизатора:
• Вы не только создаете, но и «ломаете»;
• Вы сэкономите сотни и тысячи часов работы вашего отдела;
• Вы занимаетесь нагрузочным тестированием, тестированием GUI, функциональным тестированием, вы ищете способы оптимизации, распараллеливания и прочая-прочая, и все это должно быть описано кодом.
Если разработчик реализует «машинную логику», то вы — логику и поведение пользователя, который намного изощренней и коварней.
Нередко можно услышать мнение о том, что «писать автотесты девелоперу станет скучно через две недели». Да, в этом отношении в Беларуси мы немного отстаем. Краткая справка: в компании Google автоматизатор — это позиция на одном уровне с девелопером. Они могут и код писать, и при этом строят continuous integration systems, и, порой знают и умеют больше, чем разработчики. Происходит это потому, что работают они не на одном проекте, а на нескольких, которые могут отличаться всем, вплоть до языка программирования и технологий.
Надеюсь, наши профессионалы в IT-сфере со временем придут к таким же суждениям, и тогда уже никто не будет говорить: пойду в тестировщики, пока не подтяну себя как девелопера. Может, будет даже наоборот: пойду в девелоперы, пока не подтяну себя как тестировщик? : -)
P.S Спасибо за помощь в написании статьи QA отделу компании Охаgile, которые поделились с нами таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.