Тест-аналитики – кто это? — Лаборатория Качества

Тест-аналитики – кто это? — Лаборатория Качества Аналитика

В качестве вступления

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

Забегая вперёд, скажу, что отчасти в этом кроется ключ к успешному ведению проектов — в нахождении баланса между затратами на разработку продукта и его качеством. Любой продукт схож с биологическим организмом, в формировании которого участвуют не один человек, а многие — прямым или косвенным образом.

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

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

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

Эта статья, в первую очередь написана по мотивам общения с различными компаниями, является квинтэссенцией ответов на их вопросы. Во-вторых, обращена к начинающим тестировщикам и тем людям, которые хотят узнать о тестировании побольше с точки зрения внутренней кухни. В- третьих, базируется исключительно на моём (субъективном) опыте.

Главные профессии в it: от тестировщика до дата-сайентиста

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

Евгений Картавец, программный директор Skillfactory:

«Бывает несколько разновидностей системных администраторов. Есть те, кто занимаются поддержанием работоспособности компьютеров пользователей корпоративной сети — помогают установить Word, поменять монитор и т.д. А бывают администраторы серверов — у таких администраторов квалификация и зарплата выше».

Профессия системного администратора часто становится точкой входа IT. Такие специалисты требуются практически в каждом офисе, где работает больше 5–7 человек.

Медианная зарплата: 91 тыс. рублей.

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

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

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

Курс

Системный администратор

Станьте универсальным специалистом с нуля и сможете самостоятельно поддерживает всю инфраструктуру компании. Вы получите поддержку менторов и помощь в трудоустройстве. Скидка 5% по промокоду BLOG.

Узнать подробности

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

Зарплата: от 50 000 до 300 000 рублей, медианная — 85 000.

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

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

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

Евгений Картавец, программный директор Skillfactory:

Тестирование — одна из самых простых точек входа в IT. На ручного тестировщика можно обучиться за 3-4 месяца. Дальше можно пойти в автоматизацию, для этого потребуется выучить Python или Java. При желании, с этими же навыками можно выучиться на программиста.

Читайте также: Рассказ техлида-тестировщика о тонкостях его профессии.

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

Курс-симулятор

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

Быстрый вход в сферу IT и возможность удаленной работы. На курсе вы полностью смоделируете путь тестировщика и научитесь всему необходимому. Дополнительная скидка 5% по промокоду BLOG.

Узнать больше

Этичные хакеры востребованы в госсекторе, сфере разработки ПО, торговой и банковской сферах — везде, где необходима надежная защита данных.

Таких специалистов нанимают и специализированные фирмы, и корпорации вроде Google или Mail.ru Group. А некоторые этичные хакеры остаются фрилансерами, например, используют Bug Bounty — это программа выплаты награды за обнаружение проблем в безопасности по запросу компаний.

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

Чаще всего предлагают: от 80 тыс. до 170 тыс. рублей.

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

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

Перспективы: Этичный хакер — отличный выбор для карьеры в IT. Их востребованность будет только возрастать вместе с необходимостью в киберзащите и охране данных. Опытный специалист может собрать команду пентестеров и руководить ею или даже основать собственную компанию в сфере информационной безопасности.

Курс 

Этичный хакер

Освойте с нуля все тонкости тестирования на проникновение. Научитесь отражать кибератаки и поддерживать безопасность любых IT-систем. Скидка по промокоду BLOG 5%.

Узнать больше

Евгений Картавец, программный директор Skillfactory:

«На старте карьеры необходимо выбрать, для каких устройств вы хотите заниматься разработкой — под управлением IOS или Android. Если выберете IOS — нужно будет освоить язык Swift и научиться писать на нем мобильные приложения, если Android — то в тренде сейчас Kotlin, однако понадобится также уметь читать код на Java».

Зарплата мобильного разработчика: от 150 тыс. до 350 тыс. рублей.

Чаще всего предлагают: 250 тыс. рублей.

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

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

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

Читайте также: Что выбрать: iOS- или Android-разработку?

Профессия

Android-разработчик

Станьте востребованным специалистом: освойте с нуля программирование на Java и Kotlin, мобильную разработку и UX/UI для Android. Дополнительная скидка 5% по промокоду BLOG.

Узнать больше

Средняя зарплата: 120 тыс. рублей

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

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

Перспективы: Как и в любой другой разработке, game developer проходит путь от начинающего — Junior — до опытного — Senior-разработчика, тимлида и, возможно, основателя собственной инди-студии игр.

