Как работает тестер в праздники
9 сентября планета отмечает День тестировщика
Праздники — неизменные спутники народной жизни. Праздники для нас — это возможность доставить радость близким! И уж конечно, праздник — не календарное понятие, он происходит там, где его чувствуют, где его ждут. За последние годы в нашей жизни многое изменилось, но тяга людей к праздникам остается важным явлением любого человека.
Праздник «День тестировщика» является международным и отмечается он ежегодно 9 сентября. Хотя, День тестировщика и не стал пока официальным, но его могут отмечать все, кто имеет отношение к этой профессии.
История праздника День тестировщика
День тестировщика — прекрасный повод заглянуть на страничку истории.
Нужно сказать, что дата празднования Дня тестировщика была выбрана совсем неслучайно. В 1945 году именно в этот день произошло одно знаменательное событие в мире компьютерной техники. Оно заключалось в том, что ученые Гарвардского университета официально зарегистрировали первый в истории баг. А случилось это во время тестирования одной из вычислительных машин. Тогда ими был обнаружен настоящий мотылек, случайно попавший между контактами электромеханического реле. Оказалось, что он и стал причиной выхода машины из строя.
Ученые даже сделали об этом событии запись в свой техдневник. Проделанную работу они записали как «debugging», что можно дословно перевести с английского как «избавление от насекомого». С тех пор так стали называть процесс обнаружения и избавления от сбоев в работе компьютера.
Нужно отметить, что тот знаменитый мотылек был передан в музей вычислительной техники, где он и хранится до сих пор. Под его стендом имеется надпись, которая гласит, что этот мотылек стал первым из обнаруженных багов в истории компьютерной техники. С тех пор это слово стало широко использоваться компьютерщиками во всем мире. А тот день, когда насекомое было обнаружено, решено было сделать профессиональным праздником всех тестировщиков.
Однако есть данные о том, что этот термин использовался и до этого. По крайне мере, исследователям удалось отыскать письмо знаменитого американского изобретателя Т. Эдисона, в котором уже фигурировало данное слово. Оказалось, что еще в 1878 году он употреблял слово «баг» в том же самом значении.
Отмечается День тестировщика и в России, но пока в нашей стране о нем мало кто знает.
Профессия и работа тестировщика
Работа тестировщика заключается в проверке программного обеспечения (ПО). Нужно сказать, что еще недавно в России эту работу воспринимали как подработку на время учебы или как место для программистов-неудачников. Однако прошло некоторое время и все убедились в важности качества ПО. После этого данная профессия начала набирать популярность. В настоящее время она является достаточно престижной и востребованной.
Настоящий тестировщик или тестер должен обладать большим набором знаний и навыков. Без этого просто невозможно осуществлять оптимальный контроль качества программного обеспечения. Такой специалист должен также уметь выполнять несколько разных функций одновременно. С одной стороны, он должен мыслить как разработчик программного продукта, анализируя поведение системы и полученные результаты. С другой стороны, тестировщик должен мыслить и как пользователь этого же продукта.
Если говорить проще, то такой специалист ищет причины неправильной работы компьютера.
Работа эта непростая и серьезная. Требует от человека внимания, усидчивости, терпения. Необходимо отметить, что такая работа требует от человека хорошо развитого умения мыслить логически, отличной памяти, умения быстро обучаться и приспосабливаться к существующим задачам. Очень важно также и уметь работать в команде. Кроме того, тестировщик должен обладать определенным аналитическим складом мышления. Своим трудом эти специалисты заслужили свой праздник День тестировщика.
Основной задачей тестировщика можно назвать обнаружение вероятных проблем и неполадок в функционировании программы. Он занимается также моделированием различных ситуаций, возникновение которых возможно во время использования программы. Это позволяет разработчикам исправить обнаруженные ошибки и устранить все недочеты.
Этот специалист должен также создавать и использовать разнообразные входные данные, которые были и не были предусмотрены создателями программы.
По мнению многих людей, специфика данной профессии заключается в ее монотонности и видимом однообразии трудового процесса. Однако существует мнение об этой профессии как о творческой исследовательской работе, если сравнивать со стандартизированной разработкой.
Одной из главных особенностей данной профессии можно назвать то, что она дает возможность удаленной работы. При этом расстояние может не иметь никакого значения.
Тестировщик может находиться даже в другой стране. Поэтому такая работа часто является промежуточным этапом, который позволяет накопить достаточно знаний и опыта в удалённой разработке ПО.
Может возникнуть вопрос, какое образование необходимо получить будущему тестировщику. Данной профессии не обучают ни в одном из ВУЗов нашей страны. Поэтому тем, кто хочет работать по данной специальности, необходимо закончить факультет, связанный с программированием и разработкой программного обеспечения.
Соискатель должен обладать базовыми навыками программирования, администрирования операционных систем и уметь работать с базами данных. Процесс тестирования подразумевает использование различных подходов и практик, даже требует применения дедукции. При этом важно уметь правильно комбинировать доступные методы тестирования.
Требуются также знания основных технологий построения программного обеспечения. Требования к уровню необходимых навыков и специализации при этом могут различаться в зависимости от поставленных перед тестировщиком задач.
В последнее время этой профессии уделяется все больше внимания. Начало появляться все больше материалов о тестировании и качестве ПО, выпускаются специализированные книги, развиваются сайты, посвящённые этому направлению. Появляются также форумы тестировщиков.
Тестировщики сегодня являются очень востребованными специалистами на рынке труда. Их зарплаты часто даже превышают зарплату программистов.
Нужно сказать, что данная профессия появилась в нашей стране совсем недавно. Самыми первыми тестировщиками принято считать специалистов по качеству, которые занимались проверкой программного обеспечения на соответствие ГОСТам. Однако обязанности современного тестировщика с тех пор существенно расширились.
Мы поздравляем тестировщиков с их праздником, с Днем тестировщика!
Чем занимается инженер по тестированию и как начать работать в этой области
Главные качества тестировщика — внимательность до дотошности, перфекционизм и сильное структурное мышление
Инженер по тестированию контролирует качество IT-продукта. Он находит ошибки, записывает их в отчет и передает разработчикам. На старте нужны минимальные технические навыки, поэтому такая профессия считается одной из точек входа в сферу IT. Фёдор Зволинский, руководитель службы тестирования Яндекс.Браузера, поделился особенностями работы инженера по тестированию и рассказал, какие качества помогут стать экспертом в этой области.
Работа инженера по тестированию, или, как мы говорим, тестировщика, экономит ресурсы компании и команды разработки. Продукт тестируют разными способами на каждом этапе. Чем раньше найдены ошибки, тем проще и дешевле для компании будет их исправить.
Инженер по тестированию хорошо знает продукт, понимает бизнес-процессы и может предложить решение проблемы, исходя из своего опыта. Миссия тестировщика — поддерживать баланс между интересами пользователя, целями менеджмента и возможностями разработчиков. Курс «Инженер по тестированию» Яндекс.Практикума рассчитан именно на это направление.
Задачи тестировщика
Инженер по тестированию отвечает за аудит качества продукта. Есть много направлений проверки. Например, проверка на соответствие функциональным или нагрузочным требованиям. Сохраняется ли история заказов в приложении вызова такси — это проверка функции продукта. Выдержит ли сайт, если 100 покупателей одновременно оформят покупку, — это тест на устойчивость к нагрузке.
Тестировщик проверяет код на соответствие всем требованиям и в процессе находит баги — ошибки, из-за которых продукт работает неправильно. Например, в приложении для поиска отелей не запускается сортировка по цене за ночь. Или сервис выдает ошибку при попытке добавить товар в корзину. Тестировщик проходит весь пользовательский сценарий: совершает покупки, вызывает такси, настраивает личный кабинет и так далее. Если что-то работает неправильно, фиксирует ошибку.
Тестировщик составляет тестовую модель. Он изучает структуру продукта и продумывает порядок проверки всех элементов, функций и состояний. Например, на начальных этапах нужно описать всё, что пользователь видит на разных страницах и экранах: как ведут себя фотографии товаров при наведении, есть ли чат поддержки и как его вызвать. Когда продукт меняется или усложняется, тестировщик вносит изменения в тестовую модель.
Еще одна задача тестировщика — автоматизация. Объем тестирования постоянно растет, а инструменты автоматической проверки для разных направлений тестирования помогают экономить время. Тестировщик постоянно работает над тем, чтобы контроль качества продукта становился еще надежнее и быстрее.
Тестировщик всегда может поставить себя на место клиента. Он понимает, зачем создается продукт и в чём его польза. Если главные функции работают неправильно или ими неудобно пользоваться, он способен объяснить проблему и разработчику, и менеджеру. Технические знания и пользовательский кругозор помогают всё точно сформулировать и в некоторых случаях предложить решение.
Как работает тестировщик
Работа тестировщика делится на этапы. Вначале он собирает всю информацию, изучает и анализирует требования к продукту. Следующий шаг — выбор методов тестирования и создание тестовой модели. Затем он проводит все тесты, а после них пишет отчет, где указывает ошибки, дает ссылки на технические требования и по возможности предлагает решение проблемы. Заключительный этап — проверка исправленного продукта.
Первый этап. Сбор информации
Сначала нужно изучить задачу: какие требования и условия были у нового продукта, как это работает на практике и всех ли в команде устраивает результат. Всё это можно узнать у разработчиков и менеджера продукта.
На этом этапе очень важны навыки общения с командой. Чем лучше тестировщик разберется в задаче, тем проще ему будет создать качественную и полную тестовую модель. Также нужно хорошо понимать, чего от нового сервиса или сайта ждут пользователи. Для этого стоит вникнуть в бизнес-процессы, посмотреть аналитику.
Второй этап. Анализ
Для работы на этом этапе важно понимать техническую документацию, знать требования к продукту. Если тестировщик не ориентируется в терминах и плохо понимает, как устроено приложение или сайт, здесь могут возникнуть проблемы.
Тестировщик разбивает все глобальные процессы в продукте на самые маленькие блоки. Чтобы проверить, как работает приложение, он будет отдельно тестировать каждую страницу, кнопку и действие.
«Если вы тестируете показ всплывающего окна, то такими маленькими блоками могут стать отрисовка всплывающего окна и условия показа. Отдельно проверяем, как окно будет отображаться для пользователя, и оцениваем логику показа без тестирования пользовательского интерфейса. При таком тщательном подходе в тестовой модели будет меньше ошибок, а проверка пройдет быстрее», — говорит Фёдор Зволинский.
Цель этого этапа — понять, что нужно тестировать. Качественный анализ помогает точно оценить время, которое понадобится для проверки.
Третий этап. Разработка тестовых сценариев
Тестовые сценарии описывают действия в системе, условия и ожидаемый результат. Задача инженера по тестированию — выбрать такой сценарий, который лучше всего подходит для проверки продукта.
Тестировщик составляет тест-кейсы — описание всех условий и шагов тестирования. Он ссылается на требования к продукту, указывает нужные настройки для тестовой среды, перечисляет все действия. Для каждого пункта тест-кейса тестировщик описывает результаты: ожидаемый и фактический.
Чтобы получить полный набор тестов без дублирования, специалисты пользуются техниками тест-дизайна. Это стандартные методики проверки для разных сценариев и отдельных функций. Знание основных техник помогает сэкономить время.
«Простой пример: есть функция, которая считает суммарную стоимость купленных билетов в кино. При этом стоимость одного билета известна, а купить можно не более восьми билетов за раз. В таком случае мы можем воспользоваться двумя техниками, которые были придуманы до нас: классами эквивалентности и граничными значениями. Сначала нам нужно проверить, что функция действительно всё правильно считает. Возьмём значение из середины, допустим, 5. Если с результатом всё будет в порядке, следует проверить границы — 1 и 8, а также точки снаружи границ — 0 и 9. Таким образом мы создали всего пять тестов. А если бы мы перебирали все значения от 0 до 9, нам потребовалось бы десять проверок. Экономия времени и усилий в два раза», — объясняет Фёдор Зволинский.
Цель этого этапа — решить, как проводить тесты, выбрать инструменты и методику.
Четвертый этап. Тестирование
Следующий шаг — автоматическое или ручное тестирование. Специалист проходит все этапы, которые описаны в тест-кейсе и проверяет работу продукта. Например, если нужно найти ошибки в верстке, тестировщик использует валидаторы HTML/CSS. Достаточно указать путь к приложению или сайту, и сервис покажет все обнаруженные ошибки.
Проверить продукт на совместимость с браузерами и операционными системами помогают эмуляторы. Это программы, которые воспроизводят возможности разных устройств — ПК, планшета или смартфона — с разными операционными системами. Эмуляторы удобны, когда продукт нужно протестировать одновременно на Android и iOS: не нужно ничего загружать на устройство, все действия выполняются на виртуальном аналоге.
Поиск уязвимостей или перформанс-тесты — для каждого направления тестирования нужен свой инструмент. Существуют специальные программы, которые решают отдельные задачи тестирования автоматически.
Можно управлять организацией тестирования с помощью сервисов. Например, они позволяют создавать тест-кейсы и назначать ответственных за выполнение тестирования. Такие инструменты нужны для того, чтобы привести весь процесс в порядок и не потерять данные предыдущих тестов. Каждая компания выбирает свой подход к тестированию исходя из задач проекта.
Пятый этап. Подготовка отчета
Ошибки нужно описать и показать. Кроме текста тестировщик готовит скриншоты или видео, где можно увидеть ошибку. Всё, что удалось обнаружить, нужно зафиксировать в специальных программах. Для этого используют Bugzilla, Redmine, Mantis, HP ALM. Если процессы в компании еще не настроены, работают с Word и Excel.
Отчет с описанием всех проблем и ошибок тестировщик передает разработчикам и менеджерам. Иногда нужно уточнить, является ли обнаруженный эффект ошибкой или команда изначально заложила его в идею продукта.
Описывать ошибки нужно так, чтобы разработчик или менеджер могли повторить все действия, которые к ней приводят, и увидеть проблему. Подробное описание помогает и на следующем этапе, когда нужно выяснить, действительно ли все ошибки исправлены.
Шестой этап. Проверка исправленного продукта
Нужно свериться с отчетом об ошибках и убедиться, что все проблемы устранены. Если всё работает правильно, тестировщик отмечает, что все обнаруженные ошибки исправлены. Продукт готов к запуску.
Что нужно для старта
Минимальные технические знания помогут тестировщику лучше ориентироваться в задачах и общаться с командой разработки. Пригодится умение читать код, базовые навыки системного администрирования, понимание принципов работы с данными. Еще важно разбираться в особенностях разных операционных систем, браузеров и устройств.
Собеседование с будущим инженером по тестированию обычно строится вокруг понятий тест-дизайна и тест-кейсов. Нужно понимать, для чего пишутся тестовые сценарии, как оценивать эффективность тестирования и какие подходы лучше использовать для разных случаев. Работодатель ждет, что кандидат разбирается в процессе разработки ПО, понимает, какие специалисты за что отвечают и к кому обратиться за информацией, необходимой для тестирования. Преимуществом будет понимание моделей разработки: каскадной, итеративной, спиральной.
В профессии тестировщика очень важны софт-скиллы. Нужно уметь договариваться с другими, аргументировать свою точку зрения и принимать чужую. Главные качества инженера по тестированию — внимательность до дотошности, перфекционизм и сильное структурное мышление. Такой специалист быстро освоит профессию и поможет улучшить продукт.
7 советов, как не взбесить коллегу-тестировщика в его праздник
Сегодня во всем мире отмечается день тестировщика. По этому случаю мы решили помочь вам взглянуть на работу этих специалистов с разных точек зрения, чтобы сотрудничество приносило всем участникам максимум пользы и минимум стресса.
1. «Перепроверь-ка еще разок, там точно нет бага»
Начнем с фундаментальной проблемы. На форуме Ars Technica есть старая ветка, в которой один разработчик рассказывает о глубокой ненависти к «педантичным» тестировщикам. Его ужасно раздражает, что некоторые специалисты по тестированию тратят часы на поиск мельчайших багов. И что самое неприятное, они их всё-таки находят.
Что может пойти не так: Не все готовы признавать свои ошибки. Кто-то заводит старую песню про «не баг, а фича», пытаясь доказать, что всё так и задумывалось. Другие упорно просят перепроверить код и убедиться, что бага нет. Тестировщик же просто старается хорошо делать свою работу, а вместо благодарности его отправляют на перепроверку.
Как быть: Всё просто: если тестировщик нашел недочет в вашем коде и вы понимаете, что он прав, лучше признать этот факт. У вас обоих одна и та же цель — выпустить отлаженный и работающий продукт. Юмор помогает прийти к взаимопониманию в этом вопросе. Вот статья, в которой тестировщики собрали «золотой фонд» высказываний разработчиков, пытающихся защитить свой код. Советуем пробежаться по ним и представить, как эти «классические» фразы звучат с точки зрения тестировщика.
2. «До релиза неделя. Надеюсь, на ближайшие два дня ты не планировал других дел»
Иногда код приходит к тестировщикам за несколько дней до релиза. Тогда им приходится работать в аврале. Некоторые QA-специалисты считают, что коллеги просто недооценивают их труд. Якобы они думают, что поиск багов — это легко и быстро, поэтому откладывают отладку на последний момент.
Что может пойти не так: В условиях авральной работы тестировщики не только раздражаются, но и теряют бдительность. Нехватка времени — одна из главных причин, по которой тестеры пропускают баги.
Как быть: Есть несколько моделей разработки. С точки зрения QA различают два основных подхода: каскадный и Agile. В первом случае тестировщики получают фрагменты кода поэтапно. Во втором случае они тестируют код параллельно с его написанием.
Agile помогает вовлечь QA-специалистов в проект на ранних этапах. Благодаря этому не приходится тестировать «за час до релиза». Кроме того, такой подход позволяет не отыскивать баги, а предотвращать их появление. Если ваши тестировщики жалуются на постоянный цейтнот и пропускают баги, присмотритесь к этой методологии.
3. «Я быстренько подправил код. Посмотри, пожалуйста»
Допустим, ваша команда работает по каскадной модели и умеет грамотно планировать фазы разработки. Тестировщики получают код, и времени на отладку вроде бы хватает. Но у разработчиков есть привычка прилагать на этом этапе минимум усилий. Они получают подробный баг-репорт, поверхностно его читают, быстро устраняют очевидные ошибки и отправляют код на следующий цикл тестов.
Что может пойти не так: Проблема в том, что код после поверхностных изменений зачастую возвращается с еще большим количеством багов. Тестировщик тратил время на составление подробного отчета, а в ответ на него получил какую-то отписку. Ему предстоит пройти этот путь ещё несколько раз только потому, что разработчик не хочет тратить время на «незначительные баги».
Как быть: Очевидно, не стоит торопиться. Но этого мало. Нужно разобраться, почему вы не уделяете должное внимание отчету. Если это банальная лень, помочь себе можете только вы. Бывают и другие причины. Например, вы считаете, что QA-инженеры заваливают вас отчетами о малозначимых багах. Тогда нужно прояснить этот вопрос на уровне руководства — должны ли тестеры отвлекать вас «по мелочам». Скорее всего, ответ будет положительный. Некоторые продакт-менеджеры даже просят разработчиков специально добавлять в код мелкие баги, чтобы тестировщики были всегда настороже. Важно принять этот подход и относиться к баг-репортам с должным вниманием.
4. «Кажется, я уже разобрался с этим багом. Но точно не помню»
Иногда поверхностный подход — это системная проблема. В некоторых командах баг-репорты теряются во времени и пространстве. Никто не реагирует на отчеты должным образом, не помечает, решена ли проблема или всё еще находится в подвешенном состоянии.
Что может пойти не так: Разработчики устраняют какой-то баг, вносят, как им кажется, «незначительные» изменения в код, забывают уведомить об этом тестировщиков и отсылают код на релиз. В итоге проблема всплывает, когда уже слишком поздно. И «крайним» зачастую оказывается тестировщик.
Как быть: Проблему хаоса нужно решать системно. Беспорядок вредит разработке, поэтому придется полностью перестроить процесс коммуникаций в команде. Здесь стоит воспользоваться базовыми советами по налаживанию коммуникации между разработчиками и QA-инженерами: определиться с терминологией; понятно формулировать требования; ввести иерархию приоритетности для различных багов. Что касается путаницы с багами, есть хорошие практические советы: а) пусть баги репортят все; б) далее их важно приоретизировать; в) любой закрытый баг подразумевает, что будет написан функциональный тест; г) статус «решено» присваивает не разработчик, а тестировщик. Этот подход гарантирует, что проблема действительно будет решена.
5. «Почему это я должен тестировать? Я же не тестировщик!»
В некоторых командах ответственность за отладку всецело лежит на тестировщиках. Разработчики не утруждают себя тратой времени на самые очевидные unit-тесты. Они уверены, что это не их работа. По большому счету, так и есть, хотя существуют разные точки зрения на вопрос (с мнениями сообщества можно ознакомиться здесь).
Что может пойти не так: Тестировщикам в такой ситуации приходится разбираться со всеми недочетами подряд — даже с самыми примитивными и глупыми ошибками. Разумеется, это раздражает.
Как быть: Многие разработчики выступают за самостоятельные тесты перед отправкой в QA-отдел. Это помогает не только разгрузить тестировщиков, но и научиться смотреть на продукт с точки зрения критика и пользователя. Есть мнение, что это полезно для профессионалов и лучшим образом сказывается на конечном результате. Для тех, кто не хочет себя утруждать проверками, есть автоматические инструменты. Они помогают найти самые очевидные баги. В любом случае — даже если в команде есть QA-инженеры, жесткое разделение на разработчиков и QA — не самый оптимальный подход.
6. «Игорь, сегодня работаешь в паре с Олегом. Тебе понравится»
Продакт-менеджеры не ограничиваются каскадным подходом и Agile. Некоторые из них любят экспериментировать. Например, устраивать сеансы парного программирования и тестирования.
Что может пойти не так: Это эффективный способ отлавливания багов, но у него есть и минусы — люди могут быть не в восторге от нововведений. QA-специалисту, привыкшему работать в одиночку, на другом этаже и на своем оборудовании, может быть попросту некомфортно покидать привычную среду. К тому же его может банально не устраивать опыт и знания напарника. В итоге вместо результативных тестов продакт-менеджеры получают двух недовольных работников.
Как быть: Главный совет — не рубить с плеча. Agile- и DevOps-практики могут казаться привлекательными, но без должной подготовки не дадут результата.
7. «Я возьму твой девайс для тестов, ты же не против?»
У разработчика появляется время заняться отладкой, он просит у тестировщика девайс для тестов «буквально на 20 минут» и удаляется с ним на долгие часы.
Что может пойти не так: Чаще всего разработчик вообще не возвращает устройство на место, а если и возвращает, то полностью разряженным. Учитывая, что у тестировщиков могут быть параллельные задачи на этом устройстве, такое не может не раздражать.
Как быть: Ставьте себе напоминания, клейте стикеры, делайте что угодно, но, пожалуйста, возвращайте вещи тестировщиков на место и в срок.
И главный совет разработчикам и продакт-менеджерам, который напрашивается сам собой из всех предыдущих: уважайте чужой труд и время, и как можно чаще ставьте себя на место тестировщика. Ведь если бы не он, весь мир знал бы о ваших багах.
