Я не думал особо долго на счет того, с чего начать мой телеграм-канал , какие посты запилить первыми. Не думал, потому что сама идея создания канала уже назрела под давлением обстоятельств.
«Каких?» — спросите вы.
Что ж. Вы хотите знать причины. Их есть у меня!
Но сначала чуть чуть о себе. У меня достаточно большой (хоть и не громадный) опыт в тестировании и обеспечении качества — с 2011 года. А с 2015 — опыт руководства командами. Сначала это была fullstack команда разработки, занимающаяся тестированием космических аппаратов. Затем руководство группой тестирования в одной из зарубежных компаний.
Так получилось, что я постоянно ищу себе в команду тестировщиков и как-то так сложилось, что чаще всего я обращаю своё внимание на перспективных новичков. Мне нравится развивать и драйвить команду, нравится наличие свежего взгляда в команде, нравятся горящие глаза и светлый ум (Ну ещё они не хотят сразу миллионы зарабатывать на тестировании — да, это тоже плюс).
Кто такие ТЕСТИРОВЩИКИ / Как начать тестировать / Интервью с Senior QA Engineer
Однако, я так же вижу, как много начинающих тестировщиков делают всё или почти не так. В индустрии так сложилось, почему-то, что все ресурсы заполнены шаблонами/копирками идей и рекомендаций для новичков и все они, по моему мнению, сильно устарели. Это не значит, что они бесполезны. Скорее — они неэффективны.
С другой стороны я вижу, как рынок желает всё больше и больше инженеров по качеству и как много людей (хоть и недостаточно) желают войти в IT через тестирование. И знаете что? На рынке труда совсем нет матёрых мидлов или синьоров. Почему? Да потому, что они все при местах.
Либо их хантят с такой скоростью, что они даже не выкладываются на hh.ru. Что всё это значит? Я вижу задачей этого канала решить боли обеих сторон:
- Новички получать больше информации, способствующей получению желаемой должности и быстрому профессиональному росту;
- Компании наконец смогут чуть чуть выдохнуть и не браковать 99 из 100 новичков, откликнувшихся на вакансии.
Guys! You have to quit that shit cold turkey!
«Перестаньте делать не то прямо сейчас»
Про то, с чего начать
Первая часть поста про то, с чего начать знакомство с миром тестирования и QA. План статьи был такой:
1) Рассказать с чего начинают и почему это плохо
2) Рассказать с чего стоит начинать
Но! Наткнулся на статью QL, где они и так выжали максимально кратко и полезно по этому вопросу. Поэтому, первое что нужно сделать, это прочесть эту статью.
Совсем-совсем коротко о чем было в статье (в порядке приоритета):
- подпишитесь на паблики/каналы про тестирование
- читайте книги по тестированию
- пройдите какой-нибудь курс «начинающего тестировщика»
Теперь расскажу о своём — о наболевшем.
Первое, что слышу от новичков-кандидатов «Прочел книгу Савина Тестирование.com»
— Хорошая ли это книга?
— Достаточная ли она для понимания и начала посещения собеседований?
Тестировщик: минусы профессии, о которых важно знать
— Абсолютно нет‼️
В этой книге всё очень упрощенно и абстрактно. Её несомненная польза в одном: она позволяет несведущим в ИТ людям погрузиться в тестирование и проникнуться идеями.
Вывод: если вы связаны с ИТ или если уже чуть-чуть потестировали и хотите больше — можете не читать эту книгу, она не возымеет должного эффекта.
Второе, что я слышу после тестирования.com это «Рэкс Блэк — ключевые процессы тестирования». Боже мой! Совершенно бесполезная книга для новичка.
— Хороша ли эта книга?
— Нужна ли она начинающему тестировщику?
— Боже, нет‼️
В этой книге рассказывается история тестменеджера. При чем ТМ в достаточно классической каноничной компании. Много ли у нас таких компаний в России? Нет. Зато у нас на рынке куча вакансий с историей «Мы тут решили, что пора бы начать тестировать» и «Мы расширяемся, третьим будешь?» Но историй про налаженные процессы не так уж много.
Вывод: скачайте эту книгу и начните читать её спустя 6-12 месяцев работы тестировщиком.
Третье. Я не хочу никого обижать, поэтому тут не будет конкретных названий. Но пункт я назову «Невнятные курсы по теории тестирования». Я считаю, что курсы надо проходить обязательно. Но обязательно узнайте у менеджеров — будут ли боевые проекты.
Будут ли практические задания и на сколько они практические. И если вас что-то смущает — подумайте ещё и поищите ещё.
Вывод: идите на курсы. Но не полагайтесь лишь на одну теорию. Для теории у вас есть паблики/каналы, ютуб и книжки.
Это было про наболевшее.
А теперь о том, что стоит сделать в первую очередь, если хочется войти в тестирование. И вот вам еще статья, которая как нельзя в тему. Я бы с удовольствием хотел её разобрать всю и прокомментировать, но возьму себя в руки и лишь позаимствую и переделаю последнюю часть статьи
Чеклист вхождения в профессию (заранее оговорюсь — вцелом я согласен с видением автора) Коротко, её чеклист следующий:
- Полюбите ИТ
- Прочувствуйте своего внутреннего тестировщика
- Возьмите книги по тестированию и отложите
- Окунитесь в сообщество
- Начните работать
- Вернитесь к книгам
- Осознайте, что учиться надо каждый день
Я же считаю, что надо сделать следующие 3 самые важные вещи:
1. Книги по тестированию
— Если вы не из ИТ или в ИТ совсем недавно и тестировщиков вообще не видели — Роман Савин: Тестирование .com — для чтения в метро
— Если вы из ИТ или поработали чуть чуть «проверяльщиком» по совместительству: Lee Copeland — A Practitioner’s Guide to Software Test Design — ваша новая любимая книга
2. Окунайтесь в сообщество, всё верно. Подписывайтесь на блоги, читайте статьи, смотрите видео на ютубе (все ссылки в статье Quality Lab в предыдущем посте). А вот еще классный ресурс.
3. Начните работать. И тут мой вам лайфхак — не ждите разрешения на работу — начните прямо сейчас! Тестируйте приложения, которыми пользуетесь. Качайте новые. Тестируйте сайты или порталы.
Пробуйте всё, что узнаете в п.2. Да, лучше начать искать работу или стажировку, но мой вам совет — делайте что-то для себя уже сейчас! Особенно это полезно, если устраиваетесь к кому-то (но об этом в других постах, про собеседования и резюме). Зарегистрируйтесь на upwork, а еще лучше на uTest и пройдите там uTest Academy! Это нереально вас бустанёт!
Я бы хотел продолжить в этой статье размышления про резюме. Но пожалуй лучше сделаю это в отдельной статье, чтобы не раздувать и без того длинную писанину.
Комментарии приветствуются, дайте знать, если всё хорошо. Критика уместна, дайте знать, если не всё хорошо! =)
Источник: vc.ru
Как стать тестировщиком ПО: от собеседования до поиска первого бага
Руководитель отдела тестирования компании Globus Алексей Сёмин рассказывает, как стать тестировщиком, и даёт несколько ценных советов из личного опыта. Если вы хотите попробовать себя в качестве специалиста в области тестирования, то эта статья поможет сделать первый шаг.
Алексей Сёмин
Руководитель отдела тестирования компании Globus, которая занимается разработкой мобильных приложений и сайтов для крупных заказчиков, таких как «Яндекс», «Лаборатория Касперского», ABBYY, Rutube, «СТС Медиа», HeadHunter, «ТНТ Клуб», «Связной Трэвел», «PPF Страхование жизни», VimpelCom и других. Более шести лет в профессии. Прошёл весь путь от junior-тестировщика до руководителя отдела.
Мой путь тестировщика начался с любопытства. С самого детства я занимался сборкой компьютеров и установкой ПО, в ходе работы регулярно возникали вопросы: «Почему не устанавливается? Почему не работает?». В этот момент я подумал, что хочу стать тестировщиком, заниматься выпуском качественного ПО и узнать ответы на все эти вопросы.
Ниже я хочу рассказать будущим QA-специалистам о том, что их ожидает в начале карьеры, и дать несколько советов из своего опыта.
Собеседование
Junior-тестировщику не очень сложно пройти собеседование. От него не ждут глубокого знания теории и инструментов для тестирования. При собеседовании таких кандидатов мы обращаем внимание на скорость и живость мышления, свежий и нестандартный подход к решению задач.
Например, задаём необычные вопросы, чтобы посмотреть, как мыслит человек:
- Самолёт вылетает из точки А в 17:00, а прилетает в точку Б в 19:00. При этом находится в полёте три часа. Почему такое может быть?
- Как сделать так, чтобы, получив обновлённое приложение, конкуренты не смогли узнать его новые функции?
Будьте готовы и к самому обычному заданию — протестировать простой предмет: лист бумаги, карандаш, сетевой фильтр и тому подобное.
Также для собеседования будет полезно:
- Изучить виды тестирования: функциональное и исследовательское тестирование, автоматизированные тесты (включая инструменты для него), нагрузочное и стресс-тестирования, smoke-тестирование.
- Дополнительно почитать о приёмочном тестировании и его критериях.
- Если мы говорим о тестировании веб-приложений, то это браузерная консоль и её работа, количество и версии браузеров, разрешения мониторов, инструменты тестирования вёрстки (pixel perfect).
- Если мы говорим о мобильных приложениях, это виды платформ, эмуляторы, monkey testing. Не забудьте о планшетах.
- Изучить виды баг-трекеров. Самые популярные: Jira, BugZilla, RedMine, Mantis. Посмотрите, как они работают, в чём их особенность.
- В перспективе — инструменты Jmeter, Postman, Charles. Они не очень сложны в освоении на базовом уровне.
Первый рабочий день
Первый рабочий день проходит стандартно: выдают компьютер, который нужно настроить, установить рабочие программы. Системный администратор готовит доступы к почте и корпоративным внутренним программам.
Не стоит спрашивать, где установить Skype, использовать в нём ник со школьных времён gangsta_666 или забавную картинку. Используйте в нике сочетание имени и фамилии, например ivansmirnov или smirnovivan, поставьте свою обычную фотографию.
Важный шаг в подготовке к рабочему дню — знакомство с баг-трекром, который использует компания. Об этом стоит поинтересоваться заранее: изучите статьи, посмотрите обучающие видео. Вы сэкономите время коллег и сами будете чувствовать себя увереннее.
Первое задание
Вам будет предоставлен первый проект для погружения. Советую ознакомиться с историей баг-трекера и посмотреть, какие дефекты уже встречались или чаще всего встречаются. Сможете для себя сформулировать статистику и будете понимать, на какие моменты стоит обратить больше внимания.
Проявляйте инициативу. Если вам не дали чек-лист приложения, не ждите, а попросите его у ментора. Если в организации нет чек-листа, вы можете составить его сами. В нашей компании чаще чек-лист составляют в «Google Таблицах». Ниже мы привели пример такого чек-листа — вы сможете составлять свои по его примеру.
Коллеги будут удивлены, если составите чек-лист в виде карты мыслей, например в Xmind.net.
Чек-лист для тестирования Pokémon GO
Одним из первоочередных видов тестирования для начинающего QA-специалиста, возможно, станет прохождение по чек-листам, тест-кейсам более старших специалистов. Этот этап необходим для более быстрого погружения в проект. Для наращивания тестовой базы новичок может сам расширять этот чек-лист. Junior-тестировщики в рамках обучения написанию чек-листов подготовили лист для тестирования приложения Pokémon GO. Тут описаны только позитивные кейсы.
Первый баг в трекер
Описание багов в разных компаниях может различаться, но в целом есть принципы хорошего тона.
Тема
В ней описывают проблему несколькими словами. Лучше, если она будет начинаться с отрицания: «не работает», «не происходит», «неправильно» и прочее. Например: «Не происходит синхронизация с сервером на iPhone 6», «Не работает воспроизведение видео в Nexus 5».
Сценарий
Пошаговое описание воспроизведения бага. Обращайте внимание на предусловие и знаки, которые предшествуют багу (например, загорелась красная кнопка слева).
Дополнительно можно приложить скриншоты с указанием мест, на которые стоит обратить внимание (можно использовать приложения Joxi, LightShot и другие), для более сложновоспроизводимых багов — записать видео. Когда наберётесь опыта, можете снимать и прикладывать логи.
В конце сценария указывается среда, в которой проводилось тестирование: версия приложения, прошивка девайса (Android 6.0.1, iOS 9.3.2). Если это веб-приложение, дополнительно укажите версию браузера.
Назначение бага
Далее нужно назначить на кого-то баг. Узнайте у менеджера проекта или ментора, на кого вешать данный баг, кто из разработчиков за какую область проекта отвечает. Так вы познакомитесь с командой, чтобы в будущем самому назначать баги.
Проставление критичности
Виды критичности багов в большинстве трекеров представлены следующим списком:
Immediate (Blocker)
Блокирующая ошибка. Приводит приложение в нерабочее состояние, в результате которого дальнейшее взаимодействие с тестируемой системой или её ключевыми функциями становится невозможным.
Crit — Urgent
Критическая ошибка, нарушена ключевая бизнес-логика. Проблема приводит к временному падению сервера или приложения без возможности её решения. Устранение проблемы необходимо для тестирования.
High
Значительная ошибка, нарушена часть основной бизнес-логики. Ошибка не критична, есть возможность для работы с тестируемой функцией, используя другие входные точки.
Normal
Незначительная ошибка. Не нарушает бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса и локализации.
Low
Тривиальная ошибка, не касается бизнес-логики приложения. Проблема сторонних библиотек или сервисов, плохо воспроизводится, малозаметна ввиду пользовательского интерфейса.
Самообучение
О важности самообучения все прекрасно знают — мои наставления будут банальны. Так что сразу к делу.
Ниже — несколько книг, которые лично рекомендую своим стажёрам:
- «Тестирование DOT COM», Роман Савин — очень полезное пособие, практически настольная книга начинающего тестировщика. Содержит в себе львиную долю знаний для того, чтобы начать тестировать и успешно отвечать в ходе собеседования на вопросы, касающиеся технико-теоретической части.
- «Как тестируют в Google» — более глубокая книга, описывающая организацию процессов, различные стратегии и подходы к тестированию. Книга помогает понять, что такое качество, как и на каких этапах на него можно влиять.
- «A Practitioner’s Guide to Software Test Design», Lee Copeland — в книге расписаны виды тестирования как «белым», так и «чёрным» ящиком. Перечислены различные техники тестирования, а также то, как ими пользоваться и когда лучше применять. В книге можно найти интересную статью об исследовательском тестировании, которая очень полезна для начинающих тестировщиков.
Коллеги, напишите в комментариях названия интересных книг для тестировщиков. Уверен, всем будет полезно.
Заключение
В заключении хочется добавить,что выпуск качественного продукта — процесс нелёгкий и небыстрый. Нужно уметь отстаивать своё мнение в переговорах, убеждать разработчиков делать правильно, а не на «костылях», понимать, как сделать функциональность более удобной для пользователей.
Это лишь часть нужной информации для начинающего тестировщика. Всё остальное придётся в боевых условиях искать в интернете, потом спрашивать у коллег. Не надо стесняться задавать вопросы и часами гуглить, зачастую ответ на один вопрос сэкономит вам немало времени в будущем.
Источник: lifehacker.ru
С чего начать начинающему тестировщику
Направление тестирования быстро развивается. Если ещё несколько лет назад можно было практически без знаний и опыта устроиться работать ручным тестировщиком и учиться непосредственно на работе, то в 2022 году сделать так уже сложнее. Приходится учиться. Ниже представлен минимальный список того, что нужно знать начинающему тестировщику — или QA-инженеру, как всё чаще называют представителей нашей профессии — чтобы не быть мартышкой, которая просто тыкает в кнопки.
Задача тестировщика — убедиться, что все функции продукта, описанные в функциональном задании, работают так, как ожидается. Ошибки работы, или баги, он выявляет разными видами тестирования. На баги проверяется и дизайн, и фронтенд, и серверная часть — и не раз. Если вы хотите заказать у нас мобильное приложение, можете положиться на наш отдел качества, где работают одни из самых придирчивых людей компании. Обсудить сотрудничество можно после того, как вы заполните контактную форму.
Личные качества тестировщика
- . Считаю, что они важнее . Последние можно развить или вызубрить, а вот с гибкими навыками чаще всего рождаются. Коммуникация в нашем деле — чуть ли не основная часть работы, и умение находить общий язык даже с теми, кто вызывает неприязнь, крайне важно;
- умение грамотно излагать мысли устно и письменно. Так как OA-специалист пишет много разных репортов, это тоже очень важно. Невнятная писанина может сильно усложнить работу всей команде;
- проактивность и готовность брать ответственность. Нельзя просто сидеть и ждать, пока тебе скажут, что делать. Важно понимать, что ты — часть команды и твоё действие или бездействие напрямую влияет на качество продукта и, как следствие, на компанию;
- планирование своего времени с помощью календаря, , ежедневника или блокнота. Важно заранее видеть, где в работе могут быть простои или перегрузы, и принимать шаги, чтобы их сгладить.