Курс

Разработчик игр на Unity

Научитесь с нуля программировать на самом популярном игровом дивжке и создавать любые игры для мобильных платформ и PC. Скидка 5% по промокоду BLOG.

Узнать больше

Такие специалисты востребованы везде, где есть сайт или приложение. Начинающий frontend-разработчик должен разбираться в HTML и CSS, на базовом уровне знать JavaScript, библиотеки и фреймворки для веб-разработки. Более продвинутый разработчик должен хорошо разбираться в библиотеках и фреймворках, например, владеть JavaScript-библиотекой React.

Зарплата frontend-разработчика: от 100 тыс. до 290 тыс. рублей.

Чаще всего предлагают: 170 тыс. рублей.

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

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

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

Дополнительный анализ:  Курс биткоина и альткоинов – Рынок криптовалют — TradingView

Читайте также: Рассказ бывшего полицейского, который стал frontend-разработчиком.

Курс

Frontend-разработчик

Получите перспективную творческую IT-профессию с нуля. Вы освоите полный набор знаний и умений, необходимых для создания визуальной части веб-приложений. Скидка 5% по промокоду BLOG.

Узнать больше

Тоже нужны везде, где есть приложения и сайты. Для работы на начальном уровне необходимо разбираться в базах данных и знать хотя бы один язык программирования, например PHP, Python, С#.

Зарплата backend-разработчика: от 100 тыс. до 320 тыс. рублей.

Чаще всего предлагают: 250 тыс. рублей.

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

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

Перспективы: Backend работает в тесной связке с frontend в тех же самых компаниях и сферах бизнеса. Карьерный путь у них тоже похож: стать топовым специалистом в своей области или развиваться в fullstack. Хорошее знание внутреннего устройства веб-приложений облегчит переход в DevOps или информационную безопасность.

Курс

Backend-разработчик

Освойте программирование на Go,бэкенд-разработку высоконагруженных приложений и станьте незаменимым специалистом. Дополнительная скидка 5% по промокоду BLOG. 

Узнать больше 

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

Зарплата fullstack-разработчика: от 90 тыс. до 330 тыс. рублей.

Чаще всего предлагают: 200 тыс. рублей.

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

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

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

Читайте также: Полный обзор профессии Fullstack-разработчика.

Профессия

Fullstack-разработчик

Освойте программирование и fullstack-разработку на Python и Django. После обучения наш карьерный центр поможет вам подготовиться к собеседованию и предложит несколько вакансий на выбор. Скидка 5% по промокоду BLOG.

Узнать подробности

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

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

Зарплата DevOps-инженера: от 160 тыс. до 400 тыс. рублей.

Чаще всего предлагают: 250 тыс. рублей.

Без IT: DevOps-инженер без технологий — это рационализатор. Он стремится найти способы более эффективной работы, технологии, которые ускорят и упростят работу всей команды в целом.

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

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

Профессия

Devops-инженер

Освойте перспективную IT-профессию на стыке разработки, системного администрирования и бизнеса. Скидка по промокоду BLOG.

Узнать больше 

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

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

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

Зарплата системного аналитика: от 80 тыс. до 300 тыс. рублей.

Чаще всего предлагают: 180 тыс. рублей.

Без IT: Этого специалиста можно сравнить с переводчиком. Он знает два языка — технический и человеческий — и помогает людям из совершенно разных миров лучше понять друг друга. Умение найти общий язык и с техническими специалистами, и с далекими от разработки и техники людьми пригодится за пределами информационных технологий. Например, в дизайне интерьеров: системный аналитик сможет объяснить заказчику, почему не стоит сносить несущую стену, а строителям — чего же все-таки хочет клиент и зачем ему лепнина на потолке.

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

Перспективы: от ведущего системного аналитика до руководителя по внедрению информационных систем и руководителя IT-направления.

Профессия

Системный аналитик

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

Узнать подробности

Data Engineer должен отлично разбираться в базах данных, знать SQL, уметь программировать на Python, Java или Scala. Стать таким специалистом легче всего будет с навыками разработки, но научиться можно и с нуля.

Зарплата Data Engineer: от 100 тыс. до 300 тыс. рублей.

Чаще всего предлагают: 150 тыс. рублей.

Без IT: Работа Data Engineer связана с поиском, сбором и сортировкой информации, поэтому в мире без технологий они умели бы работать с аналоговыми базами знаний, например, огромными архивами.

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

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

Курс 

