Программист vs тестировщик: «Некоторые думают, что главное — найти в программе как можно больше ошибок»
Программист vs тестировщик: кто смотрит на программу шире, а кто — глубже? Как сделать карьеру в отделе тестирования? Является ли эта профессия творческой? На эти и другие вопросы отвечают специалисты компании «Топ Софт» (белорусский офис корпорации «Галактика»).
Читать далее…
В беседе участвуют: начальник отдела интегрального тестирования Наталья Горавская, руководитель экспертной группы ОИТ Александр Ализарчик, начальник отдела тестирования Xafari Владимир Курганович и начальник отдела тестирования департамента «Управление персоналом» Дмитрий Яковцев.
МифыГоворят, основной продукт тестировщика — ошибка (точнее, описание найденных ошибок, которое передается программистам). Согласны?
Наталья Горавская: Понятно, что любая программа содержит ошибки и возможности улучшения, и тестирование — бесконечный процесс. Система «Галактика ERP» развивается и сопровождается уже 23 года — и все это время тестировщики постоянно в этом участвуют. Однако наша работа только к поиску ошибок не сводится.
Один из основоположников современного тестирования ПО Борис Бейзер описал пять стадий становления тестировщика. Нулевую, низшую стадию он определял так: цель тестирования — помощь в поиске и исправлении ошибок.
Мы тоже поначалу считали, что цель тестирования — поиск и исправление ошибок. Но, по мере того, как менялись требования к ПО, запросы наших заказчиков — эволюционировали и наши взгляды. Мы стали рассматривать тестирование как один из ключевых элементов обеспечения качества ПО.
Ещё говорят, что программисты относятся к тестировщикам снисходительно, считая их младшим обслуживающим персоналом.
Наталья Горавская: Многие коллеги из других служб признают, что тестировщики лучше знают функционал системы в целом. Конечно, тот же программист глубже знает конкретные процессы, над автоматизацией которых работает. Зато тестировщик — знает процессы шире. Ведь мы находимся в постоянном цикле «разработка — проверка» для разных модулей, продуктов и заказных проектов. Мы отслеживаем изменения программных продуктов на протяжении многих лет. Мы лучше видим взаимосвязи между программными компонентами и пользовательскими функциями.
Например, начинающий программист может не знать, что данная информация в данном модуле будет использоваться еще в четырех или пяти модулях. А опытный тестировщик — знает. И обязательно проверит все эти взаимосвязи. Поэтому представители всех служб, в т. ч. разработчики, часто обращаются к нам за консультациями.
Добавлю, что, если у сотрудника достаточный уровень знаний в предметной области и общих вопросах, если человек умеет находить решения сложных проблем, делать оценки, прогнозировать поведение системы, искать потенциально узкие места в работе программы — на него в «Топ Софте» вряд ли кто-то посмотрит свысока.
Ещё одно распространенное мнение: тестировщики и программисты часто конфликтуют.
Наталья Горавская: Может быть, в первые годы существования отдела тестирования, когда мы были молоды, бескомпромиссны и стремились настоять на своем — искры конфликтов и мелькали. Но сейчас авторитет тестировщика в компании вырос. Программисты сами заинтересованы поскорее передать продукт, чтобы мы его посмотрели. Они охотно используют наши знания и свежий взгляд со стороны.
Это не значит, что споров, дискуссий совсем не бывает. Никто не любит признавать свои ошибки — и это характерно не только для IT-среды. Иногда разработчикам трудно понять, каково приходится пользователям, осваивающим сложный продукт.
И тогда задача тестировщика — убедить разработчика, что, если предлагаемые изменения не будут внедрены — неизбежен конфликт нашей компании с заказчиком. Программу пишет не тестировщик, но ответ за ее работу приходится держать и нам. Наш отдел — выпускающая служба, которая отвечает за качество конечного решения.
Какие требования к качеству бизнес-приложений предъявляют сегодня белорусские пользователи?
Наталья Горавская: В первую очередь, их интересует функциональная полнота программных продуктов. Заказчик хочет, чтобы ему помогли автоматизировать востребованные у него бизнес-процессы и сделали это сегодня. Но при этом важно, чтобы в первую очередь решались наиболее актуальные задачи. А задача тестировщиков — проверить полноту и корректность реализации требований на разработку.
Для многих предприятий критически важна скорость обработки больших объемов данных. Контроль быстродействия системы — постоянная работа подразделений тестирования. Также для пользователей важна своевременная поддержка изменений в законодательстве, функциональная преемственность информационной системы в ходе сопровождения, эргономичность, совместимость с новыми операционными системами и версиями СУБД. Контроль соответствия программных продуктов по всем перечисленным параметрам — и есть наша главная задача.
Какие технологии вы для этого используете?
Александр Ализарчик: Хорошее познается в сравнении. Поэтому позволю себе начать издалека. В
По мере развития функциональности системы рос и объем необходимых работ по тестированию. Все отчетливее вырисовывалась проблема обеспечения устойчивости системы, сохранения функциональной преемственности, которая решается только регрессионным тестированием.
В конце 90-х годов нашей корпорацией была разработана и силами отделов тестирования Москвы и Минска внедрена система автоматизированного тестирования AQA.
Известно, что каждое изменение программного продукта имеет определенную вероятность внести ошибку. Самые трудноуловимые ошибки — те, что появляются в уже многократно проверенных компонентах. Только автоматизированное тестирование после модификации кода однозначно позволяет обнаружить эти ошибки там, где тестировщик с большой вероятностью мог бы их пропустить.
Эта возможность особенно важна при выпуске релизов, а затем — и обновлений. Сжатые сроки требуют специальной методики обеспечения надежности. Никакая команда тестировщиков не может вручную за несколько дней пройти хотя бы типовые бизнес-процессы и гарантировать полное сохранение работоспособности, поэтому основной объем проверки функциональности стал возлагаться на автоматизированную систему. Новые и модифицированные функции могут быть проверены только вручную, однако при этом производится запись сценариев для их автоматизированного тестирования в дальнейшем.
— Не проще ли было приобрести аналогичный продукт у одной из компаний, которые специализируются на их разработке?
Александр Ализарчик. Увы, ни одна из присутствующих на рынке систем тестирования не учитывала специфику нашего ПО. Например, ERP-системы работают с базами данных — но ни в одной системе не было возможности начинать каждый тест с восстановления исходной базы данных.
С помощью AQA мы воспроизводим условия эксплуатации системы на крупных предприятиях и в распараллеленном режиме проводим глубокое тестирование ее функциональности, функциональной преемственности, производительности, масштабируемости, устойчивости системы под нагрузкой и др.
Сильно ускоряет процесс использование ранее созданных библиотек тестов. Тестировщик может в одиночку, не отвлекая коллег, провести большой комплекс работ. И обращается к автору библиотеки только в случае ошибок, которые не может сам диагностировать.
Дмитрий Яковцев: Самое ценное в AQA — простота использования. Кроме того, когда для тестирования новых задач нам нужны доработки самой системы AQA — мы довольно быстро их получаем. Мы сами формулируем новые требования к ее функционалу и предлагаем решения. Со сторонними системами это было бы невозможно.
AQA встроена в систему «Галактика ERP», имеет тот же интерфейс, хорошо документирована, так что любой заказчик может ее легко освоить и использовать, как для обеспечения эксплуатации развернутой у него конфигурации, так и для тестирования собственных разработок.
Наталья Горавская: Немаловажно, что сторонние системы тестирования — недешевы, особенно в пересчете на количество рабочих мест. Если бы мы ими пользовались, корпорации «Галактика» пришлось бы существенно повысить стоимость своих программных продуктов.
Владимир Курганович. AQA используется для автоматизации тестирования «Галактики ERP» и других
— Наталья Васильевна, вы отмечали, что процесс совершенствования системы должен быть нацелен прежде всего на наиболее актуальные для заказчиков задачи. Как это удаётся?
Наталья Горавская: В этом помогает корпоративная система «Проблемы и решения». Мы и наши коллеги — программисты, внедренцы, специалисты техподдержки и других служб — фиксируем в ней все виды проблем, возникающих в ходе разработки и эксплуатации программных продуктов, предложения по их развитию, заявки на доработку и др.
ПИР помогает координировать работу служб, вовремя решать проблемы заказчиков. Информация из ПИРа подсказывает разработчикам, в каких новых функциях действительно нуждаются пользователи. А тестировщику — помогает писать тесты, позволяющие в сжатый срок проверить функциональность программы по заданным бизнес-процессам.
— Роль хороших инструментов нельзя переоценить. А каков вклад самого тестировщика, его опыта, профессионализма в решение проблем пользователей?
Наталья Горавская: Разумеется, роль интеллектуального труда тестировщика — основная. Ведь автоматизировать можно только то, в чем хорошо разобрался. Поэтому процесс тестирования начинается с анализа проектной документации. К слову, ключевые сотрудники отдела тестирования, учитывая их опыт и знания, часто привлекаются к согласованию технических заданий, технических проектов и аналитических записок, вносят свои предложения по разработке, развитию продуктов и т. д.
— Как бы вы оценили вклад службы тестирования в создание конечного программного продукта?
Владимир Курганович: Нужно учесть, что функционал разных решений различается степенью сложности, востребованности, проблемности. Соответственно, отличается и вклад тестировщика.
Наталья Горавская: Можно, оценивать, например, по соотношения ресурсных затрат, но это не всегда отражает общую картину. Для нас, во-первых, важно, что разработчики всегда стараются как можно быстрее передать нам на тестирование свои продукты. А во-вторых, мы подписываем «путевку в жизнь» каждой новой функциональности, каждому новому продукту.
— А если ошибка просочилась в программу?
Дмитрий Яковцев: Проводим анализ: почему ошибку допустили разработчики и пропустили тестировщики — и стараемся избегать подобных ситуаций в будущем. Регламент предусматривает, что по критичным — т. е. важным для пользователя — ошибкам обязательно пишутся тесты.
— Какие качества нужны тестировщику для успешной карьеры?
Владимир Курганович: Аналитический склад ума, знание предметной области, уравновешенность, стрессоустойчивость, внимательность, скрупулезность, ответственность, коммуникативность, умение аргументированно настоять на своем.
— Нужно ли быть программистом?
Наталья Горавская: Не обязательно. К нам приходят и люди без программистского образования — и через некоторое время успешно осваивают 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
Читать на dev.by