Доброго всем дня!
Я хотел бы узнать, как можно обучиться на тестировщика, если у меня нет профильного образования. Поделитесь, пожалуйста, своим опытом. Какие курсы вы проходили? Или с помощью книг/роликов на ютубе?
Спасибо!
Я хотел бы узнать, как можно обучиться на тестировщика, если у меня нет профильного образования. Поделитесь, пожалуйста, своим опытом. Какие курсы вы проходили? Или с помощью книг/роликов на ютубе?
Спасибо!
Всем привет! Мои ученики активно учатся на ручных тестировщиков и я пробую создавать разные инструменты и подходы для освоения новой для них сферы.
Сегодня состоялся релиз первой версии телеграм бота для подготовки к собеседованиям, бот бесплатный, так что пользуйтесь и пишите фидбэк, кому будет интересно.
Ссылка на бота: https://t.me/quality_academy_interview_bot
_________________
Телеграм школы: https://t.me/quality_academy
Мой тг канал: https://t.me/realization_spain
Дано: мужчина 61 год, образование физик-ядерщик, в прошлом военный, закончил в 84-м году Серпуховскую академию, гиперответственный. Писал на фортране и забивал перфокарту.
Имеет инвалидность, которая влияет и на интеллектуальные способности, то есть упадок есть и уровень, который был до болезни не потянет, но на уровне работать из дома, найти ошибки сделать и забыть вполне, -отсюда вопрос, может ли человек работать как джуниор тестировщик, хотя бы на пол ставки и есть ли подобные варианты? Если да, что для этого необходимо сделать?
Я ни фига в этой сфере не понимаю, так что тапками не кидайтесь.
Уже больше двух лет я занимаюсь обучением ребят с нуля одному из IT направлений, в котором, как мне кажется я неплохо разобрался за время своей практики. Сегодня хотел бы разобрать некоторые частые ошибки, которые допускают абсолютно все ученики и начинающие специалисты.
Самая частая ошибка при написании тест-кейсов, чек-листов и прочих артефактов. Не умение обезличить свою речь и оставить только внимание читателя на аспектах работы системы. Использование прилагательных, наречий и прочих конструкций, которые мешают восприятию документации.
Отсутствие скринкастов, скриншотов, либо присутствие, но оформленные настолько непонятно, что еще больше запутывают, нежели проясняют суть проблемы. Тестировщик сразу должен приходить к разработчику с фактами, разработчик не должен выковыривать из тестировщика и просить его доказать или что-то показать. Все должно быть уже готово заранее и при необходимости сразу же демонстрироваться, без необходимости ждать пока тестировщик (его величество) соизволит и зафиксирует свой/никому не нужный дефект на видео или скриншот.
Не достаточная степень локализации дефекта при водит к тому, что возникают несколько рычагов и тестировщик не понимает что из этого является следствием, а что причиной. А причина этому - не понимание того, как работает система.
Часто тестировщик уделяет большую часть своего внимания второстепенным вещам. Опять же в силу не понимания архитектурных особенностей / не понимание устройства системы.
Ученик или уже работающий начинающий QA вместо того, что включать голову и попробовать разобраться в сути и больше не возвращаться к этому вопросу, перекладывает всю ответственность на разработчика и постоянно его отвлекает по всяким пустякам, тратит и свое и его время. Поверхностная работа без желания понять суть работы системы - серьезная проблема.
Эти проблемы часто встречаются не только у учеников, но и у тех, кто так и не понял в чем суть работы QA инженера и просто тыкает на кнопки, вместо того, чтобы приносить пользу проекту, но у учеников они ярко видны, ведь они под наблюдением у меня каждый день.
Мой телеграм канал: https://t.me/realization_spain
Всем привет! На текущий момент на рынке сложилась довольно нехорошая ситуация в отношении курсов по тестированию. Конечно, дыма без огня не бывает и клеймо на любой инфорпродукт навесить очень просто и более того, чаще это справедливо, ведь как и другие школы я своим курсом зарабатываю, а вот подходы, инструменты и подача материалов сильно отличается и по итогу человек получает разные результаты.
Я не проводил аналитику курсов, не изучал детали обучения (хотя некоторые школы знаю изнутри довольно неплохо), но я проводил множество собеседований на позиции Junior QA в свою компанию и знания ребят, которые приходили после самых популярных курсов оставляли желать лучшего, поэтому в основе своей мой курс конечно же не является изобретением, но я постарался привнести в обучение свой взгляд и те вещи, которых не хватало тем ребятам, которым я отказывал в трудоустройстве.
В общем, курс курсу рознь и было неправильно грести все курсы под одну гребенку, поэтому сегодня я расскажу как выглядит обучение на Manual QA Engineer в моей школе / на моем курсе и мне было бы интересно узнать от тех, кто обучался в других школах используют ли они похожие подходы и/или инструменты.
Курс рассчитан на 4 месяца, поэтому всего представлено 16 спринтов (16 недель), в рамках которых обучаются ребята. Ребята занимаются в группах, и пока что у нас только одна группа, но в будущем группа будет содержать максимум 10 человек с персональным ментором. Пока что у всех ментором выступаю я :)
Каждую неделю провожу 2 онлайн лекции, на которых можно задать вопросы прям по ходу лекции. Но говорить может только лектор, все остальные могут только писать в чат. Проводится по понедельникам и четвергам или вторникам и пятницам, в зависимости от потока. Длительность одной лекции от 1,5 до 3 часов, в зависимости от темы лекции.
Каждую субботу мы встречаемся все вместе, чтобы обсудить трудности и разобраться вопросы или иные темы, которые могут выходить за пределы материалов курса. Здесь уже говорить могут все. Я собираю обратную связь от учеников, чтобы сделать мой курс еще лучше.
Всё как не реальном проекте. Домашние работы находятся в Jira. Выдаются каждый спринт от 5 до 7 практических задач.
Для того, чтобы закрыть спринт необходимо не только сдать все домашние задания, но и пройти тест (на время) по теоретическим вопросам спринта.
Вся учебная и техническая документация в Confluence. Никаких Google Docs и текстовых файлов. У нас всё как на большинстве реальных IT проектах.
Со второго спринта все ученики начинают сдавать домашние работы в свой репозиторий, тем самым понимая как работают разработчики и закрепляют знания работы с Git. У нас конечно не полноценный GitFlow, ибо смысла нет, а немного упрощенный формат. Но не на всех IT проектах есть и такой :)
Отдельное пространство школы, которое не пересекается с другими мессенджерами и позволяет сосредоточиться на учебе (на мой взгляд). Пока нас не так много и не сказать, что идут активные переписки, но это только начало :)
Не скажу, что сильно пользуется спросом, но решил прикрутить турбоверсию. Если будет актуально, то прикручу 4 версию, но пока просто эксперимент.
Лекции доступны в записи в телеграм боте на случай, если не удалось присутствовать онлайн в день проведения лекции. Ретроспективы доступны также в записи и останутся на память :)
Последний год я активно готовил ребят к собеседованиям и подкопил немного материалов, с которыми конечно же делюсь со своими учениками, чтобы они быстрее нашли свою первую работу. Есть база записей реальных собеседований моих учеников (более 40 записей) и вопросы, которые спрашивают в 90% случаях на тех. собеседованиях (более 400 вопросов).
Тут довольно просто и ничего нового, но постоянно создаю новые гайды, разрабатываем инструменты, чтобы еще эффективнее готовить начинающих тестировщиков.
Персональные созвоны раз в неделю доступы только на персональном тарифе, но на них мы готовимся к собеседованиям, разбираем индивидуально сложности и проблемы. Для тех, кому нужно персональное внимание, забота и еще больше корректировок :)
Вот как обучаю тестировщиков. Обучение довольно плотное, расслабляться некогда, домашек много и пока ребятам нравится, дальше будем глядеть и при необходимости корректироваться.
________________________________________________________
Ну и куда без своего личного телеграм канала, где пишу не только про обучение но и выкладываю фоточки, строю из себя Сократа и делюсь результатами моих учеников - https://t.me/realization_spain
Всем результатов!
Я пытаюсь запустить браузер opera в более новой версии selenium 4.12. Но на данный момент я не смогла найти решение. Возможно ли использовать WebDriverManager.operadriver().setup() для получения драйвера?
На данный момент реализация работает с указанием пути
private WebDriver createOperaDriver() {
WebDriverManager.operadriver().setup(); System.setProperty("webdriver.opera.driver", "C:\\Users\\anser\\operadriver.exe");
OperaOptions options = new OperaOptions();
options.addArguments("-start-maximized");
return new OperaDriver(options);
}
Но есть ли решение не указывать путь к драйверу, а использовать только WebDriverManager.operadriver().setup()?
Если не указывать путь до файла, получаю ошибку
java.lang.IllegalStateException: The path to the driver executable The path to the driver executable must be set by the webdriver.opera.driver system property; for more information, see https://github.com/operasoftware/operachromiumdriver. The latest version can be downloaded from https://github.com/operasoftware/operachromiumdriver/release...
Наша коллега, Валерия, выступала на конференции UIC Dev с докладом «Как выжить единственному тестировщику на проекте». А мы взяли и сделали из доклада статью для всех, кто не смог побывать на конференции и послушать его! Передаем слово Лере:
Всем привет! Рада, что вы заинтересовались моим опытом. Сначала кратко расскажу о том, что ждет вас в этой статье.
Поговорим про:
🔹 Плюсы и минусы работы единственным тестировщиком на проекте
🔹 С чего начать свой онбординг
🔹 Процессы и документацию
🔹 Оценку и приоритизацию задач
🔹 Как выстраивать work-life-balance в таких условиях
Пара слов обо мне:
Меня зовут Лера Калашникова, я Senior QA Engineer DexSys, ментор программы «Mentor in tech» и фасилитатор «IAmRemarkable».
Я работаю тестировщиком уже чуть больше 9 лет, и за это время я трижды была единственным, или почти единственным тестировщиком на проекте.
Дисклеймер: всё, что я буду говорить дальше, основано лишь на моём опыте и не является руководством к действию или инвестиционной рекомендацией. В жизни бывает всякое, я рассказываю о моментах, с которыми столкнулась я, и о том, какие уроки из этих моментов вынесла. Вам решать, подходит вам это или нет.
Когда ты единственный тестировщик на проекте – с одной стороны, вся нагрузка ложится на твои хрупкие плечи, а с другой стороны — у тебя же полный карт-бланш! Ты можешь работать с теми инструментами, с которыми ты любишь работать, и внедрять те техники и практики, которые кажутся тебе наиболее эффективными.
Например, я обожаю Postman и не привыкла работать в Insomnia. Поэтому в моём проекте мы используем Postman.
Ты выстраиваешь процессы самостоятельно, и у тебя есть право на ошибку. Твои первые шаги будут не всегда удачными, но, скорее всего, никто на это не обратит внимание. Главное — суметь вынести из ошибок уроки и двигаться дальше.
Из минусов — я столкнулась с таким моментом: когда ты работаешь единственным тестировщиком, становится очень сложно следить за тенденциями рынка. Ты всё время варишься в собственном проекте, в каких-то технологиях, которые используются только на твоём проекте, и, так как загрузка довольно большая, не хватает времени остановиться, отдышаться, посмотреть, что вокруг.
Я однажды так сходила на собеседование и была крайне удивлена – мне казалось, что я прямо супер-спец, но неожиданно узнала о пробелах в своих знаниях. С тех пор я стараюсь гораздо шире смотреть на мир, обязательно сравнивать себя с рынком и задавать себе такие вопросы: «Я развиваюсь и иду туда куда мне хочется и так, как этого ожидает рынок? Мои действия совпадают с моими планами на будущее?»
1) Прояснить ожидания от вас и вашей работы: определить круг полномочий и ответственности, который будет закреплён за вами. Если в проекте до этого не было тестировщика, ожидания могут быть сильно размазаны.
С кем вы можете прояснить эти ожидания? С техлидом или лидом тестирования. Возможно, он есть не в этой команде, а просто где-то в компании. Если у вас есть возможность его привлечь на такие встречи — пользуйтесь этим.
2) Обязательно проговорите, как вы видите процесс тестирования с командой. Команда должна понимать, что вы не можете просто взять, прийти и с первого дня начать приносить какой-то результат.
В целом, абсолютно нормальная ситуация, что скорость всей команды замедляется, когда приходит любой новый человек. Неважно, разработчик, тестировщик, всем нужно время для погружения. Скорость выпуска фич всегда снижается. Классно проговорить с командой какой результат и в какие сроки вы готовы им показать, и выровнять ожидания команды от вас и ваши возможности.
3) Выяснить, к кому с какими вопросами вы можете подойти. Тут я хотела бы обратить внимание, что к вам, как к единственному тестировщику, скорее всего, будет приходить бизнес. И это хорошо! Вам нужно выстраивать коммуникацию с бизнесом. Ваш бизнес может вам рассказать не только про приоритеты, но и про ближайшие цели, дать вам вектор развития продукта, но, самое важное, — он может помочь вам встретиться с конечными пользователями, а это кладезь полезной информации.
4) Закрепить это всё письмами, документами, на которые можно будет опереться в дальнейшем. Бюрократия, письма, артефакты – это лучшие друзья тестировщика. Во-первых, мы все люди, память нас иногда подводит, и бывает сложно вспомнить какие-то договоренности. А во-вторых, к тестировщику, как к последнему звену, всегда приходят со всеми ошибками и вопросами, и здорово, если у вас есть возможность на что-то опереться в этот момент.
Старт в продукте с нуля — это очень классная история. Когда продукт только зарождается, бизнес очень открыто и подробно делится планами, вектором развития, и это всегда помогает команде сфокусироваться на результате. А у нас есть время продумать процессы и документацию, какие артефакты нам бы хотелось сохранять, какими инструментами удобно пользоваться.
Проект с нуля — это, конечно, единорог. У меня было два таких проекта: на первом я еще не поняла все эти фишки, а вот когда перешла в «ХоумБанк» — это был восторг: глаза горели, мы все знали куда мы идём, чего мы хотим. Это было очень драйвово.
Таких плюшек, как время на погружение, как правило, нет в проекте с бэкграундом. Если проекту есть хотя бы год, то в нем уже есть база для изучения, и конечно, погружение в такой проект будет занимать время. Оно уже будет зависеть от размеров самого проекта.
Я всегда начинаю своё погружение в проект с бизнес-требований. Мне важно понимать бизнес-смысл и основные бизнес-процессы. На что обращать внимание при тестировании? С чего вообще начать? Я считаю, что начинать стоит с важных для бизнеса фич.
Если у вас вся логика на сервере, то серверные разработчики должны быть вашими лучшими друзьями. Важно найти с ними общий язык, попросить рассказать вам все, обратить внимание на какие-то важные моменты. После этого можно идти ещё раз в документацию и смотреть — то, что вам рассказали серверные разработчики, оно вообще совпадает с тем, что хотел бизнес или нет? Если нет, то запишите это себе — возможно, когда-то так было, а потом что-то поменялось.
Мне было комфортно такое погружение: я читала документацию, затем ходила с вопросами к разработчикам и аналитикам, и через 2,5 месяца я уже успешно выпустила в прод отдельный продукт — абсолютно новый процесс, в котором были задействованы новые интеграции.
Очень часто я слышу, что в проекте нет никаких процессов, или процессы неправильные, нужно всё снести и построить заново.
Я призываю к тому, чтобы вы не рубили с плеча, не говорили: «Так, все неверно, давайте делать по-другому», а посмотрели и спросили, почему именно так устроены эти процессы?
Когда я пришла в свой последний проект, наши стендапы длились по часу, и мне казалось, что это неправильно, дейлик не может быть таким долгим. А потом я задала вопрос нескольким разработчикам: «Ребят, почему так?». И мне честно сказали, что у команды большая загрузка по встречам в течение дня, очень сложно найти время одновременно у серверных и клиентских разработчиков и аналитиков для обсуждения какой-то проблемы в конкретной задаче, а сразу после дейлика это очень удобно делать, для нашей команды это работает. То есть мы на дейлике собрались, обсудили, и дальше побежали делать, потому что прямо с утра у нас все вопросы снялись.
Таким образом, вот этот «неправильный» процесс стал частью моей жизни, и я не стремлюсь его исправлять, потому что я вижу, что он дает эффект.
Приходя в проект, где нужно выстраивать тестирование, вы наверняка будете опираться на классический «Software Testing Life Cycle»: анализ требований, планирование, разработка тест-кейсов, подготовка тестового окружения и, собственно, выполнение тестов и завершение тестирования.
Но реальность показывает, что мы не всегда можем точно придерживаться этого цикла. Например, вы попадаете в проект, где нет аналитики, где требования, в лучшем случае, описаны в таске. А в худшем случае — требования обсудили на оценке, сделали оценку, теперь, собственно, на это и опираемся. И тут вместо этапа анализа документации нам нужно провести дополнительную аналитику: собрать требования, понять с серверными разработчиками, как они планируют это делать, прояснить, с какими системами потребуется интеграция, если это есть проекте. То есть ещё до этапа планирования тестирования у нас будет отдельный большой этап работы с документацией, который я назвала бы «сбор требований». И это, конечно, абсолютно меняет наш взгляд на задачу.
Случается, что нет тех этапов, которые нужны. Например, у нас нет классического препрода, который соответствует версии прода, он планировался, но сейчас его нет. И да, это не очень удобно, но, с другой стороны, это не аффектит нашу команду от выпуска.
Как я уже говорила, нам очень важно понять, что находится в нашей зоне ответственности и опираться на это. Ограничивайте свою зону ответственности задачами тестирования, и не всегда тестовые среды будут входить в эту историю.
Тут я хочу рассказать свой классный фейл: во времена работы в своем первом проекте с 0 я использовала написанные на коленке чек-листы. И, когда меня определили на проект с банковским приложением, я радостно понесла эту практику туда. А через полгода, когда мы вышли в прод, я поняла, что этого совсем недостаточно.
Дело в том, что когда мы начинали, я чётко помнила какой метод что нам должен возвращать. Через полгода — я не помнила ничего. Я тогда потратила все свои новогодние праздники, чтобы написать хоть какие-то тест-кейсы.
Нам сообщили о планах набрать вторую команду разработки и тестирования на другую функциональность этого приложения. И тут я почувствовала себя очень некомфортно! У меня было ощущение: «придут люди, а дома не прибрано». Придут тестировщики, а тут нет тестовой документации!
Смотрите на свой проект сразу реально. Если вы понимаете, что вектор развития подразумевает что-то масштабное — большую интеграцию, какое-то дальнейшее развитие, то, возможно, стоит сразу заморочиться с подробными тест-кейсами, с обращениями к серверу, с вызовами методов и разбором ответов, или хотя бы интеграций, и артефактами тестирования.
На моем текущем проекте с этим всё строго. У нас периодически пишутся даже видеопротоколы. Почему это важно? Чтобы бизнес видел, как проходит процесс.
Также, у нас по каждому большому процессу пишется памятка для бизнеса, со всеми скриншотами и логами. Я обожаю логи! Они помогают мне вообще во всём: писать моки для интеграционных сервисов, разбираться, что происходило на этапе тестирования, возвращался ли нам параметр, если вдруг в какой-то момент он перестал возвращаться.
Вам нужно подумать, какие артефакты тестирования нужно сохранять, чтобы через полгода зайти в таску, которую вы тестили, и понять, что там вообще происходило.
Это моя любимая тема. Тут я могу разговаривать очень долго, но мы с вами остановимся только на ключевых моментах.
Нужна ли оценка, если в команде тестирование не оценивается?
Есть такие проекты, и это абсолютно ок, если всей команде ок. Но, с точки зрения развития тестировщика, я считаю, что, даже если команда не просит, оценки нужно делать.
Во-первых, наш мозг любит понятные и конечные действия. Если мы понимаем, сколько займет задача, то нам проще на ней сфокусироваться или разделить на такие части, на которых мы сможем сфокусироваться.
И вторая важная история: я не знаю ни одного мидла или сеньора, которому ни разу в жизни не пришлось делать оценку. Рано или поздно вы с этим столкнетесь. Поэтому, если сейчас от вас этого не требуют — делайте это самостоятельно. Так у вас будет определенная аналитика: как часто вы попадаете в свою оценку, какая активность сколько времени у вас занимает.
Как оценивать задачи, если раньше никогда не оценивали?
1) Заведите табличку в Exel
2) Если боитесь белого листа, посмотрите Personal Software process. У них есть таблички с готовыми скриптами.
Часто бывает так, что тестировщику приходят семь задач от семи разработчиков, и возникает вопрос: «Что же делать? Какая самая важная?»
Так вот, приоритизация — это не задача тестировщика. Это задача бизнеса, продакт-оунера, команды, но не тестировщика. Бизнес лучше понимает стратегии и векторы развития продукта, и если у вас не принято приоритизировать задачи — вы должны приучить бизнес к этому.
То есть, вы должны каждый раз приходить и говорить: «Вот у меня есть семь задач, если сделаю вот эти три, то выйдет эта фича, если другие три, то вот эта фича, а если я не сделаю вот эту одну, то не выйдет никакая фича. Понятно, что с вот этой одной я начну, но какие задачи мне брать следующими, что важнее?».
Работа никогда не закончится, ребята. Теперь вы одни не только у себя, но и у своей команды.
О себе нужно заботиться. В какой-то момент я забывала об этом, и у меня были двенадцатичасовые рабочие дни. Иногда я вставала в 4-5 утра, потому что нужно было протестировать функциональность, и заканчивала в 7-8 вечера. Это неплохо, такие переработки бывают обоснованы. Но в какой-то момент я поняла, что больше не люблю свою работу. Я не хочу идти в офис, а необходимость возвращаться в проект после отпуска вызывает у меня дрожь.
И тогда в моей жизни появился спорт. Я хожу в тренажерный зал три раза в неделю, вместо обеда или вечером, но обязательно три раза. Для меня это важно. Это очень сильно поменяло моё отношение к своему телу, у меня перестала болеть спина, и я поняла, что, в общем-то, есть жизнь за пределами работы.
Прогулки. Прогулки помогают мне справляться с переизбытком информации. Если у меня был стрессовый день — я обязательно одеваюсь и иду с квадратными глазами, ничего не видя, просто иду, и через час-полтора меня отпускает. У нас есть несколько путей вывода кортизола из организма, один из них — поплакать, другой — спорт, физическая активность, прогулки.
Хобби, не связанные с работой. Я обожаю читать книги, готовить, путешествовать, открывать для себя какие-то новые места, я получила сертификат Open Water Divers. Это то, что не связывает меня с работой.
Во всё остальное время я снова люблю свою работу. Берегите себя от выгорания, сейчас об этом очень много информации. А когда вы работаете единственным тестировщиком — вы единственный не только у себя, но и у команды. Команда на вас рассчитывает. И ходите в отпуск обязательно, не забывайте об этом.
Автор: Валерия, Senior QA Engineer DexSys