Data Engineer

Научитесь автоматизировать процесс сбора и обработки данных на практике и станьте востребованным специалистом. Скидка по промокоду BLOG 5%.

Узнать больше

Для Data Analyst важно владеть основами математики и статистики. Еще нужно уметь работать с платформами для визуализации и аналитики, например Tableau. Также необходимы навыки коммуникации, так как результаты аналитики нужно представить заказчику.

Должность Data Analyst — хорошая точка входа в мир больших данных, так как таким специалистам на начальном этапе требуется меньше технических навыков, чем Data Engineer или разработчикам.

Средняя зарплата Data Analyst: 130 тыс. рублей

Без IT: Умения Data Analyst полезны и в нецифровой аналитике. В мире без технологий такие специалисты продолжат работать аналитиками, ведь их главный навык — умение видеть скрытые связи и на их основании делать выводы и строить прогнозы. Это необходимо во многих отраслях, от экономики до государственного управления.

Пример задачи: Провести A/B-тестирование различных рекомендательных систем и сформулировать рекомендации по их настройке и внедрению.

Перспективы: Для аналитиков данных характерна стандартная кривая профессионального роста Junior, Middle и Senior. Как Data Engineer, по мере профессионального развития они могут освоить смежные профессии и за счет этого получить новые перспективы.

Читайте также: История Екатерина Карповой: «Я училась на стоматолога, а теперь работаю аналитиком в «Тинькофф»

Курс 

Аналитик данных

Вы изучите необходимые в работе инструменты и навыки, пройдя на практике через все этапы работы над аналитическим проектом. Скидка по промокоду BLOG 5%.

Узнать больше

Для работы Data Scientist использует базы данных и Python. Но главное — знание математики, аналитический ум и глубокое понимание области исследования.

Средняя зарплата Data Scientist: 150 тыс. рублей.

Без IT: Data Scientist — это настоящие исследователи. Если бы в мире не было компьютерных технологий, такие специалисты занялись бы наукой и вскоре бы их придумали.

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

Перспективы: Data Scientist вполне может дорасти до Chief Digital Officer, но и горизонтальный рост в этой профессии открывает большие перспективы. Из-за бурного развития отрасли в этой профессии пока нет такого понятия, как потолок профессионального роста.

Читайте подробнее: Кто такой и чем занимается Data Scientist

Курс

Data Science с нуля

Освойте самую востребованную профессию 2021 года! Только реальные знание и навыки, поддержка менторов и помощь в трудоустройстве. Скидка 5% по промокоду BLOG.

Узнать больше

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

Медианная зарплата: 165 тыс. рублей.

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

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

Перспективы: Как и в случае с другими разработчиками, ML-специалист сначала набирается опыта, доходя до должности тимлида, а затем может стать руководителем отдела, подразделения и в конце концов CDO, Chief Data Officer — главным специалистом по данным в компании.

Курс

Machine Learning и Deep Learning

Курс даст вам полное понимание алгоритмов и знание необходимых библиотек при использовании Deep Learning.

Узнать больше

Приоритезация

Тест-аналитики – кто это? — Лаборатория Качества

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

В общем случае выполнять приоритезацию можно по следующим критериям:1. Требования клиента.Требования клиента очень важны и связаны с продвижением продукта и торговой деятельностью.2.

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

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

Дополнительный анализ:  Внедрение WFM-систем - КОРУС Консалтинг

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

По клику на картинку откроется полная версия.


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

Тезис №1: тестировщик — не обезьяна

В 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 многих компаний, особенно за пределами России, где требования к стажу и реалии немного иные.

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

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

Тезис №2: тестировщик — это инженерная профессия

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

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

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

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

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

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

Ремарка №2

В компании Liebherr Aerospace жёстко выстроены процессы и роли в компании. Чёткое следование специфичным для отрасли итеративным моделям. Тем не менее, инженерное крыло, инженерные должности называются для всех одинаково — Software Engineer. Акцент делается на том, что сотрудник в компании в первую очередь — специалист, инженер в области ПО. Значит, сотрудник должен разбираться в инженерных процессах, процессе разработки, тестирования, схемотехники и т.д. Тем не менее, среди инженеров присутствует обязательное разделение на специализацию: in Test, in Development, in Requirements, и пр.

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

То, что каждый из этапов и типов разработки и тестирования должен покрывать разные люди следует из требований международных стандартов, таких как DO-178B (для авиации), EN 50128 (для железнодорожного транспорта) или ГОСТ Р МЭК 60880 (для атомных электростанций), и обеспечивает, в конечном итоге высочайшую отказоустойчивость на уровне процессов и в том числе в части тестирования ПО.

