Что нужно знать начинающему тестировщику без опыта?
Мы много пишем про обучение на курсах QA Academy, понимая, что основная цель наших слушателей – это овладение новой профессией и получение хорошей работы.
Многие задаются вопросом, что нужно знать начинающему тестировщику для успешного трудоустройства. Вот о выборе первой работы мы бы и хотели поговорить сегодня. В какие компании отправлять резюме после окончания обучения? Что должен знать тестировщик ПО без опыта? На какие приглашения откликаться, а какие не заслуживают вашего внимания и времени? С этими вопросами мы обратились к HR-специалистам QA Academy и получили в ответ несколько нетривиальных советов. Предлагаем вам с ними ознакомиться.
1. Думайте на перспективу и накапливайте карьерный капитал.
Самые важные карьерные годы для человека – это первые три года работы в компании. И то, насколько результативно вы их проведете, зависит от того, какое место работы вы выберете. Мы рекомендуем остановить свой выбор на компании, где вы сможете накопить как можно больше опыта, отточить редкие навыки, которые позже можно будет обменять на более привлекательную для вас работу.
Иногда опыт важнее заработной платы. Если на начальном этапе вам предлагают зарплату повыше, чем в других местах, но при этом вам предстоит заключить трехлетний контракт и все три года выполнять рутинную работу, – обойдите стороной такого работодателя. Отдайте предпочтение месту, где вы сможете развиваться, расти, решать интересные задачи. Даже если при этом вы немного потеряете в деньгах. Зато через несколько лет, когда вы решите сменить место работы, вам будет что «продать» новому работодателю.
Так что погоня за быстрым результатом не всегда приносит пользу, если посмотреть на ситуацию в перспективе. Выбирайте такую работу, где вы сможете получить опыт и накопить карьерный капитал, который в будущем сможете выгодно конвертировать на рынке труда.
Спешим сообщить всем нашим слушателям, что теперь мы есть на LindkedIn!
Добавьте факт обучения в QA Academy в свое резюме и расскажите потенциальному работодателю, что прошли обучение тестированию ПО в международном образовательном центре.
2. Узнавайте про компанию из первых уст.
Не всегда работодатель рассказывает о себе всю правду на сайте или не рассказывает вовсе. Но это не значит, что данная компания недостойна вашего внимания. Если видите, что в организации открыта подходящая для вас вакансия, попробуйте узнать про нее у действующих сотрудников, которых легко найти в социальных сетях. При этом обращайте внимание не только на проекты, но и на то, какие внерабочие активности проводятся в компании, как отмечаются праздники, какие бонусы предоставляет компания сотрудникам.
Сходите на собеседование и задайте вопросы про текущие проекты компании. Представьте себя на потенциальном рабочем месте. А если предлагаемый проект звучит не очень привлекательно, не отказывайтесь сразу, а расспросите и про него детальнее, узнайте все о перспективах.
Порой возможности лежат рядом, а мы проходим мимо из-за недостатка информации или ложного представления. Не допускайте такой ошибки.
3. Не переставайте развиваться.
Мы очень гордимся тем, что обучение в QA Academy практико-ориентированное. Это значит, что мы даем слушателям все необходимое для быстрого старта карьеры в тестировании. Однако это далеко не всё, что должен знать тестировщик профессионального уровня.
Поэтому при выборе работы также обращайте внимание на то, сможете ли вы получать новые компетенции на работе, совершенствовать английский язык, изучать новые технологии. А если вы поймете, что вам по душе управление командой, сможете ли вы реализовать себя в качестве менеджера? Так что обращайте внимание и на то, сможет ли компания удовлетворить ваши требования к карьерному росту.
Кроме того, не забудьте на первом собеседовании уточнить, будет ли для вас составлена карта роста, которая поможет не сбиться на пути от Junior Tester к специалисту высшего звена и сделает этот путь прозрачным.
Найдя работу, не забудьте прочитать о том, как подготовиться к первому рабочему дню тестировщика.
И напоследок. На работе мы проводим треть жизни. Поэтому очень важно выбрать себе место по душе. И пускай работа будет вам в радость!
Краудтестинг, или Где взять опыт для первой работы в тестировании / Badoo corporate blog / Habr
Изображение: источник
Привет, Хабр! Меня зовут Евгений Кузнецов. Я работаю в Badoo, в отделе QA.
Почти пять лет назад я начал интересоваться тестированием: читал книги, искал информацию в интернете. На одном из форумов наткнулся на тему про подработку, где один из участников оставил ссылку на сайт uTest.com. И это была действительно удачная находка, поскольку uTest оказался крупнейшей платформой для тестировщиков с кучей полезной информации и сотнями оплачиваемых краудсорсинговых проектов.
Я думаю, многие здесь уже слышали об этом сайте или о подобных площадках. Но, как ни странно, часто я вижу удивлённые лица, когда начинаю рассказывать про краудтестирование. Так что цель этой статьи — пустить полезную информацию в массы.
Что такое краудтестинг
Предположим, вы продакт-менеджер и собираетесь выпустить новую версию приложения для Android и iOS. Сроки горят, вам срочно нужны результаты регрессионного тестирования, а единственный тестировщик в вашей команде говорит, что оно займёт два дня, а потом потребуется ещё день для исправления возможных багов. Более того, один из Android-девайсов сломался, и его необходимо заменить, чтобы обеспечить хотя бы базовое платформенное покрытие.
Как можно ускорить процесс тестирования без ущерба качеству продукта? Можно расширить QA-команду и купить больше девайсов; написать кучу автотестов и запускать их в «облаке»; наконец, арендовать несколько девайсов, сесть и тестировать приложение вместе с QA-инженером. Или обратиться к какой-нибудь краудтестинговой платформе. Обычно это сайт, на котором зарегистрированы тысячи тестировщиков. Они готовы тестировать любое веб- или мобильное приложение на собственных гаджетах и ноутбуках.
Вам нужно предоставить ссылку на сборку (например, с помощью HockeyApp или TestFlight), выбрать операционную систему и устройства, на которых вы хотите тестировать свой продукт. Можете даже выбрать страну нахождения тестировщиков. В общем, список пожеланий может быть очень длинным. Затем менеджер платформы разошлёт приглашения — и армия тестировщиков приступит к работе. Через некоторое время вы получите результаты и решите, какие баги нужно фиксить, а с какими можно существовать и после релиза.
Так весь процесс выглядит со стороны заказчика. А теперь давайте посмотрим на него глазами тестировщика.
Что нужно, чтобы начать тестировать
Ничего особенного. Если вы читаете эту статью, значит, у вас есть компьютер, мобильный девайс или что-то ещё. Этого достаточно для регистрации на платформе и участия в проектах. Укажите в профиле модель своего устройства, версию ОС, список браузеров на компьютере и т. д. Будет лучше, если у вас в распоряжении несколько мобильных устройств, например, iOS- и Android-девайсы — вероятность получить инвайты будет выше.
Итак, сначала вам предложат пройти тест, чтобы понять, насколько хорошо вы умеете искать баги и писать репорты. После этого всё просто: вы получаете приглашение, читаете описание проекта и решаете, будете ли в нём участвовать. Время на поиск багов ограничено. После завершения цикла тестирования все репорты просматриваются тимлидом проекта, а затем заказчиком. Отправленные вами баги либо принимаются, либо отклоняются.
Баг принят ⇒ получаете деньги.
Баг отклонён ⇒ получаете опыт, так как в комментарии к репорту будет объяснена причина отклонения.
Зачем краудтестинг начинающему тестировщику
Опыт
Я начал работать на краудтестинговых площадках до того, как нашёл первую работу. У меня были неплохие знания теории тестирования, но не было практического опыта (без которого многие рекрутеры даже не хотят начинать разговор). Работая на краудсорсинговых платформах, вы получите отличный практический опыт тестирования программного обеспечения. Разнообразие софта будет зависеть от имеющихся у вас гаджетов. У меня были iPhone и ноутбук (на Windows 7) с установленной виртуальной машиной (на которой крутились XP и Vista). Чуть позже я купил Android-девайс и iPad.
За первые два месяца я поучаствовал примерно в 20 проектах, которые длились от нескольких часов до нескольких дней. E-commerce-приложения и сайты, игры, соцсети, мессенджеры… Если будете активно участвовать и находить много багов, то ваш рейтинг будет расти, а значит, вы станете получать больше приглашений.
Протестировав кучу ПО, несложно понять, что баги обычно «прячутся» в одних и тех же местах. Помимо проверки основных позитивных и негативных сценариев, экспериментируйте с настройками девайсов, с сетью, используйте авиарежим, ведь часто разработчики забывают правильно обрабатывать поведение ПО при отсутствии связи.
Помню, как я волновался, когда репортил свой первый баг: старался описать всё очень подробно, приложил несколько скриншотов и видео, так как каждый отклонённый баг может повлиять на статистику. Кстати, очень важно просматривать репорты других участников. Не только во время тестирования (чтобы избежать дублирования), но особенно после него, когда их проверят тимлид и заказчик. Ознакомление с чужими отклонёнными багами даст вам более полное представление об ожиданиях менеджеров и заказчиков.
В итоге в вашем портфолио появится много интересных проектов и забавных баг-историй, которые можно будет использовать на собеседованиях.
Чем более вы продуктивны в тест-циклах, тем больше приглашений на них у вас будет.
Новые скилы
Очевидно, что при тестировании большого количества ПО вы будете осваивать новые навыки: как снять краш-логи с Android-/ iOS-девайса и прочитать их, как использовать ADB Console и monkey-тестинг, как правильно использовать все настройки девайса (включение ограничения приложений на доступ к камере/ геолокации, «универсального доступа», режима зумирования), как использовать браузерные инструменты для разработчиков и многие другие. И вам придётся всё это узнать, чтобы найти больше багов, так как каждый проект — это мини-соревнование между тестировщиками.
Вы научитесь работать с новыми инструментами. Например, одним из моих проектов была проверка ивентов Google Analytics, в тот день я открыл для себя Charles Proxy. Немного позже я начал использовать все его возможности (throttling, rewriting, mapping). Ещё, помню, у меня был проект по тестированию безопасности, и я нашёл прекрасный инструмент Zed Attack Proxy.
Кстати, если хотите прокачать свои навыки, рекомендую статью «Тестирование мобильных приложений: tips & tricks».
Любопытство — самый ценный навык тестировщика.
Сообщество
Общение — один из самых важных навыков для тестировщика. Это ключ ко всему. Что бы вы ни хотели узнать, найти или получить, нужно общаться. Каждый новый человек может дать вам какие-то новые возможности. На краудтестинговых платформах вы встретите много интересных людей, которые будут с вами «на одной волне». На форумах есть сотни тем, в которых можно задавать любые вопросы. Это особенно важно, когда вы начинаете свой путь в тестировании, поскольку можно научиться и получить совет у более опытных людей.
Будьте активны, задавайте вопросы в чате тест-цикла. Если вам кажется, что в описании что-то упущено, обязательно скажите об этом. Помогайте другим участникам, если знаете ответы на их вопросы. Тимлид или заказчик это заметят — и позже вы сможете получать приглашения в проекты «для избранных».
Общение — ключ к возможностям.
Языковая практика
Все мы знаем, что знание английского языка заметно повышает конкурентоспособность. Поэтому вы просто обязаны зарегистрироваться на зарубежной площадке. Ваш уровень вырастет на порядок всего лишь за несколько недель, поскольку вся документация и общение будут на английском языке, и, конечно, баг-репорты тоже должны быть на нём. Сначала будет не очень привычно, но пополнение словарного запаса определённо того стоит.
Не бойтесь ошибаться: для 90% участников английский — тоже не родной язык.
Деньги
Последний аргумент — деньги. Работу на краудтестинговых платформах можно рассматривать как оплачиваемую стажировку. Ведь вы получаете и опыт, и доход. Размер оплаты будет зависеть от критичности и количества найденных багов. На большинстве платформ он колеблется в диапазоне 3—15 у. е. (в зависимости от проекта, могут отстегнуть и 50 у. е.) за баг.
Сначала я зарабатывал около 400 евро в месяц, работая по паре часов в день. Потом я решил сосредоточиться не на количестве, а на качестве баг-репортов. Начал проводить больше времени на платформе — и в результате стал зарабатывать около 700—800 евро в месяц. Мой рейтинг ощутимо вырос — и вскоре я получил от менеджера проекта приглашение в небольшую команду на закрытый цикл тестирования одного продукта. После около 12 часов работы каждый из нас получил больше тысячи евро.
Старайтесь сосредоточиться на поиске критичных багов и повышении качества репортов, а не на их количестве. Тогда работа будет более интересной и в конечном счёте вы больше заработаете.
Платформы, на которых я работал
Крупнейшее онлайн-сообщество тестировщиков ПО. Помимо оплачиваемых проектов по тестированию, здесь есть масса полезной информации, статьи и хороший форум. Возможно, это лучшее место для начала работы. К сожалению, у меня с ним, что называется, не сложилось. Четыре года назад на платформе было очень мало проектов для тестировщиков из России (сейчас с этим, насколько я знаю, получше). В то время клиенты были в основном из Европы и США, и они хотели тестировать продукты на своих потенциальных рынках. Россия, разумеется, к ним не относилась. Конечно, можно было прибегнуть к хитрости: использовать VPN и написать в профиле, что ты тестировщик из Англии или США. Так я, собственно, и сделал, чтобы получить свой первый проект. Но для меня такой способ оказался не очень удобным, так что я начал искать другие платформы.
Раньше платформа называлась Testcloud, и она стала моей любимой краудтестинговой площадкой.
Удобный интерфейс, налаженное взаимодействие с тимлидами и заказчиками, хорошая система рейтинга тестировщиков и прекрасные рейты за найденные баги (вывод денег — через PayPal). На этой платформе у меня было множество разных и интересных проектов. В течение нескольких месяцев я был единственным русскоязычным тестировщиком, поэтому мне доставались все проекты с RU-локализацией.
Через год я решил стать тимлидом на этой платформе. Тимлид на краудтестинговой площадке — это тот же фрилансер, получающий приглашения в проекты; только он не тестирует продукты, а проверяет баг-репорты и контролирует весь цикл тестирования. Но, к сожалению, в тот момент я был очень занят на новом месте работы — и из-за нехватки времени мне пришлось уйти с площадки. А вообще у ребят замечательная команда, и я рад видеть, что платформа растёт. Очень рекомендую!
Отличная платформа с разными проектами. Несколько раз мне даже присылали гаджеты для тестирования, и некоторыми я пользуюсь до сих пор. Кстати, пару лет назад появился и русскоязычный вариант — crowdtesting.ru.
Участвовал в нескольких циклах тестирования.
В некоторых проектах требуется знание немецкого языка.
Индийская платформа. До сих пор получаю с неё приглашения на проекты.
И ещё несколько ресурсов
Если верить информации на сайте, платформа сотрудничает с Facebook, Spotify и Microsoft. Так что, если у вас есть желание зарепортить какие-то раздражающие баги FB (у меня, пожалуй, наберётся пара десятков), это место для вас.
Хочу заметить, что этот проект является организатором тестатонов (хакатонов для тестировщиков), один из которых проходил в Москве.
Не имеет ничего общего с известной компанией. Но, кто знает, возможно, у вас в руках окажется и предрелизная версия приложения Uber.
Ещё одна крупная платформа. Интересная особенность: платят не за найденные баги, а за время, потраченное на тестирование. А ещё там есть прикольный блог, где вы можете почитать истории тестировщиков с этой площадки.
Заключение
Я без проблем нашёл первое место работы во многом благодаря опыту в краудтестинге. Было огромное количество писем и звонков, которые превратились в четыре оффера из пяти интервью. В моей следующей компании все очень заинтересовались тестированием на краудтестинговых площадках, и я даже выступил в роли заказчика на одной из них. И сейчас, работая в лондонском офисе Badoo, я использую многие навыки, которые получил в то время.
Работа на краудсорсинговых платформах — хорошая возможность начать QA-карьеру. Вы получите опыт, научитесь пользоваться новыми инструментами, познакомитесь с интересными людьми, заработаете неплохие деньги, и главное — получите удовольствие от тестирования.
Тестировщики не ломают софт — они ломают ваши мечты о нём…(с) James Bach
P. S. В этой статье я по большей части описывал положительные стороны краудтестинга для тех, кто только собирается заняться тестированием. Но, конечно, на подобных площадках есть работа и для опытных тестировщиков: проекты, требующие глубоких знаний автоматизации, безопасности, UX и т. д.
P. P. S. Кстати, в Badoo мы тоже используем краудтестинг для поиска секьюрити-багов. Так что, если вы эксперт в области IT-безопасности и хотите заработать (до £2000 за уязвимость!), то добро пожаловать в нашу bounty-программу на сайте hackerone.com.
Семь правил тестировщика / Habr
«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»Е. Херригель
«Дзен и искусство стрельбы из лука»
Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?
Тогда прошу под кат!
Свою карьеру тестировщика я начал в одной небольшой фирме, занимающейся тестированием самолетного ПО. Там было только автоматизированное тестирование, все процессы были уже построены, в общем — не сильно сложная работа. Мне показали основы написания кода на Visual Basic, показали как запускать тесты, и отправили в дальнее плавание.
Затем моё студенчество закончилось, захотелось больше интересной работы, и я перешел в другую компанию на должность простого ручного тестировщика. Тут нужно сделать небольшое отступление — в небольших кампаниях/отделах тестировщик порой выполняет целую кучу задач, не связанных напрямую с тестированием. Например, развертывание тестовой среды, ведение нескольких веток продукта в сорс контроле, саппорт выпущенных продуктов и т.д. Я попал именно в такую ситуацию.
Поначалу все было хорошо — мы делали свой 1 проект, я все делал руками, и у меня еще оставалась куча свободного времени.
Но постепенно проектов становилось все больше, программисты постоянно фиксили баги, нужно было накатывать билды чуть ли не каждый час. В какой-то момент я заметил, что на собственно тестирование я трачу лишь 40% времени. Остальное время занимают какие-то левые активности. Тогда я понял первое простое правило:
1. Если ты тестировщик, то можно и нужно автоматизировать не только тестирование
Именно тогда я сделал простую табличку в Excel, и отметил все задачи, на которые тратилось время. И нашел то, что выжирало больше всего времени — банальная выкладка билдов (обновление файлов, екзешников и т.д.). Вечером дома я зарылся в яндекс, и нашел, как убрать эту активность в 0. Я посмотрел синтаксис билдов на нашем билд-сервере, и сделал автоматическую выкладку всего этого хозяйства. После этого я привязал запуск билда к check-in’у в сорс контроле, и обрадовался жизни — у меня опять появилось свободное время! Тогда же я понял второе простое правило:
2. Автоматизируй то, что даст наибольший выигрыш по времени
Постепенно проекты росли, и появились системы, расположенные на нескольких серверах. И, о ужас, — конфиги разработчиков не работали на серверах! А программисты почему-то(!) не хотели их править. Я опять полез ковыряться в билд-машине, и обнаружил, что конфиги можно легко менять на этапе сборки. Тогда я понял третье простое правило:
3. Полностью изучи работу билд-машины
Примерно тогда же в моем распоряжении появилась первая виртуальная ферма на Hyper-V. Через пару месяцев я уже не представлял себе, как жил до этого. Настолько легко и просто оказалось поднимать тестовые стенды! Отсюда четвертое простое правило:
4. Подними сервер виртуализации
В то время компания очень сильно выросла, и внезапно оказалось, что для простого заведения учетки в домене нужно писать заявку админам с обоснованием и подтверждениями. Какое-то время мы терпели, а потом я сделал свой тестовый домен. Через месяц я понял, что не только сервер виртуализации был необходим. Отсюда пятое простое правило:
5. Сделай, наконец, свой тестовый домен
Когда я поднимал тестовый домен, то обнаружил на сервере забавную вещь — Power Shell. Как оказалось, кучу вещей можно сделать без интерфейса — заводить пользователей, настраивать IIS, делать правила в файрволе, устанавливать сервисы и т.д. Кроме того я узнал, что это можно делать не только на своей машине!
И если какую-то задачу на удаленной машине нужно будет сделать больше трёх раз, я всегда пишу скрипт — экономия времени огромна.
В общем, шестое простое правило:
6. Разберись с PowerShell/cmd/bash
В какой-то момент я осознал, что даже не приступив к автоматизации тестирования, я автоматизировал все остальное!
Тогда я взялся делать свой первый огромный(как мне тогда казалось) проект по автоматизированному тестированию одной огромной монструозной бизнес-функции. Делал я его долго, мучительно, но все-таки сотворил. Вот только там было столько костылей, неявных зависимостей, хардкода и прочего добра, что как-либо поддерживать это создание воспаленного ума оказалось невозможным. Именно тогда я понял, почему эти умные программисты допускают столько косяков… Но это была не последняя монструозная система в моем исполнении — их было еще много. В общем, самое главное седьмое правило:
7. Хочешь автоматизировать? Учись правильно программировать! Прочитай книги по архитектуре программ
Именно тут проявила себя цитата, вынесенная в эпиграф. Только сделав несколько ужасных проектов, обломав кучу зубов на поддержке своих творений, я начал понимать то, что написали эти умные дядьки в своих книгах. Только тотальная нехватка времени и тупизна работы по копированию файликов из одного место в другое толкнули меня на путь автоматизации. Только полностью влившись в команду разработки я начал писать относительно нормальный код.
А потом я втянулся. И следующие несколько книжек в плане на прочтение — о программировании. Причем я не буду переходить в программисты, это не моё. Ну а программирующим тестировщиком я уже стал.
И главное, не нужно бояться автоматизации. Это не всегда огромные труды, которые могут принести мифическую прибыль в будущем. Посмотри вокруг! Что-то можно сделать мышкой? С вероятностью в 95% это можно заскриптовать. Ты выполняешь ручные операции уже в пятнадцатый раз? Значит заскриптовать их нужно было еще вчера.
И еще одно пожелание. Научился сам, просвети своих коллег — согласитесь, интереснее работать с людьми, которые делают красивые, сложные проекты, а не ходят в грязном свитере и страдают от своей работы.
Желаю интересных багов, хороших проектов и дружных коллег-программистов!
Что нужно знать начинающему тестировщику? 18+ cоветов от Webmart QA
Мы провели опыты на своих тест-менеджерах и лишили их печенек аж на три дня! Звучит ужасно, но такие суровые меры были необходимы для получения качественной информации 😉
А как же иначе? Ведь мы решили дать «пару» советов начинающим (и не очень) тестировщикам, и обычного серфинга по тематическим форумам вкупе с хождением по встречам и конференциям было недостаточно для дельной статьи.
Наши советы основываются на опыте, так что бывалый специалист и сам уже должен был прийти к этим фишкам. Но почему бы не узнать больше прямо сейчас вместо того, чтобы учиться на собственных ошибках потом? Итак, вот одни из лучших хитростей тестирования ПО, которые мы собрали:
1. Продумывайте тестовое покрытие
Хоть 100% и недостижимая высота, вы всегда должны стараться охватить продукт наиболее полно. Поэтому разрабатывать тестовое покрытие нужно с умом, комбинируя разные техники тест-дизайна. При этом важно координировать свои действия с требованиями менеджера, чтобы не изучать одну фичу глубоко и долго, когда на самом деле от тебя хотят полного тестирования ПО. Так можно и дедлайны запороть.
2. Дефрагментируйте тестируемое ПО
Чтобы обеспечить максимальный охват продукта тестами, разделите его на более мелкие функциональные модули. Напишите тест-кейсы для этих отдельных блоков. А если возможно, то разделите функциональные модули на ещё более мелкие части. К примеру:
Давайте представим, что вы разделили свой веб-сайт на отдельные составляющие, и “заполнение пользовательских данных” стало одним из модулей. Вы можете разобрать этот раздел о “данных пользователя” на меньшие части для написания тест-кейсов: тестирование интерфейса, безопасности, функциональное тестирование формы регистрации и т.д. Проведите все тесты типов и размеров поля формы, позитивные и негативные тесты для полей ввода и напишите все подобные тест-кейсы для максимального покрытия.
Помимо этого,
Некоторые тестеры во время работы представляют дерево. Березу там, или клен.
Задача – пройти по каждой ветке. Зайдя в конец первой ветки, тестер возвращается к стволу и переходит к следующему ветвлению. С помощью этого метода визуализации, он обходит все уровни и обеспечивает полное тестовое покрытие дерева.
3. Будьте последовательны
Основная мысль, которую с детства закладывают в умы будущих тестировщиков – начинай с позитивных сценариев, в первую очередь проверь основные действия юзера. Что происходит, если отойти от этого скрипта? К примеру, джуниор тестирует процесс заказа товара.
На эту задачу отведено 8 часов. 6 часов спустя, джуниор в ударе: он проверил валидационные сообщения, увидел ошибку 404 и положил базу, закинув в поле имени 5999 символов. Пошел 7 час, и тут оказывается, что на третьем шаге заполнения данных падает исключение при нажатии кнопки Оплатить. Блокирование основного сценария на седьмом часу теста, Карл! А должен был быть внесен в систему отслеживания ошибок уже в первые 10 минут работы.
4. Тестируйте с охотой!
Начиная тестирование ПО, включите свои охотничьи инстинкты и настройтесь на поиски ошибок. Незачем думать, что в продукте не будет багов. Если вы будете достаточно дотошным, вы сможете найти даже самые незаметные проблемы!
5. Но без фанатизма
Когда вам в руки попадает уже качественное, «вылизанное» ПО с микроскопическими багами, которые конечный пользователь никогда не найдет, поубавьте пыл. Даже если под проверку такого билда выделено время, те же 8 часов, то не тратьте их на попиксельное тестирование админки. Проекты делаются для определенного конечного пользователя и решения чьих-то задач и проблем. Подумайте, что им действительно нужно.
6. Поделитесь тест-кейсами до разработки
Не прячьте свои кейсы от программистов до самого получения билда с мыслью о том, что так вы сможете обнаружить больше багов. Если кодеры проанализируют ваши записи до начала разработки, то продукт получится более качественным. Кроме того, вы сэкономите время на повторную работу и исправление багов.
Да и вообще, не бойтесь общаться с прогерами побольше (в меру конечно, не надо садиться рядом и целый день смотреть в монитор программиста, чтобы вас потом изгоняли общими усилиями разработчиков, админа и бубна).
7. Определите свои тест-кейсы для регрессионного тестирования
И сгруппируйте их заранее. Так вы значительно упростите и ускорите себе повторное ручное тестирование.
8. Не забывайте о производительности
В продуктах, требующих критического времени отклика, нужно тщательно анализировать производительность. И так как у каждого тестировщика есть отдельная область задач, важно стараться видеть картину в целом. Обращайте внимание не только на свою часть работы (функциональность, gui, совместимость, например), но и привлекайте внимание менеджера проекта к проблемам в производительности, в безопасности, да в целом, в процессе работы. Тогда менеджер сможет сразу среагировать и подключить нужных специалистов к проекту.
9. Не давайте разработчикам тестировать их собственный код
И в целом не стесняйтесь не доверять разработчикам. Программисты могут качественно проводить автономное тестирование основных модулей разрабатываемого продукта. Но в большинстве случае кодер пропустит часть багов, потому что сам писал ПО и думает, что оно и так идеально работает.
Поэтому вот этот функционал он пропустит, про это поле забудет, и вот эта кнопочка им была написана, значит, с ней всё ок. Задача же тестировщика – проверить все возможные и невозможные состояния и комбинации действий, в которых софт работать не будет.
10. Выйдите за рамки требований
Иногда требования не отражают всей полноты функционала продукта, особенно, если она гибко разрабатывается под меняющиеся условия. Так что как бы не было детализировано техническое задание, оно не всеобъемлюще. И отмазкой «этого не было в ТЗ» вы вряд ли кого-либо порадуете – все и так знают, что нет смысла бронировать билеты на дату в прошлом. Поэтому тестируйте продукт не только строго следуя документации, но и опираясь на свои собственный здравый смысл, ощущения, идеи, пользовательский опыт, опыт коллег и эталонное ПО на рынке.
11. Оглядывайтесь назад
Во время выполнения регрессионного тестирования вам пригодится ранее заполненная документация, содержащая распределение дефектов по функциональным модулям во времени. Так вам будет проще спрогнозировать наиболее вероятные баги и проблемные места в ПО.
12. Ведите конспекты
Записывайте новые термины, понятия, свои наблюдения и ход тестирования. Вы можете пользоваться специальным приложением или софтом, а можете просто открывать любой текстовый редактор. Эти выкладки и записи очень помогут вам при написании отчетов о результатах тестирования и будут полезны для усвоения новой информации.
13. Записывайте тестовые изменения кода
Тестеры или программисты вносят множество изменений в кодовую базу тестируемого продукта. Это необходимый этап разработки или тестирования, предохраняющий от живой обработки транзакций, как, к примеру, в банковских проектах. Запишите все изменения кода, сделанные в целях тестирования, и к моменту конечного релиза убедитесь, что вы удалили все эти изменения из финальных файловых ресурсов внедрения на стороне клиента.
14. Делайте засечки
Мы уже говорили про запись хода тестирования. При тестировании одного из модулей, вы сосредотачиваетесь на нем и не планируете отрываться. Но по ходу дела всегда выскакивают какие-то баги в смежной функциональности. И чтобы резко на них не переключаться, удобно делать своего рода засечки, понятные вам, на бумажке, в текстовом редакторе или где-то еще. А когда вы приступите к тестированию смежного модуля, то скажете себе большое спасибо за уже помеченные 30-40% багов.
15. Обменивайтесь опытом
Важно наладить общение, чтобы новые знания, методики и практики циркулировали внутри команды и за её пределами.
16. Настройте обратную связь с программистами
Тестерам нужно знать о продукте как можно больше, поэтому мы стараемся регулярно организовывать кросс-функциональные митинги. Это позволяет быстро решить возникающие противоречия и избежать недопонимания. При этом и письменное подтверждение важно – это не даёт обсуждению превратиться в сломанный телефон. После каждого митинга не помешает подводить итоги с помощью электронных писем или краткого списка в общем чате.
17. Планируйте свое время
Расставляйте правильные приоритеты. Последовательно переходите от наиболее важных задач к задачам низкого приоритета. Не забывайте давать глазам отдых, подумайте о разбиении своего рабочего времени на равные модули по 20-30 минут. Так вам проще будет контролировать свои пики активности и использовать их на полную мощность, при этом вы не будете перенапрягаться.
18. Учитесь писать отчеты
Писать отчеты, как и хорошие тест-кейсы, надо уметь. Старайтесь тщательно и понятно описывать баги, предоставляйте не только симптомы ошибок, но и производимые ими эффекты, а также все возможные пути их устранения.
Не забывайте: тестирование – это творческая и амбициозная задача. То, как вы справитесь с этим вызовом, зависит от ваших навыков, опыта и мышления.
P.S. Мы добавили возможность комментирования, поэтому будем очень рады, если вы поделитесь своими ежедневными тест-хаками!
Инструменты тестировщика / JUG Ru Group corporate blog / Habr
Какие инструменты нужны тестировщику? Об этом мы сегодня порассуждаем в этой статье, в основе которой — доклад Юлии Атлыгиной с прошлого Heisenbug. Видеозапись доклада доступна по ссылке.Мозг — самый важный инструмент, наверное, для любой профессии, не только для тестировщика. Глаза тоже пригодятся, особенно, если вы тестируете UI. Конечно же уши: иногда вы запускаете приложение, и ваш компьютер начинает жужжать, как самолет на взлетной полосе. Нос, ведь иногда от приложений «попахивает». Нужны и ноги: иногда у вас что-то случается, возникают какие-то вопросы, приходится к кому-то бежать, что-то спрашивать, с кем-то общаться. Руки тоже пригождаются, особенно ручным тестировщикам, далеко не всё можно автоматизировать(да и автотесты мы пишем руками). И, конечно же, сердце, ведь тестирование должно быть вашей страстью!
На этом, в принципе, можно было бы уже и закончить статью, все самые важные инструменты уже перечислены. Но шутки в сторону, поговорим об инструментах, которые нам помогут быть более эффективными, вне зависимости от вашей должности, ручной ли вы тестировщик или автоматизатор, аналитик или программист.
У каждого тестировщика есть свои любимые инструменты для скриншотов. Когда в вашем приложении случаются какие-то проблемы на UI (если, конечно, UI вообще есть, а даже если нет — может понадобится сделать скриншот и ответов консоли, и результатов запросов к базе), вам нужно сделать скриншот, и эти скриншоты надо делать правильно.
Мой личный фаворит — Jing, выглядит, как такое прекрасное, позитивное солнышко на вашем экране. Чем хорош: умеет делать скриншоты, умеет эти скрины сохранять как локально, так и в свое облако, умеет записывать видео. Оно, к сожалению, записывается только во Flash, и вот здесь возникла проблема: у нас в компании большая часть разработчиков работает на Mac, и мои флешевые видео там непросто открыть. Пришлось искать другой инструмент и распрощаться со своим любимым позитивным солнышком. Сейчас я больше всего пользуюсь инструментом Recordit, он позволяет сразу записывать видео и превращать его в gif одним движением, но с ним тоже есть маленькая непонятка: всё, что он записал, он сразу выкладывает к себе в облако, т.е. если у вас что-то локальное или вы не хотите ни с кем делиться тем, как выглядит ваше приложение, придется поискать что-то еще. Например, Monosnap тоже умеет делать видео, умеет сразу сохранять его локально и делать из видео gif.
Actual Result: Doesn’t work
Expected Result: Works as Expected
Когда-то давно, когда я была маленьким юным тестировщиком, нашла прекрасную последовательность шагов, которая привела меня к ошибке 500 на странице. \
Я, конечно, записала баг репорт с шагами воспроизведения и актуальным результатом, а ожидаемый решила не писать — и так понятно, что ожидаем отсутствие ошибки. После исправления я попробовала перетестировать те же шаги, и знаете, что увидела? Просто белую страницу. Не поспоришь, ошибки 500 нет.
После этого я сделала для себя два вывода:
- не верьте разработчикам;
- expected результат — очень важная часть вашего баг репорта.
Как можно себе помочь?
Есть инструменты, которые помогают вам делать прототипы, т.е. рисовать ваше приложение, каким бы вы его ожидали увидеть. Мне больше всего нравится Balsamiq — это такой инструмент, который позволяет вам за пару кликов сложить интерфейс визуально. У него сразу есть контейнеры, элементы, из которых вы можете нарисовать веб-страничку, мобильное приложение или что угодно, буквально перетаскивая «картинки». Есть аналог — браузерный плагин Pencil, он не такой классный, но зато бесплатный.
На одном из проектов мы практиковали QDD, «QA driven development». Наши тестировщики сами писали acceptance-критерии для задач, т.е. это делал не какой-то product owner или менеджер, а именно QA-команда, а уже после задачки подтверждались product owner’ом. Для оформления задач в том числе использовали Balsamiq, чтобы показать, как всё будет выглядеть, где какие кнопки должны быть, и отдать это всё разработчику. Проходит какое-то время, к нам приходит новый билд, и, о ужас, страничка (кроме браузерной части) выглядит вот так:
Наш разработчик действительно подобрал стили, кнопочки, и его даже не смутило, что эта верхняя часть, где адресная строка, тоже выглядит не так, как браузер. Мораль: когда вы показываете прототипы своим разработчикам, классно бы с ними проговорить, что это просто прототип, не надо делать ровно так же. Это нормально, что в конкретном случае будут другие стили, и выглядеть всё будет немного по-другому, мокап нужен только чтобы определить, где что находится и как примерно должно выглядеть.
Признавайтесь, у вас есть текстовые файлики с любимыми тестовыми данными? Долой файлики с текстами! Есть специальные инструменты, которые умеют эти тексты генерировать:
С их помощью вы можете избавиться от эффекта пестицида, когда баги привыкают к вашим тестам, и тесты эти баги больше не находят. Среди этих приложений есть Mockaroo — позволяет вам не просто подобрать какие-то данные, например, номера карточек или user name. Он умеет также генерировать SQL-запросы, например, вы указываете имя базы, в которую вы хотите пойти, а также какие там параметры, и он создает из этого insert. И обращаю еще ваше внимание из всего этого списка на последний плагин, bugmagnet. Это плагин к Chrome и Firefox с заранее сохраненным набором тестовых данных. Когда у вас есть какое-то текстовое поле на экране, вы просто кликаете на него правой кнопкой мышки и в меню выбираете bugmagnet, внутри вас уже ждет куча всяких предустановленных, предзаданных тестовых данных, разбитых по группам: по длине, по формату, по языку, даже самые простые скрипты для тестирования XSS. Незаменимый продукт для exploratory-тестированием. Даже если у вас есть поле с e-mail, и вы забыли, какой e-mail валидный, а какой — нет, Gojko Adzic, автор этого инструмента уже всё сделал за вас, вам необходимо просто найти нужный элемент в этом списке. Что важно — он еще и кастомизируется, т.е. вы можете добавить свои разделы в меню.
Иногда бывает, что вам и не тексты совсем нужны, а картинки. Можно погуглить, поискать что-нибудь, потом попытаться отобрать, что из этого — правильного размера. А есть специальный сервис, LoremPixel, который позволяет вам эти картинки генерировать: вы можете задать размер картинки, цвет и даже тематику: котик, город, еда, транспорт и т.д. Последнее время он часто болеет, но есть не менее интресный аналог — picsum.photos
А есть у кого-то приложение с большими формочками и кучей разных данных? Я понимаю вашу боль. Бывает, что в вашей формочке много полей, часть из которых довольно специфична: куда-то нужно вводить только e-mail, куда-то только телефон или еще что-то, и каждый раз это всё вводить утомительно. Есть плагин для Chrome, называется Form Filler, который может помочь решить проблему: у вас добавится маленькая кнопочка рядом с адресной строкой, по клику на которую ваша формочка магически превращается в заполненную форму:
Заметьте: в поле e-mail действительно введены данные в формате e-mail, а там, где телефон, введен формат телефона, в выпадающих меню выбирается одно из данных списка, что сохраняет очень много времени. Обращаю ваше внимание, что в этом плагине также всё можно донастраивать, т.е. добавлять свои собственные маски, свои данные.
Кто-нибудь использует технику попарного перебора? Не могу сказать, что использую ее каждый день, но, тем не менее, иногда пригождается. Зачем она нужна? Когда у вас есть много параметров, например, та же огромная формочка, согласно статистике, от 65 до 97% ошибок находится при попарном переборе (как видите, тут статистика сильно расплывается в числах), т.е. мы можем сэкономить много времени и почти не потерять в покрытии, если будем перебирать пары значений.
Я пользуюсь онлайн-инструментом Pairwiser (к сожалению, онлайн-версия больше недоступна, но осталась локальная версия):
Есть много других инструментов, но большая часть из них — консольные, не такие наглядные, поэтому я использую Pairwiser. В нашей компании (мы занимаемся плагинами для Jira) тестировщикам приходится постоянно сочетать браузеры, разные версии Jira и Confluence, разные базы данных (зависят от версии Jira), версии других плагинов. Я завожу параметры в Pairwiser,
нажимаю «generate test» и получаю список тестов, таблицу, в которой видно, что и с чем нужно протестировать, какие инстансы нужно создать. Какая магия произошла: если бы я перебирала все значения друг с другом (см. картинку), я бы получила 60 тестов. С помощью Pairwiser я сократила это число до 21, в три раза.
Вот пример, который сделали создатели самого инструмента:
Бывает, что у вас параметров гораздо больше. У меня в примере их было всего три, здесь их гораздо больше: операционные системы, виды connection, какие-то условия между вашими параметрами (например, глупо тестировать мобильный браузер с десктопом), какие-то дополнительные параметры, можно отметить тесты как обязательные (что-то типа sanity, когда вы говорите, что мне точно нужно протестировать это сочетание параметров). И происходит магия, 32 теста вместо 18688:
Просто вдумайтесь, 32 вместо почти 19000! Можно сэкономить кучу времени.
UPD: пока нашла для себя другой бесплатный веб-инструмент, pairwise.teremokgames.com.
Немного поговорим про специфику веб. Есть сообщество World Wide Web Consortium, ребята занимаются стандартизацией HTML и CSS. Они создали валидаторы, т.е. статические анализаторы, куда вы задаете URL своего приложения и он вам выдает набор ошибок. Есть такие же штуки, которые проверяют, насколько вы совместимы с мобильными, или же проверяют линки. У этих валидаторов можно задать какой-то URL, можно прямо загрузить файл с вашим HTML. Есть плагины для браузеров, по крайней мере для Chrome точно, которые могут это делать локально.
Ответы будут выглядеть следующим образом:
Хочу вас сразу уберечь. Много из того, что вам скажет этот валидатор, править не нужно, может быть, он ничего страшного и не найдет, но очень важно про эти вещи хотя бы подумать, взять и перебрать, есть там что-то полезное или нет. Посмотрите первый пример — у тега img нет alt-атрибута. Alt — это параметр, который говорит, какой текст будет писаться, если у вас, например, отключены картинки, или картинка не загрузилась, скажем, из-за медленного интернета. Казалось бы, в нашем веке у всех интернет более-менее, в чем проблема? Ну не указано, и что? Вот здесь маленький нюанс: есть, например, люди с проблемами со зрением, которые используют специальные скринридеры. Если скринридер читает по экрану, как думаете, что он видит вместо картинки? Этот alt-текст. И если этот текст не задан, то человек никогда не узнает, что там вообще что-то было.
Вообще, никто не безгрешен. Если вбить в этот прекрасный валидатор Google.com, то он выдаст 21 ошибку, большая часть из них про устаревшие элементы. Даже у Google есть ошибки! С другой стороны, вы не Google, так что это должно вас как-то подбивать делать свои продукты лучше. Наверное, и ресурсов у вас не столько, а такой валидатор даст вам бо́льшую уверенность в том, что в разных браузерах страницы будут работать, поскольку вы совместимы напрямую со стандартом.
Обычно, когда спрашиваешь о перформанс-тестах, получаешь в ответ что-то вроде: «Перформанс — дело серьезно, этим должны заниматься специальные люди». И это правда, это огромная область, но хотя бы несколько поверхностных тестов можно провести очень легко. Есть несколько инструментов, которые на вашем сайте могут показать, какие есть проблемы, и даже проставить «оценочки», дать советы по исправлению. Если у вас ваш сервис уже где-то доступен, вы можете просто вводить URL, но также есть плагины, которые могут делать тесты локально. Первый сервис PageSpeed от Google, у него есть Chrome-плагин, который может локально проверить, насколько всё хорошо, и дать вам советы — сразу есть о чем поговорить со своими разработчиками.
Еще из продуктов по тестированию перформанса есть такой классный сервис WebPageTest, тоже дает оценки, которые отображаются в правом верхнем углу:
Один из параметров FirstByteTime — это время c начала перехода на страницу до тех пор, пока не появится первый бит ответа сервера на вашем сайте. Также тут есть оценка кэша, красивые графики, которые расскажут вам, что именно занимает больше всего времени на вашей страничке, картинки ли это, скрипты или HTML. Вы получаете красивые картинки с конкретными числами, с которыми вы сможете подойти к своему разработчику.
Еще одна особенность этого инструмента — можно указать, откуда этот тест проходить, в каком браузере и даже с какой скоростью интернета. В принципе, с его помощью можно сделать выводы, где нам размещать дата-центр, откуда ходить, настолько ли плохо, что сейчас у нас нет центра где-нибудь в Австралии. Кстати, у них есть API, можно попробовать использовать и для автоматизированных прогонов.
Еще один плагин к браузеру (к Chrome точно есть) называется Lighthouse — такой маяк, который оценивает ваше приложение с разных сторон, т.е. как приложение в общем, так и перформанс, accessibility, доступность для людей с ограниченными возможностями.
Вот так может выглядеть отчет по проверке тестирования именно перформанса:
На картинке видно, как выглядело мое приложение через разное количество секунд. Не так и классно, на самом деле. Как видите, там 56 пунктов, т.е. это так, сайт-середнячок. С помощью этого плагина мы также получаем некие цифры, с которыми можно подойти к своему разработчику и поговорить.
Конечно же стоит упомянуть JMeter. Он очень популярен, но, в отличие от тех инструментов, про которые мы говорили выше, на JMeter мы обычно оцениваем скорость именно серверной части. А еще пользователи часто жалуются, что в нем не очень работает record, и люди покупают какие-то специальные продукты для того, чтобы записать сценарий и потом загружать его в JMeter. есть простой способ — вкладка называется network в браузере, где видно все запросы. Вы просто нажимаете правой кнопкой мышки и можете сохранить все эти запросы как HAR, архив HTTP. Есть также BlazeMeter Converter — специальный конвертер, который умеет превращать эти HAR-файлы в тест-план для JMeter, т.е. вы просто проделали некоторые действия у себя в браузере, зашли на специальный сайт конвертера и получили уже готовый тест-план для JMeter. BlazeMeter Converter позиционирует себя, как конвертатор не только из HAR-файлов в JMeter тест-планы, но и XML, Selenium и JSON. Если честно, кроме HAR я ничего не пробовала, если кто-то попробует, было бы классно узнать о результатах.
Поговорим про кроссбраузерность, проверки совместимости. Многие с этим сталкиваются, особенно кто тестирует веб, и особенно если нужно поддерживать Internet Explorer: тут всплывают особенно необычные проблемы, например, у IE ограниченное количество строк, которые влезают в экран, больше 46424 строк вы отобразить вообще не можете.
Как тестировать разные версии? Если с Chrome и Firefox более-менее понятно, можете себе их легко поставить и более старых версий, с IE всё не так просто: ставится не везде и 2 версии параллельно не поставить. Microsoft неожиданно пошли навстречу и сделали бесплатный сервис, где можно скачать уже готовые виртуальные машины с установленным Windows и определенными версиями IE.
Официально эта виртуальная машина где-то месяца через два скажет вам, что она просрочена, но не поддавайтесь — легкая перезагрузка этой виртуальной машины позволит вам работать с ней еще долгие годы.
Есть, конечно, другие сервисы, такие как Browserstack или Saucelabs, наверняка многие из вас ими когда-то пользовались или пробовали, они платные, но тоже классные.
Что касатется мобильных, то я использовала Test Object: тут можно тестировать на реальных устройствах.
Тестирование безопасности, как и тестирование перформанса, тоже многие обходят стороной, хотя самые простые проверки сделать не так уж и сложно. Есть плагины, правда, только для Firefox, называются XSS Me / SQL Inject Me, по названию самых популярных уязвимостей в веб-приложениях. Они работают по принципу черного ящика, то есть вы ставите себе плагины, они находят текстовые поля на странице и вставляют туда скрипты, которые есть у них в базе. Эта база — просто XML, вы можете расширять его своими данными. На выходе получается готовый отчет, какие именно тестовые сценарии прошли, какие нет, какие именно тестовые данные не заработали, на какой символ произошла какая-то проблема, т.е. я могу взять руками этот же символ, попробовать сделать на своем ресурсе и увидеть, что именно пошло не так. Здесь обращаю ваше внимание, что эти плагины раскрашивают плохо или хорошо в зависимости от HTTP-статуса. Соответственно, статус 200 — всё хорошо и ответ будет зеленым, если у вас приходит 400-500 — красным, если приходит 302 — также красным. В отчете это будут красные клеточки, и мы ручной проверкой можем удостовериться, что это redirection на ожидаемую страницу, а не куда-то вовне.
Также есть инструменты, которые позволяют перехватывать запросы или писать свои с нуля. Я часто использую Fiddler или Charles (про него даже был отдельный пост, habr.com/company/redmadrobot/blog/269109) — отслеживаю запросы и переиспользую с измененными параметрами. Эти тесты можно выгрузить в файл и отдать автоматизаторам или просто переиспользовать позже. Также с помощью Fiddler можно быстро отправить кучу одинаковых запросов: хоткей Shift+R позволит повторить выбранный запрос сколько угодно раз.
Есть аналог для браузера — плагин tamper data (доступен и для Firefox, и для Chrome): он не такой функциональный, в нем нельзя эмулировать долгую работу сети или еще чего-то такого, но самые простые запросы, именно перехватывать и отправлять самому, подправляя их на лету, там тоже можно. Хочу обратить ваше внимание на то, что если вы работаете на Windows, я бы предпочла на вашем месте Fiddler, он всегда бесплатный. На Mac Fiddler работает так себе, т.е. официально он поддерживается, но бывают проблемы, лучше используйте Charles, только имейте в виду, что официально у них только 30 дней бесплатного использования.
Еще хочу поговорить про один плагин, Web Developer. Это инструмент на все руки, с его помощью можно и проверить HTML локально, изменять cookies, отключать, JavaScript или картинки — не нужно рыться в настройках браузера, всё всегда в одном месте на красочной и не сильно заметной панельке вверху вашего браузера.
Также его можно использовать и для security-тестирования: например, можно превращать выпадающие меню в текстовые поля, тем самым убирая клиентскую валидацию, проверить, готова ли серверная часть к странным данным.
Обычно первая ассоциация с «инструментами для тестирования» — это инструменты, где тесты можно писать и прогонять. Тут большое разнообразие инструментов: есть большие инструменты вроде HP QC, MS Test Manager, Test Rail. Есть бесплатные инструменты, как, например, Leantesting — если кто-то прямо сейчас выбирает, куда записывать свои тесты, обратите на него внимание. Есть Test Link, с ним очень сложно работать из коробки, зато у него открытый код и можно «допилить» под себя. Есть также и специальные инструменты для чек-листов и mind maps.
Для тех, кто пользуется Test Rail: есть специальное маленькое приложение Moqa, с помощью которого можно проходить тесты или следить за результатами прохождения прямо с мобильного. Доступен и для iOS, и для Android.
Пару слов о mind-картах. Они повсюду. Mind-карты — классный инструмент для того, чтобы визуализировать те тесты, которые вы собираетесь проводить, показать связи между ними.
Немного best practices: можно заранее сделать майнд-карту (или чек-лист, как вам больше нравится), верхнеуровневую, и описать в ней, про какие виды тестов нужно не забыть подумать для каждой функциональности: тестировщики часто сосредотачиваются только на acceptance-критериях и забывают подумать в общем: и про compatibility, и про перформанс, и про security и прочие виды тестов. Я стараюсь начинать именно с верхнего уровня и постепенно углубляться в детали. И да, на картинке есть ошибка. Для тех, кто будет на Heisenbug в этот четверг: если найдете ошибку, подойдите ко мне на BoF-сессии, получите маленький приз 🙂
После того, как мы посмотрели на функциональность в общем, углубляемся в детали: расписываем, какие есть объекты, какие сценарии необходимо посмотреть (CRUD — create-read-update-delete, например), какие данные можно вводить, классы эквивалентности, границы и прочее, т.е. мы уже всё больше и больше детализируем свои «тест-план».
Важный совет: не надо начинать карты с деталями, ваша карта становится очень большой и малоприменимой, старайтесь двигаться от общего к частному, не наоборот.
Инструментов для mind-карт существует какое-то бесчисленное количество. Я последнее время всё чаще рисую их просто на бумаге, но такую карту, естественно, сложно поддерживать. Среди софтверных решений у меня любимчик, MindMup: бесплатный онлайн-инструмент, карты из которого можно сохранять просто на гуглдиск и делиться ими со своими коллегами. Среди прочих есть, например, Coggle, выглядит очень красиво, но, если вы создали кружочек не в том месте, в котором изначально хотели, вам придется сделать много кликов, чтобы все исправить. Как Atlassian-эксперт, не могу не сказать, что есть и решения внутри Jira и Confluence: есть плагин-коннектор от Mindmeister, Yoikee, но он только для Confluence, и в обеих системах доступен коннектор в LucidChart.
Наша mind-карта, по сути, похожа на чек-лист: это некий список проверок, который нам хотелось бы пройти. Если мы просто делаем упрощенную документацию, заводить специальное приложение как-то дорого и необоснованно. Поэтому есть специальные инструменты, которые позволяют вам вести именно чек-листы: облегченные и заточенные именно на то, что ваш тест — это одна строчка. Например, Checkvist — но конкретно он не заточен под тестирование, и визуально мне, как тестировщику, не очень, когда мой тест кто-то зачеркнул, хочу явно проставлять статусы.
При дальнейших поисках нашелся специальный инструмент для тестирования — TestPad.
У вас есть какой-то перечень проверок, т.е. некая иерархическая структура, и ваш тестовый прогон — это дополнительная колонка в этой структуре. Вы просто добавляете колонку, можете заводить какие-то свои параметры, если вам нужно, например, версию операционной системы или браузеры, и один за другим проставлять статусы, прошел тест или нет, были ли какие-то вопросы. Можно оставлять комментарии, ссылки на багтрекер, есть интеграция с той же Jira. Единственный минус: этот продукт доступен только в облаках, т.е. это сервис, локально себе поставить нельзя.
Если и аналог внутри баг-трекера Jira, разработанный нашей компанией, Structure.Testy
Тестировщик должен понимать, что какую-то документацию рано или поздно писать всё равно придется, если вы свой продукт тестируете не один раз. Я много раз слышала отговорки типа «я же всё равно единственный тестировщик, я тут всё знаю, зачем мне эти чек-листы?». Даже если вы совсем один, это не значит, что документация не пригодится. Вам совсем одному всё равно придется тестировать ваш продукт снова и снова, и вы можете заранее облегчить себе работу.
Маленькие подсказки для тех, у кого совсем ничего нет, или кто совсем не знает, с чего начать. Есть куча сервисов с уже готовыми чек-листами, которые можно просто адаптировать под свой продукт. Например, есть несколько сервисов конкретно для тестирования usability, первый из них — это usability checklist, сервис, в котором перечислены некоторые проверки, про которые хорошо бы подумать, вплоть до того, как оформлена первая страница, как работает навигация, работают ли все ссылки и т.д. Есть специальные сервисы, которые проверяют только цвета, например, checkmycolours проверяет контрастность цветов.
А еще специально для вас у меня есть суперссылка, по которой вы можете найти целую базу готовых чек-листов: если у вас совсем ничего нет, можете начать с них, если уже есть свои документы — можно вдохновиться на новые тесты! Берите и адаптируйте для своих нужд, и пишите, если у вас есть идеи, что еще туда стоит добавить!
Помните, что тестирование бывает не только функциональным, и даже если вы ручной тестировщик, это не значит, что вы не должны заниматься другими видами тестов: c помощью подходящих инструментов это можно делать достаточно быстро, легко и эффективно. Нет ничего страшного ни в тестировании перформанса, ни в security — есть «помощники», которые можно использовать на первых этапах. Не забывайте документировать свои тесты — это важно, вы из будущего скажете себе спасибо.
Вот здесь перечислены все используемые в статье инструменты, там же можно оставлять комментарии и задавать вопросы. Берегите время и используйте инструменты!
Минутка рекламы. Если вам понравился этот доклад с конференции Heisenbug — обратите внимание, что уже подступает новый Heisenbug (17-18 мая, Санкт-Петербург), в его программе тоже много интересного. Надеемся увидеть там многих из вас!
Кто такие тестировщики игр и чем они занимаются, что нужно для того что бы научиться этому и какие знания?
Я сам попал в Game QA чисто по везению — одна крупная международная компания по разработке мобильных игр открывала новое подразделение, и набирала большой штат тестеров. Из требований были лишь знание английского на уровне не ниже Upper Intermediate, аналитическое мышление, внимание к деталям, умение работать в команде, базовое знание iOS, базовое знание теории тестирования и любовь к мобильным играм. У меня ещё был небольшой опыт QA-фриланса (веб в основном) и опыт работы в команде на одном из конкурсов по созданию игры за три дня. Может, потому и взяли.Как работается.
Есть билд игры, есть документация на игру, есть средства общения с твоей командой тестирования, и, наконец, есть багтрекер (туда заносятся все баги). Могут быть также различные документы, которые надо заполнять, и ещё могут быть инструменты для ковыряния уделённых данных игроков на сервере. В начале дня тебе дают задание протестировать конкретный участок игры, причём это может быть всё что угодно: от конкретного уровня, до совместимости на разных устройствах и аж до рекламы и соцсетей. Ты, взяв (или сев за) устройство, открываешь документацию, читаешь части, которые относятся к заданию, и, не забывая поглядывать в чат команды (и слушать, что говорят вокруг тебя), «играешь», проходя по пунктам, которые указаны в задании и/или документации, чётко проверяя всё и не забывая деталей. Если тебе показалось, что ты нашёл баг, ты сперва смотришь в багтрекер, не находил ли кто такой баг. Если нет, то консультируешься с коллегами, и если всё ок, то заводишь баг в багтрекере по чётко заданным правилам и формам, не забывая отметить в прочей документации по заданию номер заведённого бага.
Кажется, что вроде бы всё просто, но вот задания бывают очень комплексными, непонятными и однообразными (а времени — очень мало), описания в документациях — расплывчатыми или отсутствующими вовсе, а коллеги подвержены человеческому фактору. В результате — «что мне делать, я не понял?», головная боль и волнение из-за того, что баг, который ты пропустил как слишком мелкий или не приоритетный по указанию вышестоящего QA, обнаружат пользователи… И да, если ты закончил задание раньше времени — тебе просто дадут новое, для тестеров всегда найдётся работа 😛 Ах, да, ещё game QA платят обычно меньше, чем остальным QA…
Работать игровым тестировщиком ещё не перехотелось? Вот что, по моему, нужно для того, чтобы были шансы побольше:
- Знание английского. Хотя бы Intermediate (реальный), а лучше — Upper Intermediate. Нужно почти везде, говорю из своего опыта поиска работы на QA длиной в 7 месяцев. Где учить — не знаю, у меня он как-то сам собой выучился, благодаря игре в игры на языке оригинала и просмотра англоязычных фильмов с субтитрами.
- Теория тестирования. Нужно, чтобы хотя бы приблизительно представлять себе, как проходит процесс коммерческого тестирования. Прочитай Савина «Тестирование Дот Ком», например, эта книга даст тебе основы. Можно ещё найти бесплатные курсы (как делал я, например). А ещё можно порегаться на сайтах вроде BugFinders/uTest/testIO и попробовать свои силы там. Не то, чтобы тестирование всяких интернет-магазинов сильно помогало в накоплении опыта тестирования игр, но процесс слегка похож, да и немного долларов/евро/фунтов подзаработать изредка можно. Я начинал именно с этого.
- Компьютерная грамотность — без комментариев. И в iOS/Android тоже желательно бы разбираться, сейчас в большинстве вакансий если не веб, то мобилки.
- Игровой опыт — не настолько обязателен, как может показаться, но он поможет быстрее вникнуть в игру и позволит во многих случаях понять, где баг, даже ещё не сверяясь с документацией. И да, как написал Saboteur выше, тестировать, с большой вероятностью, придётся «унылые флешки», так что если не играл в мобильные/браузерные социальные казуалки с донатом — самое время ознакомиться.
- Навыки общения и красноречивость — бывает, необходимо кратко и в то же время ёмко описать то, что ты нашёл, и почему это баг, а также его значимость. В том числе и на английском, если придётся. Впрочем, в команде это быстро наверстается (если коллектив нормальный).
- Любить игры и ковыряние в них — обязательно, потому что иначе работа быстро осточертеет 😛
Как-то так. Надеюсь, хоть чем-то, да помог. Желаю удачи в поисках работы 🙂 (Да, начинай искать уже сейчас!)
Что почитать джуну тестировщику, кроме книг по тестированию? — Хабр Q&A
вообщем всё, что тестировщику пригодится в работе.
Зависит от того, что придется тестировать.
В идеале, тестировщик должен иметь хотя бы общее представление о работе всех элементов системы, которую он будет тестировать.
На практике это все приходит по мере возникновения проблем\вопросов.
Что нужно знать джуну-тестировщику, в самом общем виде?
1) Нужно понимать теорию тестирования: что есть дефект, приоритеты(классический вопрос про priority & severity), базовые практики тест-дизайна, понимание того как и зачем писать тесткейсы, понимание того, как локализовать ошибку.
2) Нужно иметь общее представление о предметной области:
Если тестируете веб — общее представление о клиент-серверной архитектуре, всякие пост-гет запросы, и прочеее прочее. + REST и API
Если тестируете мобилы — подробнее почитать про специфику тестирования мобил.
ну и т.д. с декстопами, железом, смарт-картами и прочим добром.
3) Базы данных. Иметь общее представление о реляционных и не-реляционных базах данных, уметь написать селектики на SQL, дальше уже плясать от конкретного стека технологий.
В целом все это отлично рассказывается в рамках тематических материалов по тестированию. Форумы, доклады, видеоуроки и в последнюю, пожалуй, очередь, книги. Толковых книг по тестированию предельно мало.
В целом — здесь вам нужно приобрести главный для тестировщика (да и любого специалиста) навык — умение быстро находить и усваивать нужную вам информацию.
Список перечисленных вами технологий смутил.
Кибана — GUI обертка для NoSQL базы данных, зачем джун тестировщику это знать — не представляю. В большинстве мест вы с ней не столкнетесь, а когда столкнетесь — разберетесь за полтора дня с Lucene Query и будете жить радостно.
XPath и Selenium — это для автотестировщика. Сажать джуна (человека с минимумом опыта) за автотесты — насилие над продуктом и человеком. Потом пригодится, на этапе джуна — фактически не нужно (понятно, что знание не лишнее, но применять оные вам вряд ли придется).
XML — ну, что нужно знать про хмл я, честно говоря, не знаю. Разве что что это такое и как выглядит.
В целом, стоит учитывать что тестировщик должен быть широкопрофильным специалистом. В идеале, вы должны иметь достаточно знаний что бы отлавливать ошибки аналитика (составлять\вычитывать\анализировать тех. документацию), разработчика (whitebox тестирование, локализация ошибки и прочее), инженера по конфигурации, понимание юзабилити и прочего.
Как результат — знаний требуется вагон и маленькая тележка, и чем выше вы для себя ставите планку, тем глубже надо понимать, как работает продукт.