Много слышали о тестировании и примеряете на себя возможность работы в этой области? Но пока не совсем понимаете, с чем придется работать?
В этой статье мы расскажем вам, кто же такой специалист по тестированию, что делает тестировщик программного обеспечения и с какими рабочими задачами он сталкивается.
На рынке ИТ постоянно появляются новые программы, призванные упростить и улучшить жизнь людей.
И такие продукты обязательно должны проходить проверку на качество перед тем, как станут доступными конечному пользователю.
Именно от тестировщика зависит качество продукта и, как результат, успех проекта на рынке. Кто станет пользоваться приложением, если оно не в состоянии выполнить даже базовые функции?
Поэтому специалист по тестированию является связующим звеном между разработчиком и конечным пользователем и отвечает за полную проверку программного продукта. И делает он это не только для того, чтобы найти и задокументировать все возможные дефекты.
Кроме поиска ошибок, тестировщик на практике проверяет работоспособность всей функциональности программы. Нужно убедиться в том, что простейшие действия пользователей не вызывают сбоев.
К основным обязанностям тестировщика ПО относятся:
Они являются основой профессиональной документации тестировщиков. Тест-кейсы содержат последовательность шагов для проверки работы всей системы, а чек-листы описывают, что нужно протестировать.
В зависимости от поставленных задач специалист по тестированию решает, какие виды тестов применить.
Когда найдена ошибка, ее нужно описать. Делается это для того, чтобы разработчик ПО смог быстро понять, в какой части кода программы кроется ошибка. Сейчас тестировщики вносят все ошибки в баг-трекинговые системы, например, JIRA или TestRail. Для более подробного описания ошибок можно приложить скриншоты экранов или видео.
Еще один шаг – контроль за устранением всех найденных ошибок. В баг-трекинговой системе каждой ошибке присваивается градация серьезности (от тривиальной до блокирующей) и статус в соответствии с этапом жизненного цикла бага (от нового до закрытого).
В процессе контроля за устранением дефектов тестировщик следит за тем, чтобы разработчик ПО своевременно устранял все ошибки и делал соответствующие отметки в системе.
Для ускорения тестирования могут применяться не ручные, а автоматизированные тесты. В таких случаях тестировщик пишет код проверки и запускает его. А программа автоматически выполняет тысячи нужных проверок, при этом сохраняя время тестировщику.
Однако начинающему специалисту не придется выполнять такие задачи, они входят в зону ответственности . Тем не менее, для более быстрого развития карьеры вы можете приступить к изучению основ определенного языка программирования.
Несмотря на относительную молодость профессии тестировщика (не более 20 лет), сегодня сформирован набор требований, которые нужны для старта.
Во-первых, чтобы успешно справляться с рабочими задачами, тестировщик должен иметь прочные теоретические и практические навыки.
К тому же, необходимо обладать рядом специфических качеств. Например, природная любознательность, внимание к деталям, усидчивость, недоверчивость и желание постоянно перепроверять себя.
Еще один важный момент – стремление вносить вклад в развитие новых технологий. Например, сейчас на рынке ИТ акцент идет в сторону автоматизации процессов. И тестировщики осваивают новые для себя аспекты, например, языки программирования.
Таким образом, специалист по тестированию еще и должен следить за развитием новых технологий, чтобы вносить свою лепту в их продвижение.
Чтобы понять, чем бы вы хотели заниматься, для начала нужно ознакомиться с тем, какие виды тестирования существуют.
Все виды тестирования разделяют на две группы:
Помимо видов, в тестировании выделяют еще и уровни, которые показывают над чем ведется работа: над системой в целом или только над одним определенным компонентом.
Всего существуют четыре таких уровня: модульное тестирование, интеграционное, системное и приемочное.
Чтобы на деле увидеть, что делает тестировщик, давайте рассмотрим небольшую практическую задачу.
Необходимо протестировать форму регистрации в социальной сети LinkedIn.
Первое, что нужно сделать, – открыть сайт. Форма для регистрации выглядит следующим образом:
Во-первых, нужно проверить обязательность заполнения всех полей. Для этого нужно, ничего не заполняя, нажать кнопку «Присоединиться». Форма сразу выдает ошибку и выделяет красным те поля, которые необходимо заполнить. В нашем случае – все:
Сразу появилось предупреждение о том, что пароль слишком короткий.
Форма требует указать настоящие данные. Однако это условие относится лишь к имени, о фамилии в тексте формы нет ни слова.
Сразу проверим форму на некорректный ввод только фамилии. В результате появляется сообщение об ошибке. Таким образом мы видим, что по отдельности форма реагирует на некорректный ввод имени или фамилии. А вот при неверном заполнении обоих полей ошибка относится только к имени.
Почему так происходит? Возможно, проблема кроется в том, что форма проверяет лишь первое поле в коде. Или же можно говорить о не совсем верной локализации. Ведь приложение изначально написано для англоязычных пользователей. На английском языке имя и фамилию можно передать как name и last name. А на русском языке могли оставить лишь перевод имени.
Такой дефект можно охарактеризовать как малозначимый (minor), и относится он к пользовательскому интерфейсу.
Проверки на ввод некорректных символов нужно провести для всех полей.
Форма приняла этот адрес и инициировала проверку безопасности. Адрес был введен корректно, структура соблюдена, присутствует символ «@».
Таким образом, мы протестировали форму регистрации для социальной сети и параллельно нашли малозначимый дефект в пользовательском интерфейсе. Напомним, что при некорректном вводе данных в поля «Имя» и «Фамилия» форма просит корректно заполнить лишь имя. Ошибка некритичная, но пользователь может не сразу заметить, что исправить нужно оба поля, а не одно.
Хотите научиться безошибочно распознавать дефекты, правильно их документировать и научиться выполнять основные задачи тестировщика? Курс « » от QA Academy поможет вам погрузиться в профессию, попробовать свои силы на практике, а главное – сделать первый шаг по карьерной лестнице.
Ведь хороший специалист по тестированию ПО всегда будет востребован как дома, так и за границей. Дерзайте!
«Все профессии нужны, все профессии важны». Эти слова Владимира Маяковского остаются актуальными вот уже не одно десятилетие. Сегодня мы поговорим о профессии тестировщика программного обеспечения (или просто тестера). Ты узнаешь, актуальна ли профессия тестера, сколько можно с помощью нее зарабатывать и как этой специальностью можно овладеть.
В мире разработки многие ставят профессию тестера на самую низшую ступень иерархии, а зря. Именно благодаря тестерам в существующем софте относительно мало ошибок - а ведь после того, как софт вышел «из-под пера» программера, ошибок было в сотни раз больше. И это не просто предположение или вымысел. В своей жизни я перепробовал множество профессий - вплоть до руководителя компании. Доводилось бывать и тестером.
9 сентября отмечается День тестировщика программного обеспечения. Праздник хоть и неофициальный, но все же у тестеров есть свой собственный праздник и это говорит о том, насколько важна эта профессия в мире. Именно во всем мире, а не только в мире разработки программного обеспечения. Твою мультиварку или стиральную машину тоже тестировали специально обученные тестеры. Даже боюсь представить, что было бы, если б эти девайсы не были протестированы перед тем, как их пустили в продакшн.
Почему именно 9 сентября? Именно в этот самый день более 70 лет назад ученые из Гарварда проводили тестирование вычислительного монстра под названием Mark II Aiken Relay Calculator. Пусть тебя не смущает слово «Calculator» в названии: вес первого «Марка» точно известен и составлял 35 тонн. Вес второго, думаю, был не намного меньше.
Слово тестировщик, как ты уже догадался, происходит от английского tester - человек, выполняющий проверку чего-либо.
Каких-то пять лет назад считалось, что тестером может быть любой студент 1-2-го курсов. К тестерам относились несерьезно - как к «недопрограммистам». Формат такой работы подразумевал только подработку на время учебы в ВУЗе, а серьезно заработать, будучи тестировщиком, удавалось мало кому.
Итак, сколько зарабатывают тестеры? Могу поспорить, что ответ на этот вопрос тебя интересовал больше всего, раз ты начал читать эту статью. Тестеры со стажем в 2-3 года могут легко заработать около 100 000 рублей в месяц. Минимальная заработная плата составляет от 30 тысяч рублей, средняя около 50-60 т.р. Не буду приводить красивых графиков, приведу две вакансии, которые нашел за 5 секунд на сайте Яндекс.Работа: в первом случае предлагают до 90 т.р. (что вполне нормально), во втором - от 30 до 45 тысяч рублей.
Вообще, если поискать, можно встретить вакансии до 120 тысяч рублей, что даже превышает обещанные мною суммы.
Как видишь, профессия довольно актуальна и при наличии желания и определенных навыков, можно без проблем найти довольно хорошо оплачиваемую работу. Да, это не Газпром, но на жизнь хватит.
Просмотрев с десяток вакансий, могу рассказать хорошие новости. Работать можно, как в офисе, так и дома - выбирай тот способ работы, который тебе привычнее. Если долго добираться в офис, можно без проблем найти удаленную работу со свободным графиком работы. А это означает, что ты можешь учиться в ВУЗе и работать тестером. В этом плане ничего не поменялось. Конечно, на «удаленке» платят меньше, но и условия труда более удобные.
Образование требуется неполное высшее, а вот опыт работы нужен. Чаще всего требуют наличие опыта работы по специальности от 1 года. Вопрос, а где же получить опыт, если везде нужны уже опытные, остается открытым. Впрочем, это беда не только этой профессии, а и любой другой. Зарплата прямо пропорционально зависит от опыта работы - приличные деньги начинают платить тестерам с опытом работы от 2 лет.
Но не нужно думать, что тестеру не нужны никакие навыки, кроме умения нажимать на кнопки! Как минимум нужно:
В обязанности тестера входит:
Как видишь, список требований и обязанностей очень солидный. Надеюсь, теперь ты не будешь думать, что тестер - это просто тот, кто нажимает на кнопки и проверяет, не глючит ли программа.
Какие перспективы могут быть у тестера? Прежде всего, есть перспектива повышения зарплаты по мере роста опыта работы. Сегодня ты получаешь 30-40 тысяч рублей, через два года - почти 100 тысяч. Чем не перспектива? Даже если текущая компания не предлагает тебе такие деньги, всегда можно перейти в другую: опыт работы-то уже у тебя есть.
Другая перспектива - стать программистом. Проработав несколько лет тестером, довольно просто перейти в другую сферу IT: например, «превратиться» в разработчика, аналитика или даже в руководителя. Все зависит от тебя и от твоих интересов.
Несмотря на то, что профессия очень актуальна и есть множество вакансий, в наших ВУЗах такой специальности нет. Если у тебя нет высшего образования, но есть желание его получить, можно поступить на любую специальность, так или иначе связанную с программированием (например, на прикладное или системное программирование), в рамках которой ты сможешь подрабатывать тестером, а затем начать работать программистом.
Но нужно отметить, что обучение в ВУЗе не всегда оправдано, особенно если речь идет о тестерах. Во-первых, учиться в ВУЗе долго. А если у тебя уже есть высшее образование (пусть даже не техническое) и ты хочешь освоить профессию тестера, то вообще нет смысла опять поступать в ВУЗ: на втором высшем ты будешь вынужден 2.5 года посещать лекции. Потерять целых 2.5 года! А если высшего образования у тебя нет, тогда ты можешь потерять целых 5 лет, за которые можно было бы не только освоить эту профессию, но и превратиться в очень востребованного специалиста.
Во-вторых, получив диплом программиста (и потратив на это от 2.5 до 5 лет), ты все равно не сможешь устроиться по специальности: ведь у тебя нет опыта практической разработки, которого в ВУЗах не дают.
В качестве альтернативы можно предложить курсы, позволяющие освоить профессию тестировщика ПО. Например, . Преимущества курсов в том, что ты экономишь и время, и деньги: они длятся всего 2 месяца и обойдутся тебе гораздо дешевле, чем обучение в ВУЗе по специальности «программист». Кроме того, на курсах ты получаешь:
Уже через 4 месяца ты будешь обладать следующими навыками:
А самое главное, тебе не придется ждать несколько лет, а сразу можно будет приступить к работе!
Вообще затраты времени минимальные. Обучение хоть и длится 4 месяца, но проходит онлайн, а это означает, что ты можешь работать/учиться и осваивать параллельно. Нет необходимости ездить куда-то и тратить драгоценное время.
А как же быть, если работодатель требует наличие корочек? Ну, в большинстве случаев оно все же не требуется. Если вышка у тебя уже есть, то в к нему прибавится сертификат, который ты получишь по окончанию курсов. А если высшего образования нет, то ничего страшного: зато у тебя будет весь набор навыков, необходимых для успешного тестирования программного обеспечения. Когда ты проработаешь первый год по специальности, на отсутствие в/о не будет смотреть вообще никто - главное, что опыт и навыки уже есть. Кроме того, по окончанию курсов у тебя будет возможность двухмесячной стажировки в реальной компании!
Выводы получаются такие: профессия тестера - востребованная и позволяет в среднем зарабатывать около 60 т.р. в месяц. Учиться в ВУЗе на тестера смысла нет: долго, дорого да и нет официально такой специальности, как тестер. Кроме того, после ВУЗа у тебя все равно не будет опыта работы - лишь несколько потерянных лет.
В случае с ты можешь получить все навыки, необходимые для начала карьеры, и пройти стажировку в компании, чтобы получить минимальный опыт работы. На все про все нужно всего 4 месяца, а обучение происходит онлайн в комфортное для тебя время.
Здорово, правда?
Специальный проект с компанией GeekBrains
За время своей работы в сфере тестирования, у меня сложилось своё, особое мнение об этой области, начиная с позиции младшего тестировщика (junior tester) до руководителя отдела тестирования (test manager). И, в целом, это мнение достаточно критичное с долей любви и обожания к этой замечательной профессии.
Я никогда не собирался становиться тестировщиком - меня больше привлекала разработка. Со школьной скамьи я писал программы, которые уже обкатывались моими одноклассниками, а затем одногруппниками: мне было интересно решать задачи и оживлять вещи, а уж решением возникающих проблем и багов я занимался после того, как мне о них сообщали пользователи. К версии я приписывал минорную циферку, и… и в каком-то балансе между функциональностью и качеством программа оставалась навсегда, уступая место новым проектам и программам.
Забегая вперёд, скажу, что отчасти в этом кроется ключ к успешному ведению проектов - в нахождении баланса между затратами на разработку продукта и его качеством. Любой продукт схож с биологическим организмом, в формировании которого участвуют не один человек, а многие - прямым или косвенным образом. В формировании хорошего продукта должны участвовать все заинтересованные стороны, и каждая из них должна делать весомый вклад в общее дело. Но, к моему удивлению, тестировщики в этом отношении занимают особую нишу: во-первых, они являются связующим звеном в процессе, а во-вторых, они одни единственные из инженеров имеют право вето на выпуск версии продукта.
Обо всём об этом я узнал на первом своём месте в качестве тестировщика с неугасшими амбициями разработчика. В первую очередь, меня очаровала возможность получения доступа к управлению продуктом, власть, на которую я не особо рассчитывал. Это было здорово, что-то особенное, выше написания очередной функциональности. Во-вторых, тестировщики в силу особенностей профессии имеют большее представление о процессах и целях продукта, отчасти транслируют бизнес цели разработчикам, а результат разработчиков -руководителям. К сожалению, в мире и, тем более, в России, представление о роли тестировщика весьма сумбурное, и её значение сильно преуменьшается. А те компании, которые всё-таки находятся в тренде, стараются развить направления тестирования и управления качеством, хотя и ставят несколько завышенные цели: «найти все ошибки, снизить до минимума стоимость разработки через тестирование».
Эта статья, в первую очередь написана по мотивам общения с различными компаниями, является квинтэссенцией ответов на их вопросы. Во-вторых, обращена к начинающим тестировщикам и тем людям, которые хотят узнать о тестировании побольше с точки зрения внутренней кухни. В- третьих, базируется исключительно на моём (субъективном) опыте.
В Android SDK входит замечательный инструмент под названием MonkeyRunner, который позволяет автоматизировать процесс тестирования Android приложений в идеале без исходного кода, без особых знаний языков программирования (лишь общего представления о скриптовых языках достаточно) и, главное - имитировать любое поведение настоящего пользователя. В итоге получается эдакая скриптовая обезьяна, которая тыкает, печатает, читает приложение. Самое то, что можно «отдать на аутсорс» машине. Для меня такое понимание тестирования в порядке вещей. Но, к моему удивлению, когда я искал работу в первый раз после своей первой должности в роли тестировщика, выяснилось, что на рынке существуют (и по сей день!) странное разделение на «ручных» и «автоматических» тестировщиков, более того, лестница грейдов и вовсе столь смешана и растянута, что диву даёшься. Не говоря уже о том, что от компании к компании одни и те же должности подразумевают разные должностные обязанности, особенно это актуально для старших должностей.
В мои должностные обязанности входило: составление тест-дизайна, тест-кейсов, стратегии тестирования (если это был назначенный на меня проект), репорт багов, проверка документации и создание тестовой документации. Это было само собой разумеющимся для меня, хотя несколько удивляло, что у западных коллег эти обязанности были разделены. На рынке же оказалось, что вполне обычным явлением считается, что дизайн пишется с помощью CTE/UML (в лучшем случае) Test Lead/Senior Tester/Test Designer. Тест кейсы (разнообразные стратегии проверки границ, интерфейсное тестирование, нагрузочное, стендовые кейсы) - Senior Tester’ы. И, наконец, существуют низшие должности «исполнителей» - Tester. В некоторых компаниях и отделах их число может доходить до 20 и более человек! Другими словами, в штате проекта числились обезьяны, в лучшем случае, обладающие навыками пользователя компьютером и каким-то продуктом.
На деле же это… несколько неправильно. Потому что тестировщик не обезьяна. Если это не так, то либо вы, как компания, выпускаете разные продукты в короткий срок, без последующей поддержки и качества, прогоняя формальные smoke-тесты, либо, что более вероятно, ваш менеджер/архитектор - баран.
Затраты на автоматизацию тестирования окупаются далеко не сразу.
Для знакомых с теорией тестирования (коих, как показывает практика, не так уж и много), вполне очевидно, что необходимость автоматизации сильно зависит от специфики проекта (его сроков, поддержки, повторяемости, и пр.). В некоторых случаях куда предпочтительнее обойтись smoke тестами и пользовательским бета-тестированием и выполнять приёмку через product owner"a, чем усложнять процессы. Так же должно быть чёткое понимание приёмки продукта: верхнеуровневая и низкоуровневая. В первом случае, внутри проекта, можно определить роли и принять продукт владельцу продукта, во втором возможно ограничиться, если допускают это требования, приёмкой самими инженерами-разработчиками с выпуском release notes. В случае, когда тестирование требуется всё-таки отдельное, то куда проще и эффективнее иметь поставленный менеджментом процесс жизненного цикла продукта и человека или команду инженеров, способных самостоятельно покрыть задачи развёртывания и тестирования продукта, т. е. людей, которые априори знают область, инструменты и методы, а не стадо обезьян, которых повесили на разработчиков или одного руководителя проекта.
Ремарка №1
Как ни удивительно, но этот простой тезис зачастую сознательно нарушается. Например, для аутсорсинговых компаний это хороший способ получить дополнительные FTE. В плане бизнеса попросту выгоднее продать побольше, что-то, имеющее низкую себестоимость. В опыте моей работы на Auriga, где заказчикам предоставлялись на почасовую оплату соответствующие ресурсы в количестве десятков человек - не единичный случай. Более того, такой план хорошо покрывает цели стаффирования проекта для клиента при минимальных затратах. Несмотря на то, что нагрузка на менеджера проектов значительно возрастает, при грамотном руководстве это пусть к созданию «кузницы кадров» за счёт проекта, привязки кадров к компании (обучение и рост навыка) при сравнительно большей цене покупке специалиста с рынка, и последующая перепродажа, ротация персонала на более требовательные проекты.
Ещё одной причиной такой стратегии является возможность покупки нецелевых кадров для клиента. Так уж получается, что требования к кадрам ваших работодателей или клиентов иногда бывают недальновидны (о чём речь пойдёт ниже), и меньшими затратами для компании (по деньгам и времени) является возможность покупки фиктивных кадров. Скажем, покупка такого рода «обезьян» на проект с параметром «20 лет стажа» (но, возможно будучи весьма посредственным специалистом). Это особо актуально в системе грейдов Junior/Standard/Senior многих компаний, особенно за пределами России, где требования к стажу и реалии немного иные.
Следующей, и, на мой взгляд, главной причиной, являются риски. Постановка задач на проекте для тестирования - это покрытие определённой функциональности и действий. Зачастую процессы можно автоматизировать, особенно в отношении регулярных активностей, регрессионного тестирования, т. е. в процессе тестирования создать ферму, процесс и инфраструктуру, часто масштабируемую, портируемую и переносимую на другие продукты и проекты с минимальными издержками. Сокращение «непосредственной» работы на проекте для тестировщика ведёт к двум следующим следствиям:
Поэтому этот первый тезис стоит рассматривать как проблему в стратегической перспективе для любой компании, проблему роли тестирования и выстраивания инженерных процессов. Разрешение её, грамотная градация и использования сугубо инженерных кадров, является признаком грамотного руководства и долговременного планирования в компаниях.
Из-за мешанины с обезьянами в профессии тестировщиков хватает людей, далёких от инженерной сферы, и не имеющих подчас даже соответствующего технического образования. Это действительно грустно и печально, т. к. квалифицированных ресурсов на рынке тестировщиков сегодня действительно не хватает - грамотные специалисты предпочитают уходить в разработку (в лучшем случая близкую к теме аналитику), а те, что остаются, имеют скудное представление о жизненном цикле ПО, тестировании и языках программирования.
На мой взгляд, любой тестировщик должен обладать техническими знаниями, уверенным владением и хотя бы базовыми навыками администрирования прикладных программ и популярных ОС. Кроме того, тестировщик должен иметь хотя бы базовое представление о языках программирования, уметь читать код хотя бы на интуитивном уровне, а также быстро адаптироваться к новым языкам и программам/средам. Вообще, главные особенности тестировщика - это гибкость и обучаемость. Поэтому, имея опыт в программировании и общее представление о скриптовых языках и языках высокого уровня, человек сможет обучиться и адаптироваться без особых проблем. В идеале требуется знание скриптового языка и основ языка разработки, на котором и базируется проект.
Из всего этого вытекает, что тестировщик обязан уметь работать с кодом. Хотя, в идеале, хороший процесс должен исполняться по модели чёрного ящика. Тем не менее в него, в этот ящик Пандоры, тестировщик должен не бояться заглянуть и помочь разобраться с проблемой разработчику. То есть быть как рыба в воде в системе не только багтрекера, но и контроля версий кода, и быть способным провести ревью кода.
Несмотря на то, что я в подавляющем большинстве случаев слышу мнение, что процесс ревью кода, отладки (дебаггинг) и юнит-тестирования - прерогатива исключительно разработчиков, возьму на себя смелость утверждать, что это неправильный подход. Проблема исходит из недостаточной квалификации тестировщиков и неверного управления жизненным циклом ПО. Возможно, этот подход хорошо работает в маленьких проектах по TDD, но главная сила и возможность обеспечить высокое качество продукта - разбить сферы влияния, ответственности, обеспечить принцип раздельности (dissimilarity).Это сделает процесс разработки более прозрачным, отслеживаемым и позволит скомпенсировать «эффект замыленности глаза» у разработчиков, избежать «трюков» с их стороны.
Ремарка №2
В компании Liebherr Aerospace жёстко выстроены процессы и роли в компании. Чёткое следование специфичным для отрасли итеративным моделям. Тем не менее, инженерное крыло, инженерные должности называются для всех одинаково - Software Engineer. Акцент делается на том, что сотрудник в компании в первую очередь - специалист, инженер в области ПО. Значит, сотрудник должен разбираться в инженерных процессах, процессе разработки, тестирования, схемотехники и т.д. Тем не менее, среди инженеров присутствует обязательное разделение на специализацию: in Test, in Development, in Requirements, и пр.
Так как компания следует жёстко инженерным процессам с целью соблюдения высочайшего качества, каждая часть процесса разделена на независимых участников. На практике это означает, что каждый уровень требований пишется отдельным человеком (группой), дизайн другими, код пишется третьими, юнит-тестирование четвёртыми, функциональное тестирование - пятыми и так далее. При этом, чтобы не дать «заскучать» и «увязнуть» в рутине, людей в проекте стараются вращать по функциям, и, вполне возможно, даже на одном проекте, в разных итерациях инженер, по мере своих возможностей будет покрывать разные обязанности, и охватит различные этапы разработки ПО.
То, что каждый из этапов и типов разработки и тестирования должен покрывать разные люди следует из требований международных стандартов, таких как DO-178B (для авиации), EN 50128 (для железнодорожного транспорта) или ГОСТ Р МЭК 60880 (для атомных электростанций), и обеспечивает, в конечном итоге высочайшую отказоустойчивость на уровне процессов и в том числе в части тестирования ПО.
Во время почти каждого собеседования на должность тест менеджера можно услышать вопрос по поводу того, как соискатель собирается выстраивать процесс тестирования и какие метрики с проекта он собирается снимать, какие метрики будет использовать по отношению к себе. На самом деле, вариантов метрик - количественных и качественных - можно придумать немало, но особого смысла они не будут иметь до той поры, пока не будет в проекте эффективности в команде. В команде в широком смысле слова, т. е. как внутри отдела/команды тестирования, так и при взаимодействии с командой разработчиков и заказчиков из бизнеса.
На практике это означает, что бесполезно считать количество разработанных тестов (это метрика прогресса), найденных багов (в худшем случае) показателем эффективности команды тестирования, даже рейт регрессий, даже синтетических метрик на проекте (с использованием критериев важности и трудоймкости), не говоря уж о идиотских (но по-прежнему применяемых и для команды тестирования KSLOC\hour). Для менеджера проекта, возможно, будет неплохой метрикой CPI/SPI как KPI проекта, которая может базироваться на всех обозначенных и собранных тест-менеджером метриках. То есть, достаточно абстрактная и высокоуровневая оценка в зависимости от затраченных усилий и полученного результата. Но при условии, что команды работают как единый организм.
Для тестировщиков это означает, что они связующее, ведущее колесо процесса, которое сделает программное обеспечение работоспособным и соответствующим требованиям. В процессе тестирования это означает как само тестирование, так и предоставление теста повторяемости, документируемости, возможных проблем и решений проблемы (если это видно со стороны тестирования, если хватает квалификации), а так же перепроверку тестирования (VoV). Другими словами, задачей тестирования является как перепрогон и перепроверка всех возможных состояний, так и (в необходимом и достаточном случае) покрытие полной тест-стратегии и тест-плана (по крайней мере то, что обозначено в Quality Gates), вынесение багов и их разрешение через разработчиков ПО и спецификации. Т. е., с момента проверки и обнаружения бага ответственность на нём не «перекидывается» на разработчика, а сопровождается тестировщиком до его разрешения. Грубо говоря, тестировщик отвечает за баги, а разработчик - за фичи.
Тут мы подошли к ключевым различиям между тестировщиком и разработчиком, кои в моей статье получаются очень близки и похожи. Тем не менее, по стилю работы разработчики обычно либо перфекционисты, либо «фичеделы» (которые любят кодить ради кода, функциональности и алгоритмов); тестировщики же - либо педанты, либо автоматизаторы (стремящиеся автоматизировать автоматизацию). Поэтому в проекте тестировщик знает, как правильно сделать, а разработчик - как именно.
Исходя из этого, повторюсь, что главное - это результат, зависящий от единой команды, а не только от метрик в одном прогрессе, скажем, разработки дизайна. И где процесс проседает больше - там и кроется проблема, там и падают реальные метрики, которые уже в контексте работающего синергического проекта обретают смысл. Вполне возможно, что долгая разработка тестов не вина дизайнера, а вина аналитика, транстировавшего требования слишком сложно.
Ремарка №3
Несмотря на то, что описанная мною модель говорит о единстве и взаимосвязанности всех этапов процессов, сегодня тестировщиков правильнее классифицировать всё-таки на разработчиков самих тестов (акцентирующих силы и знания на методологии тестирования) и devops инженеров, обслуживающих инфраструктуру. Сегрегация функций имеет свои плюсы при достаточно большом размере проекта и хорошем финансировании, когда развитие, поддержку и тестирование инфраструктуры можно разнести между инженерами, в идеале - между экспертами-специалистами. Важным моментом является то, что тест-инженер всё-таки в первую очередь инженер, разработчик в тестировании, способный использовать различные инструменты для разрешения поставленной задачи. И только во вторую очередь - эксперт в какой-то определённом инструменте и программе. Знатоков инструментария, возможностей фреймворков правильнее классифицировать как отдельных инженеров, инженеров-инструменталистов (tool engineer).
В V-модели разработки ПО наглядно видно, что тестировщик участвует на всех этапах жизненного цикла.
Схожесть разработчика и тестировщика, размазанность границ области при наличии хорошей квалификации - главный показатель интереса в работе тестировщика. Конечно, можно утверждать, что причастность к продукту и его качеству в случае тестирования чёрного ящика является мотивационным фактором, но, на мой взгляд, человек, пришедший в техническую, инженерную область сделал это осознанно, с желанием развиваться и работать над собой. Поэтому возможность расширять свой кругозор, влиять на качество продукта, (пусть даже небольших вещей), проявлять активность, а также накладывать вето на выпуск продукта у тестировщика, по моему мнению, более весомые аргументы за профессию. А раз так, раз хороший тестировщик - не обезьяна, а инженер-исследователь, знаток, принимающий участие на почти на всех этапах жизненного цикла по (в отличие от ролей аналитиков, дизайнеров, разработчиков, и технических писателей), ответственный за качество продукта (не процесса, это к QA, так что под «качеством продукта» будем подразумевать соответствие заявленным и утверждённым требованиям и стандартам, чеклистам и прочая), то для поднятия качества продукта и развития себя, как специалиста, тест-инженер должен проявлять активную позицию. Он знает, как улучшить продукт. Знает, что такое «достаточно хорош», и как его, продукт или процесс, таким сделать, инициировать движение как инженера-разработчика, так и других команд и даже компаний. Например, в любых проектах бывают моменты простоя, который может быть допустим со стороны руководства. Обычно в это время сотрудники решают личные проблемы или занимаются самообразованием. В отношении работы разработчик может заняться рефакторингом, поизучать алгоритмы и перенести на свои проекты. А что делать тестировщику? Осваивать новые средства тестирования? Он-то ничего не делает без изначального пакета от разработчиков/аналитиков. В действительности, он может заняться автоматизацией своей деятельности или улучшением продуктов, им используемых, даже если он далёк от инфраструктуры и devops.
Ремарка №3
В Liebherr Aerospace жёсткий процесс резко ограничивал использование любых инструментов и жёстко формализовал процесс разработки и тестирования, т. е. простора для автоматизации оставалось не так много - даже вмешательство в багтрекер было запрещено. Тем не менее, такой процесс, как подготовка документации, был в такие периоды автоматизирован, пусть и с использованием не находящегося под запретом VBA для MS Office. А для процесса код ревью можно было улучшить статические анализаторы кода. Они не совсем удовлетворяли стандартам на проекте и порождали лишние сообщения, которые не фильтровались даже элементарным grep. Тем не менее, чтобы уменьшить время на ручное ревью кода, в рамках простоя мы работали на перспективу, улучшая сторонний продукт, такой как статический анализатор, подготавливая набор кейсов для него для имплементации нужных нам проверок.
Последней и самой странной темой, на мой взгляд, является весьма смутное представление о тестировании (даже о теории, не говоря о практике). Во многих компаниях отделы тестирования не оправдывают надежд, в некоторых даже дискредитировали себя и функционируют на малую часть от своей потенциальной эффективности по ряду факторов. Проблема проистекает как из-за отсутствия школы, так и из-за некомпетентности менеджмента. Ситуация весьма плачевная в отраслях, отдалённых от IT, даже где «деньги - не проблема» - там задачи ставятся по принципу «повысить качество продукта». Даже в IT-компаниях, где есть общее представление о процессах, есть целый ряд проблем, связанных с фиксацией на определённых ролях или инструментах, хотя к тестированию, повторюсь, такой подход плохо применим.
В одном из крупных инвестиционных банков, в котором у меня проходило собеседование, было схожее требование на позицию тест-менеджера: «повысить качество и уменьшить брак». Любую задачу можно решить. Хотя под покровом задач скрывается координация отделов по ряду различных продуктов, составление планов тестирования, организация тестирования, работа с разработчиками, составление базы кейсов и прочая. В действительности, ответственность за качество продуктов в компании логично взять на себя какому-нибудь «директору по качеству», оно же QA Director, а не просто руководителю отдела тестирования. Однако тут дело упирается в полномочия, которых на этой позиции нет, и в отсутствие группы, которая не планировалась вовсе (которая могла бы помочь тому-тому тому-то). То есть в компанию нужен человек-оркестр без команды. Разгадка тут простая: менеджмент ищет по ключевым словам, и считая качество в аббревиатуре QA панацеей от всех проблем, хотя она лежит в сфере стратегического топ-менеджмента и процессов, которые нужно спускать сверху с соответсвующими полномочиями и ресурсами.
В идеале управление качеством (QA) и тестирование две .
Проблема системная, т. к. весьма неплохо, когда HR ищут по ключевым словам вроде «нагрузочное тестирование», «функциональное». Но когда в процессе рассмотрения делается акцент не на навыки тестирования, не на активность и гибкость кандидата, а на конкретный инструмент - это уже проблема, особенно когда никакого тестирования нет в помине (есть обезьянничество), и не факт, что требуемый инструмент эффективнее того, который знает соискатель. Проблема в том, что знание мелкого нюанса или инструмента, на освоение которого уйдёт несколько часов, ставится во главе угла, выше знания языков программирования или теории. В одном из интервью было достаточно смешно было отвечать на вопросы: «назовите какую-нибудь книгу по тестированию» и, ответив про Сэма Канера, услышать: «мы такого не знаем, а про жизненный цикл бага что-нибудь читали?». Это было бы смешно, если бы не было так грустно. Грустно, когда HR сообщает об отказе из-за отсутствия опыта у кандидата, хотя дело к неправильном расставлении акцентов.
Найти хорошего тестировщика - большая проблема, т. к. инженер-тестировщик - это, в идеале, человек, который разрешает технические проблемы, связанные с разработкой ПО, эдакий problem solver. Такому человеку, помимо технических навыков очень важно иметь внимательность, пытливый ум, быть активным и уметь донести мысль и отстоять свою точку зрения на любом уровне.В каком-то роде, тестировщики - это исследователи из мира разработки ПО. Поэтому в руках инженера-тестировщика легко узнаваемый символ - лупа (линза), наблюдающая за жучками. Как нельзя лучше характеризует она работу тестировщика: используется как по прямому назначению для выявления дефектов, так и для «прожигания дырочек», с её помощью можно добывать огонь и даже, имея целую систему линз, наблюдать за звёздами. Главное - уметь это делать.
Ремарка №5
В компании Intel главенствует подход, в котором инструменты выбираются из предпочтений сотрудников на проекте. Это означает, что, в целом, неважно, какой инструмент и язык выбрать для решения задачи, главное - её решить. Сосуществование трёх разных тест инженеров, пишущих на трёх разных языках вполне допустимо, если проблема решается, решается эффективно и накладные расходы на поддержку разумны, а процесс документируется. Кроме того, многие используемые инструменты являются бесплатными, open-source или собственной разработки. На сегодняшний день существует огромное количество инструментов, с помощью которых возможно решать разнообразные задачи, и выбор инструментов не должен ограничивать возможности инженера. Однако, если для задачи действительно требуется использовать какой-то инструмент, отличный от свободно доступного, то при наличии чёткого понимания и обоснования, можно купить и использовать его. Это опять-таки соответствует целям бизнеса - не забивать гвозди микроскопом, не работать эффективно, выжимая максимум из инструментов, если квалификация инженеров позволяет обойтись «малыми потерями». Хорошей альтернативой является также участие в открытых проектах и инвестиции в них для последующего использования для собственных нужд. Такой подход убивает двух зайцев (свои нужды) и задачи и создаёт инструменты для всего общества в свободном использовании.
Тестировщик - это больше, чем профессия. Это образ проактивной жизни и стремления эту жизнь сделать лучше для всех посильными и эффективными средствами. Цели тестировщика в отношении продукта наиболее близки к целям бизнеса и стратегической цели компании в отношении этого продукта, и в то же время глубоки внутри компании в роли исследователя. А раз так, то главные его качества - это энергия, знания и гибкость. Но в тоже время работа тестировщика – это не всеобщее знание и ответственность за качество продукта и качество услуг. У тестирования есть границы: с одной стороны ограниченные проектом и требованиями в нём (менеджмент проекта и установленный жизненный цикл программы), и с другой – процессами, за которые отвечает QA. Но о различия QA от тестирования совсем другой разговор.
Подойдёт ли мне курс, если у меня нет опыта в программировании
Конечно! Мы учим с нуля. Во всем помогут опытные наставники, которые будут курировать вас на протяжении всего курса.
Достаточно ли будет практики?
Её будет много. Начиная с самого первого занятия вы начнёте пробовать себя в качестве тестировщика, пытаясь решать задачи, с которыми специалисты встречаются в повседневной работе. Кроме практики во время занятий, после каждой лекции вы будете получать домашнее задание, которое позволит закрепить знания. И его не примут, пока оно не будет сделано по-настоящему качественно.
А я точно трудоустроюсь?
Да, если пройдете обучение по курсу, в нем изучается достаточно навыков, чтобы получить работу программиста. Конечно, есть и условия, которым должны отвечать не только мы, но и вы.
Какое оборудование мне понадобится?
Для прохождения обучения и выполнения домашних заданий достаточно будет ноутбука и смартфона.
Как проходит обучение в группах?
Все обучение проходит индивидуально, вы общаетесь с преподавателем один на один. Для дополнительной коммуникации есть чат, в котором можно обсудить насущные вопросы с группой.
Получится ли совмещать с работой?
Весь формат обучения построен таким образом, чтобы вы могли совмещать его с работой, институтом и личной жизнью.
Записаться на курс или получить консультацию
Направление тестирования быстро развивается. Если ещё несколько лет назад можно было практически без знаний и опыта устроиться работать ручным тестировщиком и учиться непосредственно на работе, то в 2018 году сделать так уже сложнее. Ниже представлен минимальный список того, что надо знать для работы тестировщиком — или QA-инженером, как всё чаще называют представителей нашей профессии — а не мартышкой, которая просто тыкает в кнопки.
Задача тестировщика — убедиться, что все функции продукта, описанные в функциональном задании, работают так, как ожидается. Ошибки работы, или баги, он выявляет разными видами тестирования. На баги проверяется и дизайн, и фронтенд, и серверная часть — и не раз. Если вы хотите заказать у нас мобильное приложение, можете положиться на наш отдел качества, где работают одни из самых придирчивых людей компании. Обсудить сотрудничество можно после того, как вы заполните .
Мы собрали перечень ключевых навыков и умений тестировщиков ПО. Итак, тестировщик должен:
Разберёмся, как стать тестестировщиком программного обеспечения с нуля и что требуется знать начинающему тестестировщику. Перечень книг и полезные статьи, которые стоит почитать:
