Да, это канал про software тестирование.
🥇 Extra virgin, самый первый, самый жидкий, не бодяжный.
Подписывайтесь, отключайте уведомления.
🥇 Extra virgin, самый первый, самый жидкий, не бодяжный.
Подписывайтесь, отключайте уведомления.
Так случается, что иногда приходится сменить работу. Причин масса: либо ты всех запарил, либо сам запарился. Как говорится «одно из трёх: либо да, либо нет». У меня на прошлой работе закончились контракты и закончились деньги. Это были гос. тендеры. Та ещё жопа. Поэтому я решил кардинально сменить работу и ворваться в IT. Но как?
Собрал друзей айтишников в баре и давай мы брэйнштормить как нам меня в IT затолкать. Табличку составили с варинтами, плюсами, минусами. Короче, выбрали тестирование. Мол, нудный я и порядок люблю. За порядок и двор – стреляю в упор.
Потом полгода я готовился к собеседованиям. Курсы, вебинары посещал. Книжки читал. Старался очень сильно, уставал.
Три-четыре провальных собеседования и вот, мне повезло! Меня пригласили в неплохую компанию на неплохую зарпалту. ееее рокккккккк 🔥
Прошел год, я поднабрался опыта и решил завести этот телеграм канал чтобы делиться с вами годнотой и, конечно, бугуртить от заказчиков и их «ну это же подразумевается».
Собрал друзей айтишников в баре и давай мы брэйнштормить как нам меня в IT затолкать. Табличку составили с варинтами, плюсами, минусами. Короче, выбрали тестирование. Мол, нудный я и порядок люблю. За порядок и двор – стреляю в упор.
Потом полгода я готовился к собеседованиям. Курсы, вебинары посещал. Книжки читал. Старался очень сильно, уставал.
Три-четыре провальных собеседования и вот, мне повезло! Меня пригласили в неплохую компанию на неплохую зарпалту. ееее рокккккккк 🔥
Прошел год, я поднабрался опыта и решил завести этот телеграм канал чтобы делиться с вами годнотой и, конечно, бугуртить от заказчиков и их «ну это же подразумевается».
Зачем мне этот канал? Во-первых, это интересно мне. Во-вторых, вдруг, этот канал реально кому-то будет полезен. Опять же хотя бы мне.
Может, я пока буду писать про какую-нибудь тему и сам в ней разберусь. Звучит как план.
Может, я пока буду писать про какую-нибудь тему и сам в ней разберусь. Звучит как план.
Как я вообще готовился к тому чтобы стать тестировщиком.
За 10 месяцев до того как послать первую резюмешку, я решил основательно подготовиться и понять что это за профессия такая тестировщик. Начал гуглить какие существуют платформы удаленного образования. Нашел много: codeacademy, coursera, sololearn, universarium, lectorium, netology. Каждую внимательно просмотрел сколько они стоят и вообще есть ли там что-то про тестирование. Начать решил с вот этого https://universarium.org/course/715 Мне он показался интересным и годным для новчиков. Могу ли я его порекомендовать? Да. Он бесплатный и довольно широко рассказывает о том, в чем вообще заключается работа тестировщика. Плюс там есть домашние задания. Я всё прилежно выполнял и набрал максимальный балл.
Параллельно с прохождением курса я подписался на все дурацкие рассылки, которые только нашел и читал абсолютно всё, что находил в рунете по тестированию. Ничего не понимал конечно, но читал много и часто. Так я стал привакать и к глоссарию, и увидил типичные проблемы, и лучше понял как выглядит обычный будний день тестиовщика.
Кроме ежедневного чтения всяких ресурсов типа software-testing и habrahabr я скачал и пролистал книжки Роман Савин - Тестирование .COM и Канер - Тестирование программного обеспечения. По-моему, это неактуальные и спорные книжки. Мне не нравится идея: "Чем больше багов нашел, тем ты лучше". Херня какая-то. Но бегло прочитать их всё-такие надо, потому что на русском языке очень мало информации по тестированию. Приходится читать что есть.
И, наверное, последнее что я могу вспомнить про свою подготовку – это материалы про собеседования. Вот ссылка, по которой я готовился как по check-листу https://habrahabr.ru/post/254209/ Там тоже не все вопросы мне кажутся адекватными, но других нет, так что проработать хотя бы их однозначно стоит. Собеседования это капец какой стресс. Серьезно, я очень сильно переживал до, вовремя и после собесдования. Ну, потому что я понимаю, что впариваю работодателю себя с нулевым опытом. Раз опыта у меня нет, то остаётся только делать акцент на soft skills. Если вы живете не в лесу, то вам стоит погуглить что это такое и заняться этим.
За 10 месяцев до того как послать первую резюмешку, я решил основательно подготовиться и понять что это за профессия такая тестировщик. Начал гуглить какие существуют платформы удаленного образования. Нашел много: codeacademy, coursera, sololearn, universarium, lectorium, netology. Каждую внимательно просмотрел сколько они стоят и вообще есть ли там что-то про тестирование. Начать решил с вот этого https://universarium.org/course/715 Мне он показался интересным и годным для новчиков. Могу ли я его порекомендовать? Да. Он бесплатный и довольно широко рассказывает о том, в чем вообще заключается работа тестировщика. Плюс там есть домашние задания. Я всё прилежно выполнял и набрал максимальный балл.
Параллельно с прохождением курса я подписался на все дурацкие рассылки, которые только нашел и читал абсолютно всё, что находил в рунете по тестированию. Ничего не понимал конечно, но читал много и часто. Так я стал привакать и к глоссарию, и увидил типичные проблемы, и лучше понял как выглядит обычный будний день тестиовщика.
Кроме ежедневного чтения всяких ресурсов типа software-testing и habrahabr я скачал и пролистал книжки Роман Савин - Тестирование .COM и Канер - Тестирование программного обеспечения. По-моему, это неактуальные и спорные книжки. Мне не нравится идея: "Чем больше багов нашел, тем ты лучше". Херня какая-то. Но бегло прочитать их всё-такие надо, потому что на русском языке очень мало информации по тестированию. Приходится читать что есть.
И, наверное, последнее что я могу вспомнить про свою подготовку – это материалы про собеседования. Вот ссылка, по которой я готовился как по check-листу https://habrahabr.ru/post/254209/ Там тоже не все вопросы мне кажутся адекватными, но других нет, так что проработать хотя бы их однозначно стоит. Собеседования это капец какой стресс. Серьезно, я очень сильно переживал до, вовремя и после собесдования. Ну, потому что я понимаю, что впариваю работодателю себя с нулевым опытом. Раз опыта у меня нет, то остаётся только делать акцент на soft skills. Если вы живете не в лесу, то вам стоит погуглить что это такое и заняться этим.
В самом начале карьеры тестировщика я сталкнулся с тем, что не смог найти нормального примера оформления баг-репорта. Почти все советы в интернете на столько общие и размытые, что толку от них никакого. Пришлось потратить дофига своего времени на тупую работу – просмотреть все эти рекомендации и шаблоны чтобы отжать "воду" и собрать свой шаблон баг-репорта.
Итак, баг-репорт – это запись о найденом дефекте в программе. Вещь очень нужная для всех: разработчикам понятно что не так с приложухой, а мне баг-репорт нужен чтобы через неделю я смог вспомнить что тут вообще происходило. Для менеджеров на первый взгляд баг-репорты не важны, но это не так. Они им тоже нужны чтобы владеть информацией об актуальном качестве продукта и дальше менеджерить исходя из этих данных.
Перечислю поля, которые сам считаю важными.
• ID – номер бага в вашем баг-трекере. Почти везеде (JIRA, RedMine, YouTrack) он присваивается автоматически при создании любой новой задачи в трекере;
• Автор – имя того, кто багу завёл (=нашел). Тоже присвается автоматом;
• Дата – имя поля говорит само за себя;
• Название проекта – название проекта, в котором эта бага обнаружена. Тоже присвается автоматом;
• Версия билда. Почти наверняка вы разрабатваете спринтами. И что бы точно знать имя билда где этот баг 100% присутствует надо это поле заполнить.
• Описание. В этом поле надо подробно по шагам описать сценарий воспроизведения бага. Уделите этому пункту своё внимание. Когда проект большой или у вас несколько проектов, то вы точно забудете что это за баг вообще и как его воспроизводить тем более. То что записано уже не забудется.
• Ожидаемый результат и Фактический результат. Думаю, тут понятно что нужно писать в каждом из полей. Не ленитесь описывать эти поля. Потому что требования могут изменяться и вам в будущем будет проще доказывать свою правоту перед коллегами, когда у вас будет такой аргумент.
Дальше я выделил необязательные поля, но каждое из них может быть очень нужно для какой-то конкретной баги или даже проекта целиком:
• Тестовая среда. Напрмер, название браузера или его версии, название почтового клиента, разрешение экрана, модель ОС или название БД к которой вы цепляетесь;
• Приоритет. То на сколько заказчику важен функционал, в котором есть эта бага.
• Критичность. То на сколько рушит эта бага ваше приложение. Не путайте приоритет и критичность.
• И последнее: скриншоты и видео-пруфы.
Итак, баг-репорт – это запись о найденом дефекте в программе. Вещь очень нужная для всех: разработчикам понятно что не так с приложухой, а мне баг-репорт нужен чтобы через неделю я смог вспомнить что тут вообще происходило. Для менеджеров на первый взгляд баг-репорты не важны, но это не так. Они им тоже нужны чтобы владеть информацией об актуальном качестве продукта и дальше менеджерить исходя из этих данных.
Перечислю поля, которые сам считаю важными.
• ID – номер бага в вашем баг-трекере. Почти везеде (JIRA, RedMine, YouTrack) он присваивается автоматически при создании любой новой задачи в трекере;
• Автор – имя того, кто багу завёл (=нашел). Тоже присвается автоматом;
• Дата – имя поля говорит само за себя;
• Название проекта – название проекта, в котором эта бага обнаружена. Тоже присвается автоматом;
• Версия билда. Почти наверняка вы разрабатваете спринтами. И что бы точно знать имя билда где этот баг 100% присутствует надо это поле заполнить.
• Описание. В этом поле надо подробно по шагам описать сценарий воспроизведения бага. Уделите этому пункту своё внимание. Когда проект большой или у вас несколько проектов, то вы точно забудете что это за баг вообще и как его воспроизводить тем более. То что записано уже не забудется.
• Ожидаемый результат и Фактический результат. Думаю, тут понятно что нужно писать в каждом из полей. Не ленитесь описывать эти поля. Потому что требования могут изменяться и вам в будущем будет проще доказывать свою правоту перед коллегами, когда у вас будет такой аргумент.
Дальше я выделил необязательные поля, но каждое из них может быть очень нужно для какой-то конкретной баги или даже проекта целиком:
• Тестовая среда. Напрмер, название браузера или его версии, название почтового клиента, разрешение экрана, модель ОС или название БД к которой вы цепляетесь;
• Приоритет. То на сколько заказчику важен функционал, в котором есть эта бага.
• Критичность. То на сколько рушит эта бага ваше приложение. Не путайте приоритет и критичность.
• И последнее: скриншоты и видео-пруфы.
И ещё небольшой чек-лист по оформлению багов, который я выработал для себя за время работы:
1) воспроизвожу найденную багу дважды, а не один раз
2) перед тем как завести багу в баг-трекере ищу дубликаты
3) воспроизведение баги в соседних билдах (и релизе, если такой есть)
4) пишу сценарий и попутно его воспроизвожу полностью отключив мозг. То есть делаю только то, что написано
5) сделал скриншоты
6) заполнил в баг-трекере поля: автор, ответственный, версия билда, дата обнаружения, приоритет, критичность
7) ПИШУ ЛАКОНИЧНОЕ НАЗВАНИЕ БАГА. Да, это лучше делать в самом конце. Когда уже сам хорошо понимаешь природу бага и его место.
1) воспроизвожу найденную багу дважды, а не один раз
2) перед тем как завести багу в баг-трекере ищу дубликаты
3) воспроизведение баги в соседних билдах (и релизе, если такой есть)
4) пишу сценарий и попутно его воспроизвожу полностью отключив мозг. То есть делаю только то, что написано
5) сделал скриншоты
6) заполнил в баг-трекере поля: автор, ответственный, версия билда, дата обнаружения, приоритет, критичность
7) ПИШУ ЛАКОНИЧНОЕ НАЗВАНИЕ БАГА. Да, это лучше делать в самом конце. Когда уже сам хорошо понимаешь природу бага и его место.
Как уже говорил, я пришел в тестирования совершенно без опыта. Понимания о том какова роль тестирования в жизненном цикле разработки у меня не было. Стал гуглить. Довольно легко нагуглить информацию про жизненный цикл разработки ПО, но почти ничего внятного нет про жизненный цикл тестирования ПО. Так что пришлось как-то самостоятельно выработать эти этапы.
Не знаю, правильно это или нет, но я постарался привязаться к самой распространенной модели жц разработки:
1. Анализ требований
2. Дизайн
3. Разработка
4. Тестирование
5. Эксплуатация
И к каждому этапу я, можно сказать, прилепил своё тестирование руководствуясь девизом: чем раньше начать тестирование, тем лучше.
Этап 1. Анализ требований. Надо врываться в этот этап чтобы понимать функциональные и нефункциональные требования. Общайтесь с заказчиком чтобы понимать ожидания заказчика.
Этап 2. Дизайн. На этом этапе появляются кой-какие прототипы. Тестируйте их, смотрите на ожидания заказчика и то, как он реагирует. Ближе к концу, но всё ещё в рамках этого этапа стоит начать накидывать тестовую документацию. Мне кажется, этот этап вообще самый важный. Ведь чем больше вы сейчас поработаете, тем меньше потом будете париться и с багами, и с несбывшимися ожиданиями заказчика. И вообще определитесь какова ваша цель в этом проекте.
Этап 3. Разработка. Тут всё более-менее понятно: модульное тестирование, интеграционное и затем системное.
Этап 4. Тестирование. Это основная наша работа – тестируем всё: регрессионное, функциональное тестирование, тестирование UI/UX. Сложность этого этапа в том, что для нас этот этап считается последним, то есть после него мы уже не сможем ничего менять и цена пропущенных багов может быть огромной. Не сложный этап, но большой и ответственный.
Этап 5. Эксплуатация. Всё, продукт в продекшене. Системой пользуются настоящие человеки. Тут тебе и огромное количество среды эксплуатации и использование продукта не по назанчению. Здесь возможно всякое и прилетающие нам баги будут очень болезненно восприниматься заказчиком. Постарайтесь это держать в голове и, может, как-то более внимательно разговаривать с заказчиком. Ну и баги, само собой, срочно надо фиксить на этом этапе.
Вот и получается, что жц тестирования неотделим от каждого этапа разработки.
Не знаю, правильно это или нет, но я постарался привязаться к самой распространенной модели жц разработки:
1. Анализ требований
2. Дизайн
3. Разработка
4. Тестирование
5. Эксплуатация
И к каждому этапу я, можно сказать, прилепил своё тестирование руководствуясь девизом: чем раньше начать тестирование, тем лучше.
Этап 1. Анализ требований. Надо врываться в этот этап чтобы понимать функциональные и нефункциональные требования. Общайтесь с заказчиком чтобы понимать ожидания заказчика.
Этап 2. Дизайн. На этом этапе появляются кой-какие прототипы. Тестируйте их, смотрите на ожидания заказчика и то, как он реагирует. Ближе к концу, но всё ещё в рамках этого этапа стоит начать накидывать тестовую документацию. Мне кажется, этот этап вообще самый важный. Ведь чем больше вы сейчас поработаете, тем меньше потом будете париться и с багами, и с несбывшимися ожиданиями заказчика. И вообще определитесь какова ваша цель в этом проекте.
Этап 3. Разработка. Тут всё более-менее понятно: модульное тестирование, интеграционное и затем системное.
Этап 4. Тестирование. Это основная наша работа – тестируем всё: регрессионное, функциональное тестирование, тестирование UI/UX. Сложность этого этапа в том, что для нас этот этап считается последним, то есть после него мы уже не сможем ничего менять и цена пропущенных багов может быть огромной. Не сложный этап, но большой и ответственный.
Этап 5. Эксплуатация. Всё, продукт в продекшене. Системой пользуются настоящие человеки. Тут тебе и огромное количество среды эксплуатации и использование продукта не по назанчению. Здесь возможно всякое и прилетающие нам баги будут очень болезненно восприниматься заказчиком. Постарайтесь это держать в голове и, может, как-то более внимательно разговаривать с заказчиком. Ну и баги, само собой, срочно надо фиксить на этом этапе.
Вот и получается, что жц тестирования неотделим от каждого этапа разработки.
Сети – это скучно. Даже разработчики особо не вникают как работает сеть, воспринимая её как существующий факт. Конечно, разработчики понимают важнейшие основы: что есть роутер, зачем DNS, VPN, стек TCP/IP, в чем суть UDP, как работает NAT и т.д.
Может, кто-то начнёт пердеть с моего мнения, но нам, тестировщикам, стоит не меньше разработчиков понимать как работает сеть. Не знание основ работы сети вредно для карьеры любого уважающего себя инженера IT.
Можно привести несколько примеров когда знания сетей пригодится тестировщику, но, думаю, вы сами понимаете на сколько это важно на сегодняшний день в нашей работе.
Итак, мне надо научиться в сети. Что делать? Ну ессно гуглить и читать всякое тематическое. Материала даже на русском хоть попой ешь.
Но не было бы этого поста, если бы у меня для вас не было кой-чего годного
🔥 это самая годная серия статей про сети, из всего что я нашел в рунете. Серьезно. Хотя бы по диагноли, но прочитайте и добавьте в закладки. Сначала нихрена не понятно (потом тоже), но прочитайте.
https://habrahabr.ru/post/134892/
Может, кто-то начнёт пердеть с моего мнения, но нам, тестировщикам, стоит не меньше разработчиков понимать как работает сеть. Не знание основ работы сети вредно для карьеры любого уважающего себя инженера IT.
Можно привести несколько примеров когда знания сетей пригодится тестировщику, но, думаю, вы сами понимаете на сколько это важно на сегодняшний день в нашей работе.
Итак, мне надо научиться в сети. Что делать? Ну ессно гуглить и читать всякое тематическое. Материала даже на русском хоть попой ешь.
Но не было бы этого поста, если бы у меня для вас не было кой-чего годного
🔥 это самая годная серия статей про сети, из всего что я нашел в рунете. Серьезно. Хотя бы по диагноли, но прочитайте и добавьте в закладки. Сначала нихрена не понятно (потом тоже), но прочитайте.
https://habrahabr.ru/post/134892/
Есть ещё мощнейшая книга В. Олифер Н. Олифер. «Компьютерные сети. Принципы, технологии, протоколы». Но она уже для тех, кому нужно нормально так разобраться, а не по верхам пройтись. Скажу честно, из-за отсутствия конкретной задачи, у меня не хватило мотивации дочитать её до конца. Я сдулся где-то на 1/3.
Тут подвезли довольно крупное аналитическое исследование рынка тестирования ПО в России.
Цитата: Компания Перфоманс Лаб представляет второй выпуск Russia Quality Report. На сегодняшний день это единственное аналитическое исследование индустрии тестирования программного обеспечения в различных сегментах рынка Российской Федерации. В ходе исследования было опрошено 360 респондентов уровня ИТ-директоров и Руководителей отделов тестирования. Были выявлены основные изменения, которые прошли в отрасли за последние два года. Найдено множество интересных инсайтов. Отчет рекомендуется для широкой аудитории ИТ-специалистов, заинтересованных в повышении качества программных продуктов.
Ключевые выводы:
• QA специалисты осваивают новые компетенции
• Agile на пике популярности, однако, есть сложности
• Количество центров компетенций по тестированию растёт
• Банковский сектор — лидер отрасли
• Государственный сектор не спешит проводить импортозамещение в области инструментария тестирования
Цитата: Компания Перфоманс Лаб представляет второй выпуск Russia Quality Report. На сегодняшний день это единственное аналитическое исследование индустрии тестирования программного обеспечения в различных сегментах рынка Российской Федерации. В ходе исследования было опрошено 360 респондентов уровня ИТ-директоров и Руководителей отделов тестирования. Были выявлены основные изменения, которые прошли в отрасли за последние два года. Найдено множество интересных инсайтов. Отчет рекомендуется для широкой аудитории ИТ-специалистов, заинтересованных в повышении качества программных продуктов.
Ключевые выводы:
• QA специалисты осваивают новые компетенции
• Agile на пике популярности, однако, есть сложности
• Количество центров компетенций по тестированию растёт
• Банковский сектор — лидер отрасли
• Государственный сектор не спешит проводить импортозамещение в области инструментария тестирования