Тезис №3: метрики — ерунда, если нет работы в команде

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

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

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

Дополнительный анализ:  Пятничные вебинары: учимся программировать бесплатно / Блог компании Skillbox / Хабр

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

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

Другими словами, задачей тестирования является как перепрогон и перепроверка всех возможных состояний, так и (в необходимом и достаточном случае) покрытие полной тест-стратегии и тест-плана (по крайней мере то, что обозначено в Quality Gates), вынесение багов и их разрешение через разработчиков ПО и спецификации. Т. е., с момента проверки и обнаружения бага ответственность на нём не «перекидывается» на разработчика, а сопровождается тестировщиком до его разрешения. Грубо говоря, тестировщик отвечает за баги, а разработчик — за фичи.

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

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

Ремарка №3

Несмотря на то, что описанная мною модель говорит о единстве и взаимосвязанности всех этапов процессов, сегодня тестировщиков правильнее классифицировать всё-таки на разработчиков самих тестов (акцентирующих силы и знания на методологии тестирования) и devops инженеров, обслуживающих инфраструктуру. Сегрегация функций имеет свои плюсы при достаточно большом размере проекта и хорошем финансировании, когда развитие, поддержку и тестирование инфраструктуры можно разнести между инженерами, в идеале — между экспертами-специалистами. Важным моментом является то, что тест-инженер всё-таки в первую очередь инженер, разработчик в тестировании, способный использовать различные инструменты для разрешения поставленной задачи. И только во вторую очередь — эксперт в какой-то определённом инструменте и программе. Знатоков инструментария, возможностей фреймворков правильнее классифицировать как отдельных инженеров, инженеров-инструменталистов (tool engineer).

Тезис №4: тестировщик — центр процесса разработки по

Тест-аналитики – кто это? — Лаборатория Качества
В V-модели разработки ПО наглядно видно, что тестировщик участвует на всех этапах жизненного цикла.

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

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

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

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

Ремарка №3

В Liebherr Aerospace жёсткий процесс резко ограничивал использование любых инструментов и жёстко формализовал процесс разработки и тестирования, т. е. простора для автоматизации оставалось не так много — даже вмешательство в багтрекер было запрещено. Тем не менее, такой процесс, как подготовка документации, был в такие периоды автоматизирован, пусть и с использованием не находящегося под запретом VBA для MS Office. А для процесса код ревью можно было улучшить статические анализаторы кода. Они не совсем удовлетворяли стандартам на проекте и порождали лишние сообщения, которые не фильтровались даже элементарным grep. Тем не менее, чтобы уменьшить время на ручное ревью кода, в рамках простоя мы работали на перспективу, улучшая сторонний продукт, такой как статический анализатор, подготавливая набор кейсов для него для имплементации нужных нам проверок.

Тезис №5: тестирование — не место для фиксации на ключевых словах

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

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

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

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

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

Тест-аналитики – кто это? — Лаборатория Качества
В идеале управление качеством (QA) и тестирование две непересекающиеся сущности.

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

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

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

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

Ремарка №5

В компании Intel главенствует подход, в котором инструменты выбираются из предпочтений сотрудников на проекте. Это означает, что, в целом, неважно, какой инструмент и язык выбрать для решения задачи, главное — её решить. Сосуществование трёх разных тест инженеров, пишущих на трёх разных языках вполне допустимо, если проблема решается, решается эффективно и накладные расходы на поддержку разумны, а процесс документируется. Кроме того, многие используемые инструменты являются бесплатными, open-source или собственной разработки. На сегодняшний день существует огромное количество инструментов, с помощью которых возможно решать разнообразные задачи, и выбор инструментов не должен ограничивать возможности инженера. Однако, если для задачи действительно требуется использовать какой-то инструмент, отличный от свободно доступного, то при наличии чёткого понимания и обоснования, можно купить и использовать его. Это опять-таки соответствует целям бизнеса — не забивать гвозди микроскопом, не работать эффективно, выжимая максимум из инструментов, если квалификация инженеров позволяет обойтись «малыми потерями». Хорошей альтернативой является также участие в открытых проектах и инвестиции в них для последующего использования для собственных нужд. Такой подход убивает двух зайцев (свои нужды) и задачи и создаёт инструменты для всего общества в свободном использовании.

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector