В программисты или в тестировщики (идти)? — Хабр Q&A
Кратко: тестировщик — это своего рода экзаменатор/фильтр качества выпускаемого продукта, которое прямо влияет на репутацию компании этого продукта на рынке.Чем лучше отношение человека к качеству тестируемого им продукта, тем больше такой тестировщик ценится на рынке.
Т.е. надо понимать, что работа тестировщика — не только написание и исполнение кейсов для проверок основных функций разрабатываемого продукта, но и участие в возможном улучшении продукта (например, он может сказать, что пользоваться определённой кнопкой — неудобно, лучше бы она стояла там…).
Тестировщики — тоже бывают разные: реакция приложения на последовательные действия пользователя (обычный тест), удобство использования(UI/UX), тестирование на реакцию приложения при возникновении различных случайных событий и ситуаций (нет интернета, приложение/окно не закрыли как положено и т.д.).
Есть низкоуровневые тестировщики (или элитные тестировщики): они проверяют отсутствие утечек памяти, нагрузку на CPU/GPU, тротлинг, корректность создания потоков, процессов, race-condition и прочее. Как правило — это дебаггер с ассемблером и прочие страшные вещи для отладки при использовании программного продукта.
Всё зависит от Ваших способностей погрузиться в глубины обработки информации: от банальной реакции приложения на экране до регистров процессора/ячеек памяти/отслеживания системных вызовов.
Могу сказать, что это большое отдельное направление, которое набирает обороты, т.к. качественный и стабильный продукт, работающий без ошибок — это репутация компании, которая его произвела, и чем он будет стабильнее и качественнее работать, тем больше людей перейдёт от конкурентов на продукт этой компании.
Стоит ли это направление изучать?
Если Вы не имеете возможности кодить и разрабатывать (причины — любые), но хотите быть частью большой команды, создающей хорошие программные продукты в компании, которая имеет возможность обеспечить качественное и оплачиваемое содержание такой команды — изучайте и идите сразу туда.
Если же компания экономит на тестировщиках, значит она просто не набрала нужный опыт и/или уровень на рынке и, как следствие, не может/не хочет вкладываться в таких специалистов, как тестировщики. Вот туда — лучше и не пытаться даже.
Тестировщик vs программист. Как работать, если отношения накалены?
Первое: тональность контакта, сама форма рабочего общения. Некорректная тональность становится триггером субординационного конфликта.Нужно подобрать здоровую тональность коммуникации, чтобы коллеги звучали уважительно друг для друга. Если тестировщик снимет с себя плащ супермена-фиксера, а разработчик выйдет из образа демиурга, элиты или звезды, то накал отношений спадет.
Абсолютное no-no – злорадствовать в случае найденной ошибки, гордиться обилием обнаруженных дефектов разработки. Этикет программиста, в свою очередь, состоит в том, чтобы посмотреть написанный код, прежде чем отдавать его на тестирование. Если в команде есть токсичные люди, которые распространяют злорадную, издевательскую, высокомерную тональность и создают атмосферу конфронтации, то важно не поддерживать этот вайб, а свою коммуникацию строить конструктивно.
Второе: мыслить перспективами. Тестировщику карьерно выгодно быть в конструктивных отношениях с программистами, потому что он, вероятно, будет развиваться в направлении аналитики и автоматизации тестирования, начнет изучать языки программирования. Когда что-то непонятно или не получается, ему будет полезна подсказка коллег. Он также может захотеть стать программистом или QA-лидом. В обоих случаях важно быть в положительных рабочих отношениях или наладить их, если они натянуты.
Что-то вроде волшебного решения в этой теме есть. Но без фундаментальной коммуникации оно не сработает. Базово не нужно допускать в отношениях твиста в стиле «момент, когда Дэйнерис превращается в Безумную королеву». В точках выбора реакции и линии поведения не нужно take it too personal. Это не личное. Но может становиться личным очень быстро, а неприязнь порождает неприязнь.
Конструктивные отношения не значит дружеские: считается, что тестировщику и программисту не нужно быть в конфронтации, но и дружить вредно, это отразится на объективности и качестве тестирования. Приятельствовать лучше тогда, когда вы уже будете работать в разных компаниях или над разными продуктами.
Третье: самоуважение и уважение другого. Качество работы тестировщика прямо связано с воронкой продаж, с популярностью ПО, с его репутацией в соцсетях и комьюнити, с рекомендациями. Если тестировщик честно делает свою работу, то у него есть все основания для профессионального самоуважения. Не нужно подстраиваться из позиции нижестоящего и менее значимого сотрудника, это только повредит: тестировщику, программисту, менеджеру, продукту, рабочей культуре в компании и паттернам в отрасли. Достаточно уважения, доброжелательности, сотрудничающего настроя, разумной рабочей дистанции, соблюдения правил, согласованных в сотрудничестве с менеджером и программистом, а также понимания общей цели.
Парадокс разработки и тестирования состоит в том, что тестировщик со временем видит разрабатываемую систему гораздо более целостно, чем программисты, которые пишут отдельные модули. В какой-то момент, тестировщик, QA-инженер становится экспертом по конкретному программному обеспечению. Для Quality Assurance специалиста важно найти баланс между самоуважением и уважением к другой стороне.
Четвертое: при тестировании подходить реалистично, ранжировать и документировать обнаружение дефектов разработки. В одном из первых интервью ALMAMAT Blog QA-инженер Setka Сабина Хасанова упомянула о тестировщиках-баголовах, которые рассматривают количество багов как ачивки, достижения, гордятся самим количеством. Надо понимать, что программист потратит много времени на исправление каждого бага. Одни действительно важно поправить ASAP, а другие несущественные.
Пятое: приоритезировать цель, а не задачи. Тестировщик ищет баги. Программист пишет код. Это их задачи. Цель менеджера – своевременные релизы чистого продукта, которым потребителю удобно использовать. Задачи программиста и тестировщика часто путают с реальной общей целью – для чего это делается. Этих специалистов нанимают для того, чтобы качественный продукт работал на рынке и приносил прибыль. Это их повседневная цель в каждой итерации работы над продуктом. И каждую итерацию работы они достигают этой цели через решение своих задач: написание кода и тестирование кода на предмет дефектов разработки. С точки зрения бизнеса, задачи сотрудников являются средством достижения цели. Общая цель – релизить качественный продукт и корректно работающие обновления.
Шестое: принцип «креативной пары». Креативными парами называют небольшие команды в рекламном бизнесе. Тот же принцип полезен и в разработке – не буквально, речь именно о принципе. Решение о реструктуризации команды и организации ее работы над продуктом находится в полномочиях менеджера.
Есть работающая модель, которая не предполагает разделения на отдел разработки и отдел тестирования. В самом разделении заложена конфронтация тестировщиков и разработчиков, а также сильная рассинхронизация. Если же речь идет о смешанных командах, осознанно работающих на общую цель, тогда принцип «тестировщик vs программист» сменяется принципом «тестировщик & программист». То есть создаются команды, состоящие из тестировщиков и программистов: они дополняют друг друга, совместно планируют релиз, а тестировщики при этом могут заранее готовиться к тестированию и делать вклад в разработку, потому что видят продукт целостно, становятся экспертами по продукту.
Седьмое: программист по архетипу своей роли и применяемому стилю мышления – «созидатель, строитель». Тестировщик по архетипу своей роли и применяемому стилю мышления – «критик, разрушитель». При тестировании он имитирует задачу изобретательными способами сломать систему, чтобы увидеть, при каких условиях она перестает работать, и показать программисту, где нужно укрепить или перестроить конструкцию. Важно понимать и помнить, что это архетипы ваших ролей, стили мышления, которые применяются именно в этих ролях. Люди не сводятся к ролям, а разные стили мышления мы применяем опционально при решении разных задач. almamat blog
Тестировщик vs разработчик / Habr
Сегодня я бы хотел затронуть тему процесса разработки программного обеспечения. Если точнее, эта статья о том «Как не превратить офис в поле битвы тестировщиков и разработчиков».Полгода назад я погрузился в тестирование ПО, мне было интересно и я понял, что это действительно моё. Часами залипал на форумах тестировщиков, читал литературу и изучал процесс разработки ПО. На форумах, в группах и беседах я частенько замечал приколы про взаимодействие тестировщиков и разработчиков, но я не понимал этих шуток и не обращал на это внимание. По крайней мере, пока не попал на стажировку в одну компанию по разработке ПО.
Через пару месяцев я начал догонять смысл этих приколов и активных обсуждений «Tester vs Developer». Так как я был первым тестировщиком в этой компании, освоиться было сложно. Задачам с пустым описанием, но с названиями «протестируй и отпишись», «проверь сайт», «не работает приложение» не было конца, а разработчики и проджект менеджер вообще не знали понятие QA. Всем знакома эта фраза «Без ТЗ – результат ХЗ», так вот там было тоже самое. Плюс ко всему этому, никого не волновало то, что продукт мягко говоря «кривоват». В большинство случаев было так: ты получаешь задание «протестируй» — тестируешь, делаешь отчет о найденных дефектах и передаешь их разработчику, ну а у разработчика эта задача могла висеть месяцами. В итоге шеф посчитал, что тестировщик в штате лишний и для меня этот кошмар закончился, ну а продукт так и остался «кривым».
Бывают разные споры, разногласия, но мне кажется, что уже давно пора придумать какой-нибудь простой подход, чтобы избежать подобных случаев.
Скриншот из беседы тестировщиков ПО:
Найти дефект — задокументировать — передать разработчику для исправления. Но опять-таки, вроде бы всё просто, если бы не реакция разработчика на свои ошибки. Наверное он просто забыл о том, что задача тестировщика это поиск ошибок и сбоев в функционировании объекта. В итоге мы как дружное сообщество начали давать разные советы бедной даме. Многие предлагали решать вопрос через тимлида, а некоторые даже предлагали набить лицо за такое отношение. Ну а я предложил свой вариант, но многим он показался странным.
Через некоторое время я попал на один интересный проект, в котором проджект менеджер был мостом между тестировщиком и разработчиками. Я не знаю, насколько эта концепция эффективна, но мы за всё время ни разу не поругались. Как баг трекинговую систему мы использовали Trello. Эта система удобна тем, что она вся построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии. Но это же и главный минус программы. Она слишком простая и не предназначена для больших команд.
От проджект менеджера прилетала задача, во время тестирования каждый баг оформлялся в отдельную карточку и прикреплялся в блок «Баги» с меткой «Недочёт» и с подробным описанием. Затем проджект менеджер задавал приоритет карточке и закидывал одному из разработчиков. Иногда такое бывает, что сроки горят и до встречи с заказчиком нужно проверить самые важные моменты. В таком случае проджект менеджер задавал высокий приоритет багам связанных с бизнес логикой, а баги связанные с UI откладывались на потом. У многих возникнет вопрос » Кто тогда будет отвечать за упущенные баги в прод? «, к сожалению мы сам не в курсе.
Самое важное в таком процессе, это то, что тестировщик не взаимодействует с командой разработчиков, следовательно, нет криков, ссор и споров:
— Да это же баг!
— Нет, это фича!
Если в вашей команде адекватный project manager или product owner, попробуйте протестировать такой подход. Я думаю, что многим понравится. Конечно же, есть компании, в которых отношение разработчиков и тестировщиков идеальное. Например, в которых за упущенные баги в продакшн и жалобы пользователей отвечает разработчик. В таком случае разработчик сам будет заинтересован в хороших отношениях с тестировщиком. Но опять-таки возникает вопрос » А сколько компании работают по по такому принципу? «
Всем спасибо за внимание.
Живут, как тестировщик с программистом / Habr
Часто задают вопрос: как быть с тем, что программисты не любят тестировщиков, считают их работу второстепенной, пишут неряшливо – «все равно ведь проверят» либо мстят за каждый найденный баг и пытаются не признавать их за баги.
Или наоборот, программисты жалуются, что тестировщики злорадствуют, найдя баг, и считают личным достижением, если программист наделал много ошибок.
Cтандартные в таких случаях советы: объясняйте, мирите, аргументируйте, — выглядят, как будто перед программистами оправдывают существование тестировщиков. Постфактум решать такую проблему (а это очень критичная проблема) очень трудно. Нужно закладывать правильную атмосферу при построении команды и носить это правильное отношение к работе за собой из команды в команду, из компании в компанию.
Знаете, в чем на самом деле фишка? В разности целей! Просто описанные тестировщики и программисты ходят на работу не за одним и тем же, не с одной целью. У них нет атмосферы работы в одном направлении. У них нет понимания того, что они делают, на самом деле, одно и то же дело, только с разных сторон.
Конечно, все работают ради разного: кто-то ради зарплаты, кто-то ради решения интересных задач, кто-то ради получения бесценного опыта. Но для достижения личных целей нужно работать в направлении целей проекта, продукта, компании. Тогда будет и зарплата, и опыт, и интересные задачи. Судите сами, если бы целью программиста был выпуск качественного продукта, успех проекта, процветание компании, и он бы работал на это, то это бы просто автоматически работало на его личную цель. И при таком раскладе никогда не прозвучит «это не баг», потому что любое подозрение на баг таким специалистом принимается и рассматривается.
Как раз сейчас я краем глаза смотрю запись гран-при Канады Формулы 1.
Феноменальный пример слаженной, однонаправленной командной работы. Есть 2 части команды: собственно, перформер, пилот, человек, который на виду, который пожинает лавры в глазах публики, но который на каждой пресс-конференции говорит про работу всей команды, и есть та самая команда-тыл, которая смотрит на его работу на трассе, анализирует её и говорит в шлемофон: «Кубица сменил резину на жесткую, Барикелло тоже, не дай себя обойти». А теперь представьте, что команда отлавливает ошибки пилота и злорадно сообщает ему «Из-за того, что ты не сменил резину на прошлом пит-стопе, потерял 2 секунды во время дождя». Как только части команды начинают работать друг против друга – она обречена на провал!
Давайте посмотрим на команду разработки. Нам явно нужна классификация. Сначала хотелось назвать описываемых героев Хорошими Тестировщиками (или Программистами) и Плохими Тестировщиками (или Программистами). Потом подумала, что тогда в этом мире получится очень много плохого, а это не так. Поэтому у меня будут Просто Программисты (или Тестировщики) и Правильные Программисты (или Тестировщики).
Признаки того, что ваши программисты и тестировщики не Правильные:
— от тестировщиков всерьез звучат фразы «наколбасил им багов, пусть теперь разгребают»
Это идет от старших тестировщиков и от общей атмосферы в коллективе. Я ещё не видела ни одного неопытного тестировщика, который бы думал так с самого начала.
Если старший коллега хочет вырастить злобное чудовище, которое радуется при нахождении бага не потому, что теперь пользователь получит на одну ошибку меньше, а потому, что насолил программисту, то ему стоит продолжать в духе «Давай, сынок, покажем этим кодерам, что за какашку они выпустили бы без нас ». Но если он хочет, чтобы тестирование работало не против программирования, а совместно с ним на качество продукта, и ведет себя соответственно, то никогда в его команде не будет такого.
— от программистов слишком часто звучит презрительное «это не баг»
Это значит, что каждый баг воспринимается как личный тычок: «Это твоя личная ошибка, слышишь? Ты непрофессионал. Хорошие программисты пишут без ошибок, а ты баг сделал, эх, ты». Думаю, что здесь проблемы надо искать в личности такого специалиста. Адекватный человек, направленный на развитие, использует любую критику для совершенствования, а не для обид. Тем более, когда критикуют работу, воспринимать это как личную критику – выглядит, как болезнь.
— программист не проверяет результат своей работы перед передачей в тестирование
«Моё дело писать код, а их дело проверять», «Ну а их-то зачем понанимали?» — можно услышать в таких командах. Это элементарное отсутствие гигиены, работа ради «отписаться». Где вы видели журналиста, который не перечитывает свою статью перед тем, как передать её в редактуру? Если в коллективе есть программист, который проповедует такой подход, его нужно как можно скорее ликвидировать. Какой бы он ни было классный специалист.
— тестировщики заносят баги, не интересуясь их дальнейшей судьбой
Это позиция «с моей стороны пуля вылетела» с другой стороны.
Цель тестирования – найти как можно больше ошибок в приложении, безусловно, имеет право на жизнь на определенных этапах тестирования. Только в этом определении не хватает второй части. Исправить. В силах тестировщиков донести важность важных багов до программистов и честно сказать про низкий приоритет низкоприоритетных. Если программисты знают, что их тестировщики зря хайприорити не поставят, то они серьезно относятся к каждому такому багу. А вот массированная атака багами без интереса к их дальнейшей судьбе, без подвижек в сторону облегчения их локализации, действительно является результатом работы только на себя.
— эффективность работы тестировщиков измеряется количество найденных багов, а мера качества работы программистов обратно зависит от этого количества
Это первый шаг, который толкает хороших специалистов и неплохих (я уверена) людей грызться на работе. Если работа не измеряется конечным качеством выпускаемого продукта, а лишь количественными показателями работы, то люди и работать будут на количество. Тестировщики на увеличение, программисты на уменьшение.
В то время, как только подход «максимум найти и тот же максимум обезвредить» эффективен, на мой взгляд, и работает действительно на цели продукта.
Уверена, что список можно продолжить.
При этом, чувствуете? В первом и четвертом случае корень проблемы в Просто Тестировщиках, во втором и третьем — в Просто Программистах, а в пятом — в Просто Менеджерах. Оказавшись в одной из таких команд, первым делом нужно понять, от кого исходит этот вирус и искоренить его. Либо уйти. Потому что продуктивной работы все равно не получится.
5 мифов о тестировщиках, или Как устроиться в Veeam с помощью табуретки
Удивительно, но это приметы специалиста по качеству ПО (Quality Assurance). Не забудьте добавить сюда технический бэкграунд или живой интерес к технике. Почему же тогда, услышав слово «тестировщик», мы представляем себе совсем другой образ?
Глава департамента обеспечения качества ПО Veeam Software Игорь Кацев рассказал нам, кто такой тестировщик, и развенчал несколько популярных мифов об этой профессии.
Бытует мнение, что в тестировщики идут те, кого не берут в программисты. Что это занятие для тех, кто не нашел себя в чем-то более интересном, а сам процесс тестирования — бесконечное нажимание кнопок. Даже в самом слове «тестирование» есть нечто вторичное, ведь первичен тот, кто написал код.
На самом деле тестировщик и программист — две разные профессии. Людей, выбирающих первый или второй вид деятельности, многое отличает. Часто это люди с разными типами мышления, разными взглядами на мир. При этом они дополняют друг друга: каждый из них обладает своими ценными качествами и играет в проекте ключевую роль. Разумеется, у тестировщика столько же сложных задач, ответственности и радости от успешного релиза.
Тестировщик — это не стартовая площадка в ИТ с последующим ростом до кого-нибудь «поважнее». Это сложная самостоятельная профессия, требующая не столько образования или опыта, сколько особого склада ума и таланта к этому виду деятельности.
QA-специалист выделяется своим критическим мышлением, цепким взглядом, тем, что видит скрытую комбинаторику и вариативность за разными процессами. Там, где другой айтишник увидит два-три типовых сценария, тестировщик представит 64 возможных варианта. Это часто делает его уникальным.
Во-первых, существуют стратегии тестирования, не предусматривающие работу с кодом. Тестировщик получает знания о системе из множества других источников. Во-вторых, сам тестировщик — это сложный «сплав» разных способностей. Его здравый смысл, четкая логика и вариативное мышление бывают гораздо ценнее знания языков программирования.
Согласитесь, читать шесть миллионов строк кода, сто тысяч из которых меняются еженедельно, едва ли проще, чем каждый день перечитывать «Войну и мир». Освоить все языки и технологии вряд ли возможно, а протестировать любой продукт — запросто. Даже табуретку, на которой вы сидите.
Цель тестировщика — убедиться, что пользователи получат качественный продукт. Он всегда в центре событий, много общается с людьми. Его работа многогранна, и каждый его день может быть не похож на предыдущий.
Например, в понедельник он примеряет на себя роль системного администратора и разворачивает сложную инфраструктуру.
Во вторник он «аналитик» — обдумывает требования к программе, критикует принятые решения, предлагает свои идеи.
В среду собирает информацию у всех участников процесса, планирует свое тестирование.
В четверг ставит миллион разных экспериментов.
В пятницу участвует во встречах, посвященных развитию продукта. Или проходит обучение. Или гоняет продукт в «свободном полете», находя редкие и трудноуловимые ошибки. Как в такой график вписать рутинную работу?
Тестировать сложные продукты нужно с пониманием того, как они устроены, в какой среде функционируют. Так что технический бэкграунд тестировщику нужен. Но если вы покажете, что умеете думать, накидывать варианты, протестируете обычную табуретку так, что ваш язык не будет успевать за полетом вашей фантазии — нам станет не важно, что написано в вашем дипломе и трудовой.
Вот показательные случаи нашей команды, когда люди сменили свою профессию в пользу тестирования:
- бухгалтер с опытом десять лет, без технического образования;
- специалист по безопасности труда и жизнедеятельности с опытом пять лет;
- системный администратор с опытом пять лет.
Если у вас нет технического образования, но есть опыт или интерес к сфере ИТ или другой технической области, попробовать стать тестировщиком можно и нужно.
У тестировщика есть два основных направления развития — главное, попасть в правильную среду. Если он будет активно развиваться в профессиональном и техническом плане, то станет крутым и востребованным специалистом в области QA. Если ему интересен административный рост — он может стать руководителем и управлять командами и проектами.
Тестировщику будет комфортно на любой работе, связанной с аналитикой, обеспечением качества, управлением проектами или реализацией своих собственных идей.
Примерить на себя роль тестировщика и погрузиться в профессию вы сможете во время стажировки в Veeam Software. Если вы оканчиваете технический вуз, хотите сменить профессию или, прочитав наше объявление, узнали себя — вам обязательно стоит попробовать свои силы. Вас ждут интересные задачи, крутая команда, растущий оклад, возможность переезда в Прагу, медстраховка, фитнес и прочие приятные атрибуты крупной ИТ-компании.
Вакансии VeeamP.S. А если вы заметили странность с количеством мифов — советуем не затягивать!
программисты vs. тестировщики! / Habr
Когда-то я был тестировщиком. Помню, как в те далекие времена порой был крайне недоволен программистами:
Эти вечные сомнительные доводы «это не баг, это фича» или «если это и баг, то незначительный, пусть остается».Да как же остается, если система колом встает!?
Потом я стал программистом. И всё изменилось – меня начали жутко бесить эти бесконечные возвраты на доработку:
То им это не нравится, то тут не работает! Да нафига было вообще в этом окне контекстное меню вызывать и вставлять нечитабельные символы!? Как они вообще до этого додумались!? Бред же, в боевом режиме так ни один пользователь не сделает!Не буду править, пусть остается!
В общем, классика – вражда программистов и тестировщиков.
А потом я стал менеджером. И понял, что вражда эта губительна для общего дела. К счастью, я хорошо помнил себя и программистом и тестировщиком, что и помогло мне осознать истинную суть проблемы и изменить ситуацию.
Процесс
В те времена у нас был очень простой и понятный процесс разработки:
Задачи —> Программирование <—> Тестирование —> Релиз
Причем
- Тестировщики узнают о задачах только в момент передачи их в тестирование, т.е. о начале разработки новой задачи они уведомлений не получают.
- Программисты не дожидаются завершения тестирования задач и приступают к новым задачам немедленно.
А что, это же пример идеальной инкапсуляции!
У программистов
- на вход: новые задачи и возвраты из тестирования.
- на выход: передача задач в тестирование.
У тестировщиков
- на вход: задачи от программистов.
- на выход: возврат задач программистам и официальный выпуск версии.
Собственно, процесс не плох сам по себе – каждый живет в своем мире и занимается любимым делом.
Цель
Но ведь у этого процесса есть вполне конкретная конечная цель – выпускать качественное ПО с нужным функционалом в срок.
Собственно, в этот момент и начинаются проблемы.
Проблемы
Однажды приходит менеджер и начинает напоминать о конечной цели.
Типичная ситуация: Менеджер приходит к программистам и спрашивает «когда?», а они отвечают «не знаем, мы все сделали, спроси у тестировщиков».
Менеджер идет к тестировщикам с тем же вопросом «когда?», а они ему отвечают «разработка только утром выдала сборку, мы только приступили к тестированию, и точно будет возврат – тут багов уже много вылезло, поэтому мы не знаем когда будет выпуск – спроси у программистов».
И менеджер начинает ходить по кругу туда-сюда, а релиза все нет и нет.
В итоге, терпение менеджера кончается, он собирает программистов и тестировщиков вместе и пытается как-то решить вопрос. Собственно, все решения сводятся к выработке правил взаимодействия между программистами и тестировщиками. И все дальнейшие усилия менеджера направлены на контроль за соблюдением этих правил.
Вот некоторые правила, которые сформировались в нашем отделе спустя несколько месяцев изнурительной работы менеджера:
- Совместное планирование. Версия планируется заранее. На планировании присутствуют и программисты и тестировщики. Благодаря этому, все заранее знают, что им предстоит делать. Например, это позволяет тестировщикам заранее начать составлять планы тестирования и подготавливать необходимое тестовое окружение.
- Разработка в бранчах. Разработчик не вливает новых задач в основную ветку до тех пор, пока все уже влитые задачи не будут протестированы. Это позволяет избежать «снежного кома», т.е. эффекта накопления большого количества наполовину сделанных задач в основной ветке. И так же не дает бездельничать программистам – они всегда могут делать следующую задачу в бранче.
- Маленькие версии. Это попытка сократить разработку в бранчах, ведь это накладные расходы на мердж, актуализацию кода и повторное тестирование. Если делать маленькие версии, то можно работать сразу в основной ветке.
- Ничегонеделанье. Ещё одна попытка сократить разработку в бранчах. Когда в бранчах накапливается много задач, и разработка сильно убегает вперед от тестирования, то программистам разрешается просто ничего не делать, чтобы ещё больше не убегать вперед.
- Раннее информирование. Например, тестировщик приступил к тестированию задачи. Задача большая, но он уже сразу нашел дефект. Он сообщает об этом программисту сразу при обнаружении, а не в конце, когда все тестирование завершено. Или наоборот, программист ещё во время разработки сообщает тестировщику о нюансах реализации, чтобы тот заранее подготовил тест-план. Это вроде как позволяет распараллелить работу программиста и тестировщика.
Все эти правила на самом деле хоть и помогли улучшить ситуацию, но кардинально её не изменили. Они как будто затыкали по одной маленькой дырочке. Чувствовалось, что есть какое-то другое решение, что что-то упущено из виду.
Например, как только менеджер расслаблялся – почти сразу все договоренности между программистами и тестировщиками забывались, и все возвращалось к исходному состоянию.
Более того, взаимоотношения между программистами и тестировщиками не улучшались – как была вражда, так она и осталась.
Осознание
Прошло ещё немало дней и ночей, когда я много думал о причинах происходящего, о поведении людей, об их эмоциях, потребностях и мотивах.
А потом вдруг всё стало ясно!
Да ведь сама структура такого подхода, когда «одни программируют – другие тестируют» порождает конфликт между программистами и тестировщиками.
И вся суть этого конфликта в том, что У НИХ РАЗНЫЕ ЦЕЛИ!
У тестировщиков цель «протестировать».
У разработчиков цель «разработать», т.е. «передать в тестирование».
А цель «выпустить релиз» только у менеджера. И только пока он прикладывает к этому усилия – она достигается.
А когда у людей разные цели – им не по пути, они не интересны друг другу. Как их не притягивай, они все равно будут идти своей дорогой, в разные стороны.
Решение
Собственно, решение проблемы и заключается в том, чтобы поставить и перед программистами и перед тестировщиками одну общую цель.
Причем цель очевидную – выпуск качественного релиза в срок.
Ведь не достигая эту цель, локальные цели «разработать» и «протестировать» теряют всякий смысл.
Это как то знаменитое высказывание, что для кого-то деньги – это цель, а для кого-то средство.
Т.е. программирование и тестирование – это средства, пусть и приятные – это даже хорошо, но все же средства. А цель – это релиз.
Ясно, что изменить цели оказалось делом не простым. Но поскольку я полностью проникся логикой своих мыслей – то был готов сломить любое сопротивление изменениям!
Вот основное, что было сделано:
- Изменена организационная структура отдела. Вместо отделов разработки и тестирования сформированы команды, в которых собраны и программисты и тестировщики.
- Переезд. Вновь сформированные команды получили по отдельной комнате. Теперь не было ситуации, когда тестировщики и программисты сидят в отдельных комнатах и живут своей жизнью.
- Пропаганда. Естественно, пришлось сказать немало пламенных речей о том, для чего и почему мы затеяли реорганизацию. И главное – донести до всех общую цель, для чего мы вообще здесь все собрались. Поскольку люди все грамотные, а идеи логичные – пропаганда получилась легкой и успешной.
- Увольнение. Увы, но кто-то не согласился с новыми идеями. Но оно и к лучшему, они уступили дорогу тем, кто теперь приносит куда больше пользы!
И все эти усилия того стоили! Эффект оказался просто поразительным!
- Напряженные отношения между программистами и тестировщиками исчезли, как будто и не было.
- Появилась взаимная поддержка, продукты стали качественнее.
- Программисты стали помогать тестировщикам, указывая на узкие места, которые стоит дополнительно проверить.
- Изменилось общее отношения к обнаруживаемым дефектам. Никто никого не считает виноватым. Даже наоборот, разработчик благодарен тестировщику, что тот помог сделать продукт лучше!
- Все договоренности о взаимодействии программистов и тестировщиков стали выполняться сами собой – потому что все поняли их эффективность.
- В общем, все заработало как часы – регулярные релизы, качественный продукт.
На глазах, за какие-то полгода, произошло настоящее преображение!
Вывод
У любого конфликта всегда есть истинная причина. У типичного конфликта между программистами и тестировщиками истинная причина – это разные цели. Стоит поставить перед ними одну общую цель – и все сразу изменится! Программисты и тестировщики станут лучшими друзьями, всегда будут помогать друг другу, а от этого выиграют все – и программисты, и тестировщики, и менеджеры, и продукты, и компания!
Программист vs тестировщик: «Некоторые думают, что главное — найти в программе как можно больше ошибок» | Статья
Программист vs тестировщик: кто смотрит на программу шире, а кто — глубже? Как сделать карьеру в отделе тестирования? Является ли эта профессия творческой? На эти и другие вопросы отвечают специалисты компании «Топ Софт» (белорусский офис корпорации «Галактика»).
Читать далее…
В беседе участвуют: начальник отдела интегрального тестирования Наталья Горавская, руководитель экспертной группы ОИТ Александр Ализарчик, начальник отдела тестирования Xafari Владимир Курганович и начальник отдела тестирования департамента «Управление персоналом» Дмитрий Яковцев.
Говорят, основной продукт тестировщика — ошибка (точнее, описание найденных ошибок, которое передается программистам). Согласны?
Наталья Горавская: Понятно, что любая программа содержит ошибки и возможности улучшения, и тестирование — бесконечный процесс. Система «Галактика ERP» развивается и сопровождается уже 23 года — и все это время тестировщики постоянно в этом участвуют. Однако наша работа только к поиску ошибок не сводится.
Один из основоположников современного тестирования ПО Борис Бейзер описал пять стадий становления тестировщика. Нулевую, низшую стадию он определял так: цель тестирования — помощь в поиске и исправлении ошибок.
Мы тоже поначалу считали, что цель тестирования — поиск и исправление ошибок. Но, по мере того, как менялись требования к ПО, запросы наших заказчиков — эволюционировали и наши взгляды. Мы стали рассматривать тестирование как один из ключевых элементов обеспечения качества ПО.
Ещё говорят, что программисты относятся к тестировщикам снисходительно, считая их младшим обслуживающим персоналом.
Наталья Горавская: Многие коллеги из других служб признают, что тестировщики лучше знают функционал системы в целом. Конечно, тот же программист глубже знает конкретные процессы, над автоматизацией которых работает. Зато тестировщик — знает процессы шире. Ведь мы находимся в постоянном цикле «разработка — проверка» для разных модулей, продуктов и заказных проектов. Мы отслеживаем изменения программных продуктов на протяжении многих лет. Мы лучше видим взаимосвязи между программными компонентами и пользовательскими функциями.
Например, начинающий программист может не знать, что данная информация в данном модуле будет использоваться еще в четырех или пяти модулях. А опытный тестировщик — знает. И обязательно проверит все эти взаимосвязи. Поэтому представители всех служб, в т. ч. разработчики, часто обращаются к нам за консультациями.
Добавлю, что, если у сотрудника достаточный уровень знаний в предметной области и общих вопросах, если человек умеет находить решения сложных проблем, делать оценки, прогнозировать поведение системы, искать потенциально узкие места в работе программы — на него в «Топ Софте» вряд ли кто-то посмотрит свысока.
Ещё одно распространенное мнение: тестировщики и программисты часто конфликтуют.
Наталья Горавская: Может быть, в первые годы существования отдела тестирования, когда мы были молоды, бескомпромиссны и стремились настоять на своем — искры конфликтов и мелькали. Но сейчас авторитет тестировщика в компании вырос. Программисты сами заинтересованы поскорее передать продукт, чтобы мы его посмотрели. Они охотно используют наши знания и свежий взгляд со стороны.
Это не значит, что споров, дискуссий совсем не бывает. Никто не любит признавать свои ошибки — и это характерно не только для IT-среды. Иногда разработчикам трудно понять, каково приходится пользователям, осваивающим сложный продукт.
И тогда задача тестировщика — убедить разработчика, что, если предлагаемые изменения не будут внедрены — неизбежен конфликт нашей компании с заказчиком. Программу пишет не тестировщик, но ответ за ее работу приходится держать и нам. Наш отдел — выпускающая служба, которая отвечает за качество конечного решения.
Какие требования к качеству бизнес-приложений предъявляют сегодня белорусские пользователи?
Наталья Горавская: В первую очередь, их интересует функциональная полнота программных продуктов. Заказчик хочет, чтобы ему помогли автоматизировать востребованные у него бизнес-процессы и сделали это сегодня. Но при этом важно, чтобы в первую очередь решались наиболее актуальные задачи. А задача тестировщиков — проверить полноту и корректность реализации требований на разработку.
Для многих предприятий критически важна скорость обработки больших объемов данных. Контроль быстродействия системы — постоянная работа подразделений тестирования. Также для пользователей важна своевременная поддержка изменений в законодательстве, функциональная преемственность информационной системы в ходе сопровождения, эргономичность, совместимость с новыми операционными системами и версиями СУБД. Контроль соответствия программных продуктов по всем перечисленным параметрам — и есть наша главная задача.
Какие технологии вы для этого используете?
Александр Ализарчик: Хорошее познается в сравнении. Поэтому позволю себе начать издалека. В 
середине 1990-х к тестированию новых релизов Галактики ERP приходилось привлекать сотрудников других служб «Топ Софта», вплоть до отдела продаж. Но все равно весь процесс занимал, как минимум, 2–3 месяца. Пользователи подолгу ждали исправления ошибок, появления запрошенных функций, поддержки изменений законодательства и т. д.
По мере развития функциональности системы рос и объем необходимых работ по тестированию. Все отчетливее вырисовывалась проблема обеспечения устойчивости системы, сохранения функциональной преемственности, которая решается только регрессионным тестированием.
В конце 90-х годов нашей корпорацией была разработана и силами отделов тестирования Москвы и Минска внедрена система автоматизированного тестирования AQA.
Известно, что каждое изменение программного продукта имеет определенную вероятность внести ошибку. Самые трудноуловимые ошибки — те, что появляются в уже многократно проверенных компонентах. Только автоматизированное тестирование после модификации кода однозначно позволяет обнаружить эти ошибки там, где тестировщик с большой вероятностью мог бы их пропустить.
Эта возможность особенно важна при выпуске релизов, а затем — и обновлений. Сжатые сроки требуют специальной методики обеспечения надежности. Никакая команда тестировщиков не может вручную за несколько дней пройти хотя бы типовые бизнес-процессы и гарантировать полное сохранение работоспособности, поэтому основной объем проверки функциональности стал возлагаться на автоматизированную систему. Новые и модифицированные функции могут быть проверены только вручную, однако при этом производится запись сценариев для их автоматизированного тестирования в дальнейшем.
— Не проще ли было приобрести аналогичный продукт у одной из компаний, которые специализируются на их разработке?
Александр Ализарчик. Увы, ни одна из присутствующих на рынке систем тестирования не учитывала специфику нашего ПО. Например, ERP-системы работают с базами данных — но ни в одной системе не было возможности начинать каждый тест с восстановления исходной базы данных.
С помощью AQA мы воспроизводим условия эксплуатации системы на крупных предприятиях и в распараллеленном режиме проводим глубокое тестирование ее функциональности, функциональной преемственности, производительности, масштабируемости, устойчивости системы под нагрузкой и др.
Сильно ускоряет процесс использование ранее созданных библиотек тестов. Тестировщик может в одиночку, не отвлекая коллег, провести большой комплекс работ. И обращается к автору библиотеки только в случае ошибок, которые не может сам диагностировать.
Дмитрий Яковцев: Самое ценное в AQA — простота использования. Кроме того, когда для тестирования новых задач нам нужны доработки самой системы AQA — мы довольно быстро их получаем. Мы сами формулируем новые требования к ее функционалу и предлагаем решения. Со сторонними системами это было бы невозможно.
AQA встроена в систему «Галактика ERP», имеет тот же интерфейс, хорошо документирована, так что любой заказчик может ее легко освоить и использовать, как для обеспечения эксплуатации развернутой у него конфигурации, так и для тестирования собственных разработок.
Наталья Горавская: Немаловажно, что сторонние системы тестирования — недешевы, особенно в пересчете на количество рабочих мест. Если бы мы ими пользовались, корпорации «Галактика» пришлось бы существенно повысить стоимость своих программных продуктов.
Владимир Курганович. AQA используется для автоматизации тестирования «Галактики ERP» и других 
продуктов, созданных корпорацией «Галактика» на собственной платформе разработки «Атлантис». А такие решения, как система управления производственными процессами предприятия «Галактика AMM», система управления активами предприятия «Галактика EAM» и другие, разрабатываются на нашей новой бизнес-платформе Xafari — которая, в свою очередь, развивает возможности Open Source платформы XAF компании DevExpress. Специалисты нашего отдела изучили возможности множества инструментов — и в итоге выбрали для автоматизации тестирования решений на Xafari систему EasyTest той же DevExpress. Ее плюс — платформонезависимость и простота использования EasyTest. А также, что немаловажно, возможность самостоятельной (силами собственных разработчиков) доработки, развития функционала этого инструмента под свои нужды.
— Наталья Васильевна, вы отмечали, что процесс совершенствования системы должен быть нацелен прежде всего на наиболее актуальные для заказчиков задачи. Как это удаётся?
Наталья Горавская: В этом помогает корпоративная система «Проблемы и решения». Мы и наши коллеги — программисты, внедренцы, специалисты техподдержки и других служб — фиксируем в ней все виды проблем, возникающих в ходе разработки и эксплуатации программных продуктов, предложения по их развитию, заявки на доработку и др.
ПИР помогает координировать работу служб, вовремя решать проблемы заказчиков. Информация из ПИРа подсказывает разработчикам, в каких новых функциях действительно нуждаются пользователи. А тестировщику — помогает писать тесты, позволяющие в сжатый срок проверить функциональность программы по заданным бизнес-процессам.
— Роль хороших инструментов нельзя переоценить. А каков вклад самого тестировщика, его опыта, профессионализма в решение проблем пользователей?
Наталья Горавская: Разумеется, роль интеллектуального труда тестировщика — основная. Ведь автоматизировать можно только то, в чем хорошо разобрался. Поэтому процесс тестирования начинается с анализа проектной документации. К слову, ключевые сотрудники отдела тестирования, учитывая их опыт и знания, часто привлекаются к согласованию технических заданий, технических проектов и аналитических записок, вносят свои предложения по разработке, развитию продуктов и т. д.
— Как бы вы оценили вклад службы тестирования в создание конечного программного продукта?
Владимир Курганович: Нужно учесть, что функционал разных решений различается степенью сложности, востребованности, проблемности. Соответственно, отличается и вклад тестировщика.
Наталья Горавская: Можно, оценивать, например, по соотношения ресурсных затрат, но это не всегда отражает общую картину. Для нас, во-первых, важно, что разработчики всегда стараются как можно быстрее передать нам на тестирование свои продукты. А во-вторых, мы подписываем «путевку в жизнь» каждой новой функциональности, каждому новому продукту.
— А если ошибка просочилась в программу?
Дмитрий Яковцев: Проводим анализ: почему ошибку допустили разработчики и пропустили тестировщики — и стараемся избегать подобных ситуаций в будущем. Регламент предусматривает, что по критичным — т. е. важным для пользователя — ошибкам обязательно пишутся тесты.
— Какие качества нужны тестировщику для успешной карьеры?
Владимир Курганович: Аналитический склад ума, знание предметной области, уравновешенность, стрессоустойчивость, внимательность, скрупулезность, ответственность, коммуникативность, умение аргументированно настоять на своем.
— Нужно ли быть программистом?
Наталья Горавская: Не обязательно. К нам приходят и люди без программистского образования — и через некоторое время успешно осваивают AQA и справляются со своими обязанностями.
Александр Ализарчик: Я заметил, что некоторые, кто приходил к нам, например, из бухгалтерской профессии — склонны ограничиваться констатацией найденных ошибок. Люди, прежде связанные с программированием и другими техническими специальностями, чаще стараются разобраться в причинах ошибки.
Дмитрий Яковцев: Но мы в каждом стремимся разбудить желание разобраться в причинах.
Наталья Горавская: Недавно в вузах появилась новая специальность — «Тестирование ПО». Но с выпускниками пока побеседовать не довелось. Как правило, к нам приходят те, кто окончил двухмесячные курсы тестирования программного обеспечения. Их слушателей обычно обучают на примере тестирования калькулятора. Многие выносят из этого опыта мнение: мол, главное — найти в программе как можно больше ошибок. И видят в этом суть будущей профессии. Приходится их переучивать.
Александр Ализарчик: Я всегда стараюсь максимально «запугать» кандидата на собеседовании, чтобы к нам не попадали случайные люди, которые уйдут уже через полгода.
— Сколько времени обычно занимает подъем на очередную ступень карьеры?
Наталья Горавская: Перейти с должности эксперта второй категории на первую — 2 года. Стать ведущим экспертом — 2–3 года, руководителем группы — 3–4 года. Если вы хорошо знаете предметную область — сразу идете на позицию эксперта первой категории. Ведущие специалисты получают право проводить обучение молодых сотрудников, разрабатывать планы отдела.
— Как распределяются обязанности в отделах?
Наталья Горавская: Согласно ресурсной схеме. В ОИТ за каждым тестировщиком закреплено несколько модулей продукта «Галактика ERP» по направлениям. Например: бухгалтерский контур, логистика, производство.
Также при распределении обязанностей стараемся учитывать способности, склонности специалистов. Кто-то преуспевает в умении скрупулезно проанализировать бизнес-процесс клиента, кто-то — в «быстром» тестировании новых решений (и находит при этом большое количество ошибок) и т. д.
— Регламентирован ли ваш рабочий день?
Наталья Горавская: В целом — да, потому что постоянно идет поток программных обновлений. Каждый тестировщик начинает день с мониторинга входящего потока в системе «Проблемы и решения». Идет подпитка знаний, анализ: какие ошибки возникли, по чьей вине, насколько они критичны, какие проблемы ставят пользователи, к каким обновлениям нужно готовиться и т. д.
В течение дня тестировщиков могут привлекать к совещаниям, связанным с развитием того или иного продукта, к анализу отчетов руководителей проектов разработки, к консультациям специалистов техподдержки и службы внедрения.
Дмитрий Яковцев: А наши повседневные задачи — это тестирование обновлений, написание и прогон тестов, выполнение различных регламентных работ и т. д.
— Вы можете назвать свою профессию творческой?
Наталья Горавская: Конечно. Например, бывает непросто подобрать правильную конфигурацию для тестов — программные компоненты, которые на реальном предприятии могут взаимодействовать с тестируемым компонентом. Или ответить на вопрос: почему на вашем компьютере система работает, а на компьютере пользователя — нет? Таких вопросов в течение дня может возникнуть немало.
— Вы можете назвать свою профессию творческой?
Дмитрий Яковцев: Довольно интересным и творческим получился проект по расчету заработной платы на 2 миллиона сотрудников, в котором мы участвовали с Александром Ализарчиком. Основной целью нагрузочного тестирования была оценка перспектив использования технологии распараллеливания процессов для обеспечения масштабируемости системы «Галактика ERP». Разработку технологии распараллеливания проводили в Департаменте разработки «Управление персоналом», поэтому для ее апробации был выбран один из самых ресурсоемких и затратных процессов в контуре «Управление персоналом» — расчет заработной платы. Результат расчета в системе «Галактика ERP на стенде компании Intel 2 миллионов лицевых счетов составил 8 часов 8 минут. Расчет на 1 миллион счетов прошел за 4 часа 1 минуту, на 100 тысяч — за 26 минут, на 10 тысяч — за 6 минут. В ходе проекта мы применили целый ряд нестандартных решений. Например, придумали и реализовали подход, когда для распараллеливания расчетов могут быть задействованы простаивающие мощности рабочих станций заказчика (в случае отсутствия или дефицита в это время достаточного объема вычислительных мощностей). При создании тестовых баз на 1 и 2 миллиона сотрудников также были придуманы и использованы оригинальные решения.
Александр Ализарчик: У нас любой проект — творческий. Например, мы нашли множество нетривиальных решений, когда создавали собственное средство обработки результатов тестов. Важно было получить наглядную картину уже протестированного функционала. Ведь у нас в службе работает около 30 человек, и нужен был инструмент координации командной работы.
Другой пример. По требованию одного заказчика я проводил тесты, имитирующие работу большого количества пользователей с использованием системы нагрузочного тестирования компании HP. Пришлось осваивать ее с нуля. Но основная проблема заключалась в том, что система HP больше ориентирована на тестирование веб-приложений. Писал специальные скрипты, подбирал режим работы системы для совместимости с desktop-приложениями, выезжал в командировку, настраивал оборудование и проводил измерения.
В итоге мы успешно продемонстрировали заказчику, что наше решение по нагрузочному тестированию показывает достоверные результаты. Что заказчика вполне устроило.
Текст: Юрий Смирнов
Фото: Андрей Давыдчик
Эта публикация подготовлена в партнёрстве с «Топ Софт»
Что такое партнёрский материал?
Унитарное предприятие «Топ Софт» УНП 100314702