Необходимо войти или зарегистрироваться

Авторизация

Введите логин, email или номер телефона, начинающийся с символа «+»
Забыли пароль? Регистрация

Новый пароль

Авторизация

Восстановление пароля

Авторизация

Регистрация

Выберите, пожалуйста, ник на пикабу
Номер будет виден только вам.
Отправка смс бесплатна
У меня уже есть аккаунт с ником Отменить привязку?

Регистрация

Номер будет виден только вам.
Отправка смс бесплатна
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
Авторизация

Сообщество

Сообщество

Сообщество - Лига тестировщиков

Лига тестировщиков

25 постов 636 подписчиков
Полная информация
Правила сообщества

"Авторка", "блогиня", "йогиня" - новые феминитивы в интернет-пространстве.

shiko.kate в Лига тестировщиков

Здравствуйте, дорогие друзья!


Я - студенка филологического факультета МГУ и произвожу исследование об образовании феминитивов в современном Интернет-пространстве, а также о том, как на эти слова реагирует общество.


Прошу уделить несколько минут Вашего драгоценного времени и пройти данный опрос - это очень поможет в моей работе. Каждый человек - на вес золота)) +100 к карме обязательно


Спасибо!

https://ru.surveymonkey.com/r/MW96DVB

"Авторка", "блогиня", "йогиня" - новые феминитивы в интернет-пространстве. Мини-Опрос, Простой опрос, Интернет, Русский язык, Тестирование, Феминизм, Феминитивы, Мужской феминизм

Как стать тестировщиком или каких знаний мы ждём от джуниора

QAtester в Лига тестировщиков

Пара вводных слов

Всем доброго времени суток, меня зовут Туманов Дима. Сейчас я работаю в компании Rambler&Co и отвечаю за тестирование на проектах Афиши. В рамках данной статьи я развею несколько мифов об IT и тестировании в частности. Кроме того, приведу примеры из жизни как “не зная ничего” стать Junior QA Engineer в крупной компании.



Начало пути


Проработав почти два года в одной “мирной” госкорпорации в должности “ненастоящего инженера”, я осознал, что развитие остановилось. Я мог сидеть на одном месте и почти ничего не делать. В конечном итоге мои знания бы совсем отстали от реальной действительности и я бы стал невостребованным на рынке. В этот момент я принял решение о смене места и сути своей работы.



Вопрос №1 — “Какую область для работы выбрать”


Мой выбор основывался на нескольких фактах. Во-первых я хотел работать в быстро развивающейся отрасли. В этом я видел и вижу сейчас возможность постоянно расти в профессии, развивая себя в различных направлениях. Во-вторых я хотел уйти от бюрократии, жёстких регламентов и обязательного ношения костюмов жарким летом. Ну и последнее, но не по значению, я хотел делать действительно важное дело, ощущать близость конечного пользователя, понимать, что моя работа действительно нужна. Все три этих пункта я смог увидеть в IT-отрасли.



Вопрос №2 — “Какую профессию выбрать”


Для меня важным было некое совмещение гуманитарных и технических наук, то есть коммуникаций и инженерии. С одной стороны я не хотел быть только техническим специалистом и например писать лучший код на Java. С другой я хотел понимать как всё устроено изнутри. По этим причинам мой выбор пал на тестирование. Дополнительно к смежности профессии, описанной выше, в тестирование довольно просто попасть. Порог входа действительно небольшой.



Вопрос №3 — “Какую компанию выбрать”


По сути все компании можно классифицировать несколькими способами. Во-первых по отношению заказчик-разработчик. Есть принципиальная разница между компаниями аутсорсерами и продуктовыми компаниями. Для первых самым важным является продажа продукта. Да, есть имя компании, отзывы клиентов, но так или иначе заработок идёт от прямых продаж. Для вторых важным является иметь качественный и популярный продукт. На таком продукте можно разместить дорогую рекламу и заработать много денег. Поэтому с точки зрения тестирования сильная команда будет сформирована именно в продуктовой компании. Во-вторых компании стоит разделять на русские и импортные. На текущий момент тестирование остаётся слабо развитым направлением в России. Это даёт свои плюсы и оставляет возможность занять своё место под солнцем без сильных проблем. Но, с другой стороны, сужает выбор достойных мест для работы. Благо в крупных интернет компаниях рунета уже “пройден этап варварства и созданы первые государства”. Для меня было важно работать именно в русской компании. Это что-то вроде “странного” патриотизма, если хотите. Исходя из всего этого мой выбор пал на крупные продуктовые интернет компании России. Таких кстати совсем немного и вы легко можете найти их рейтинг в Forbes (2014, 2015, 2016).



Вопрос №4 — “Как решить проблему отсутствия опыта”


Парадокс подавляющего числа компаний заключается в необходимости опыта даже для начальных предложений. Ответ на вопрос как они вообще себе такое представляют я не нашёл до сих пор. Благо в неразберихе рождается всё новое и многие построили бизнесы на этой истории. Сеть сейчас кишит различными обучениями с практикой, среди которых есть действительно стоящие. С остальными знаниями, которые нужно приобрести, вроде без эксцессов, поэтому давайте обо всём по порядку.



Вопрос №5 — “Какие знания нужно получить и как это сделать”



Погружение в теорию тестирования. В первую очередь нужно научиться говорить на языке IT и тестирования в частности. Для этого необходимо разобраться с тем, что такое обеспечение качества и с основными понятиями из тестирования ПО. Данные материалы можно раскопать почти в любой книге по тестированию, но я ярый противник “технических” талмудов и считаю их медленным источником информации. Намного проще и быстрее это сделать из отдельных статей:


Что такое обеспечение качества


Что такое тестирование


Какие виды тестирования бывают


Какие уровни тестирования бывают


Какие тестовые артефакты есть и зачем их используют


Что такое тест дизайн


Как должен выглядеть процесс тестирования в вакууме


Что такое автоматизация тестирования и её основные виды


Какие метрики тестирования бывают и зачем они используются


Изучение Bug Tracking систем. Ключевым навыком инженера по тестированию является поиск, локализация и качественное заведение дефекта. Баг не существует в вакууме, он чётко связан с разделом программы, воспроизводится на списке конфигураций (операционная система и её версия, браузер и его версия), имеет свой приоритет. Более того работу над исправлением дефекта проводят несколько разных специалистов. Для того чтобы сделать процесс управления починки дефекта управляемым используют специальные системы. Здесь есть иллюзия выбора. Есть широко распространённый Redmine. Но если вы нацелены на работу в компании, указанного выше класса, то вам стоит изучать Jira. Для этого рекомендую сделать следующее:


Поставить себе пробную версию продукта и пройти эти ролики


Поставить себе и изучить базовые гаджеты: 1, 2, 3


Изучение Test Management систем. Любой софт — это по сути набор возможностей, то есть так или иначе конечное множество. При этом логика работы каждой из них не является идеальной моделью, а значит количество багов в системе всегда бесконечно. Вопрос в том что мы считаем багом, а что нет. Тут на помощь нам приходят требования от заказчика, описывающие то каким должен быть наш продукт. В качестве требований не обязательно должно быть техническое задание на тысячу страниц. Это также может быть прототип или постоянное живое обсуждение, если ваш продукт это просто новая доработка. Для перевода требований в набор проверок существуют методы из теории тестирования, которые вы уже должны были изучить выше. Но тесты, как и дефекты не существуют в вакууме и над одним функционалом может одновременно работать несколько специалистов по тестированию. По аналогии для управления процессом написания и применения тестов используют специальные системы. Лихие 90-е ушли и работа в “эксельках”, “блокнотиках” и “тестлинках” уже не является нормальным явлением. Недавно я проводил аудит по поиску подходящей системы. В основном они либо ничего не делают, либо стоят как космолёт. Золотой серединой является TestRail. Для его изучения нужно сделать следующее:


Поставить себе пробную версию и пройти эти ролики


Поднятие технического бэкграунда. Мы занимаемся web и mobile приложениями, поэтому рассуждение пойдёт в этом ключе. Настоящий тестировщик обязан понимать “начинку” того, что он проверяет. Это экономит время команды, так как специалист по тестированию сам может определить истинную причину дефекта и описать её правильно. Да и тестировать то, о чём ты ничего не знаешь как минимум странно. Плюс глубокое понимание улучшает ваши коммуникации с другими техническими специалистами. Для старта хватит этих общих знаний:


Как устроен интернет


Что такое backend и frontend


Что такое http запрос


Как работать с консолью браузера


Изучение программирования. Извечный вопрос нужно ли уметь программировать тестировщику имеет очень простой ответ. Нужно. Связано это с тем самым техническим бэкграундом во-первых и с развитием аналитичности вашего мышления во-вторых. На начальном этапе достаточно иметь базовые представления о программировании, в будущем для качественного роста вам потребуется изучить один из популярных языков. Например, Python или Java. На старте стоит изучить следующее:


Самые базовые знания по программированию


Основные языки программирования


Основные термины в программировании


Преодоление преграды отсутствия опыта. В IT-отрасли сейчас сильная нехватка кадров, в частности тестировщиков, поэтому часто берут перспективных кандидатов без опыта. Действительно, проще научить с нуля, чем переучивать. Для того, чтобы стать более востребованным по сравнению с другими стоит пройти специализированные курсы по тестированию. На них можно получить структурированные знания и самое главное опыт реального тестирования. Я рекомендую пройти курс “Школа успешных тестировщиков, v 2.0)” с этого портала


Поиск работы. Дальше остаётся только составить резюме, учитывая обновлённые знания и навыки, и научиться грамотно использовать hh



Перспективы развития


Работа занимает треть нашей жизни. Если отбросить сон, то это вообще половина нашего времени. Единственно правильным считаю работать там и делать то, что действительно нравится. Помимо морального удовлетворения есть и материальные блага. Уровень зарплат по официальным источникам даже на старте превышает среднюю температуру по больнице. Наличие ДМС, скидки на фитнес или наличие зала внутри компании, бесплатные билеты на различные мероприятия и прочие бонусы конечно же присутствуют. К тому же работа оценивается по количеству сделанной работы, а никак не по проведённому на ней времени. В IT всегда гибкий график и “опоздание на 15 минут” никак не будет наказываться. Более того, на это даже никто не обратит внимание, потому что это действительно нормально. Роль тестировщика — это не окончание вашего движения, это лишь точка входа. После пары лет хорошей практики в тестировании вы сможете выбрать любой путь развития в компании.



Почему я уверен в вашем успехе


Как когда-то сказал Стив Джобс: “Нельзя соединить точки жизненного пути, смотря вперёд. Их можно соединить, только оглядываясь в прошлое”. Именно этот принцип и даёт мне уверенность в том, что стать тестировщиком и начать получать удовлетворение от работы может абсолютно каждый. Есть и другие примеры за последние несколько лет, которые только подтверждают доступность данной профессии. У меня был некий Challenge Accepted. В какой-то момент ко мне почти одновременно обратилось два человека, которых я очень хорошо знал. Один из них на тот момент работал в правоохранительных органах, другой был профессиональный военным. Схожесть ситуации была на лицо. Они большие молодцы и с большой настойчивостью проходили примерно описанный выше план. Такое самообучение и поиск самой работы у них заняло порядка трёх-четырёх месяцев. Сейчас они работают тестировщиками, имеют перспективы для развития, гибкий график и думаю много чего в их жизнях ещё изменилось.



Post Scriptum


Ещё раз подчеркну. Войти в данную профессию не сложно. Это сможет каждый. Дальнейшее развитие в IT зависит уже только от вас.



скопипащено отсюдо: https://habrahabr.ru/company/rambler-co/blog/303254/

Показать полностью

Все поздравляют дизайнеров, а про QA забыли

Andelor в Лига тестировщиков
Все поздравляют дизайнеров, а про QA забыли QA, Тестировщики, День тестировщика

День тестировщика — профессиональный день тестировщиков, отмечаемый 9 сентября.


9 сентября 1947 года[1][2] учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле, и Грейс Хоппер произнесла слово «bug» (англ. «жук»), ставшее позднее термином, обозначающим компьютерную ошибку. Извлечённое насекомое было вклеено в технический дневник с сопроводительной надписью: «First actual case of bug being found» (англ. «первый случай в практике, когда был обнаружен жучок»). Этот забавный факт положил начало использованию слова «баг» в значении «ошибка». В итоге процесс выявления и устранения причин сбоя в работе компьютера получил название debugging (дебаггинг, «отладка», дословно: избавление от жуков). А само название профессии возникло от английского слова test, то есть испытание.

Показать полностью

Пол года в тестировании или взгляд с колоколенки

ozzyatekraken в Лига тестировщиков

Почти год назад я спрашивал мнения у вас, ребята, по поводу профессии тестировщика. Было много дельных советов, и не очень, но все они были полезны в коей-то мере. И вот, я уже ровно 7 месяцев как тестировщик. Возможно, что кому-то будет полезен пост. Вероятно, что именно ты задумываешься о том, чтобы начать строить карьеру в тестировании, но пока обременён другими заботами. Я постараюсь максимально простым языком поделиться своим скромным опытом, и возможно, повлиять на твоё решение в вопросе "хочу ли я быть тестировщиком?".В общем, заваривай чайку, хватай печенюги и усаживайся поудобнее. А я беру бокал креплёного и начинаю.

Преамбула.

Войти в Ай-Ти или хлопоты "входа"

Немного цифр. После окончания универа по профилю "Энергетика" я уже окончательно для себя решил, что хочу быть тестировщиком. У меня всегда была тяга к тому, чтобы всё, чем я пользуюсь было идеальным + большое увлечение компами и еже с ними. Небольшой опыт кодинга (говно-кодинга) в конце 10-11 класса школы и первых курсов универа, но со временем всё забылось. После получения заветной корочки и месяца беспросветных кутежей, я составил резюме и начал шерстить вакансии на хх. И вот, первый отклик. Мне выслали тестовое задание, с ним я к сожалению не справился. Как говорится, первый блин комом. Затем почти один за одним были еще 3 ответа к моим откликам. Каждая компания высылала тестовое задание, которые я уже успешно выполнил и впереди у меня состоялись 3 первых в моей жизни собеседования. Первые два я успешно провалил, а на третьем, уже имея некоторый опыт в общении с HR и тестировщиками, успешно его прошел. Спустя приблизительно неделю в один жаркий летний день мне позвонили и сообщили, что с 1 сентября я выхожу на работу. Это была моя маленькая победа. К слову, я даже рад, что в предыдущие места меня не взяли, но об этом дальше.

Ах да, цифры, подытожим - 4 отклика, 4 тестовых задания, 3 собеседования, 1 успешное, затраченное время около 3 недель.

Испытательный срок или оклад за обучение

После оффера (успешного прохождения собеседования и приглашения на работу) я начал усиленно готовиться, читал блоги, смотрел видео, впитывал и вкушал опыт других, бывалых тестировщиков. Первые два месяца я приходил на работу и изучал документацию по продукту, который мне предстояло тестировать, смотрел видео-уроки (записывали их тестировщики из компании). Очень круто, что для лёгкого входа новичков был весь необходимый материал, это очень помогло. В течение месяца я каждый день изучал новое, а два раза в неделю общался с менеджером разработки (член команды, который ставит задачи, общается с заказчиками и вообще, занимается многими организационными вопросами + защищает нас от других команд, которые хотят скинуть свои косяки на нас), рассказывал ему, что нового узнал, отвечал на его вопросы. Честно, я ощущал себя идиотом, который нифига не понимал, но очень хотел и старался вникнуть в процесс. Какие-то непонятные названия, странные слова Agile, Scrum, МР, ПМ, Тим-лид и прочие, уже кажутся такими простыми и примитивными, но тогда, будучи совсем зелёным, я их до конца не мог сложить воедино. Первые три месяца пролетели быстро, но их я запомню на всю жизнь - это самое болезненное время, когда много, просто невероятно МНОГО информации, которую нужно усвоить и научиться использовать.

И вот, наступил декабрь. К этому моменту я успешно прошёл испытательный срок. У нас была даже некая балльная система, по которой по всем критериям у меня было 5/5, что не могло не радовать + положительный отзыв МРа. И в декабре, когда я уже неплохо освоился, состоялась ретроспектива. Ретроспектива - это некое собрание, когда команда обсуждает предыдущий квартал, какие были проблемы, находит пути их решения, подводит итоги и строит планы на следующий квартал. Цель - стать лучше. Одна из задач - разрешить предыдущие проблемы. И на этой ретроспективе я понял, что эта команда та самая, с которой можно свернуть горы и сделать наш продукт очень крутым. Я много читал историй, когда коллектив, мягко говоря - хрень, но в моём случае все более, чем круто сложилось. Ребята, зная, что я совсем зеленый, легко отвечали на все мои самые глупые вопросы, чем я старался не злоупотреблять.

Пошло-поехало

Прошло ровно пол года, как почувствовал, понял, осознал (как это не назови), что тестирование - это моё. Именно спустя пол года я понял, что то, чем я занимаюсь - это призвание. Естественно, что бывают косяки, не тестируемые задачи и прочие грустны вещи, но целая картинка позитивна!

Результат работы

Спустя 7 месяцев я научился и освоил некоторые инструменты и приобрёл скиллы, а именно:

PostgreSQL (СУБД) на уровне, который нужен тестировщику (анализ связей в БД, типов данных, запросы для тестирования и выборки данных);

Консольку Linux для просмотра логов, кода на тестовых стендах, правки "на горячую", всякие curl и прочие мелочи;

Различные техники тест-дизайна;

Буквально в последний месяц начал писать автотесты в связке Ruby+Selenium Webdriver+(всякие гемы аля Browsermob-proxy);

Написание документации (тест-планы, тест-кейсы, чек-листы и пр.);

Ну и всякие мелочи из разряда "деплоить ветку на тестовый стенд", "проверить наличие задач в ветке".

Вывод и скромный совет

Хотел бы обратиться к тебе, читатель. Если ты прочитал до этого места, то тебе в принципе интересно всё о тестировании, даже бредни джуна. Запомни одно - если чувствуешь, что это твоё - "не тормози сни..." не распыляйся и занимайся этим. Тестировщики - это ценные сотрудники, они отвечают за качество продукта, а следовательно экономят деньги заказчикам и делают конечных пользователей чуточку счастливее.

Задавай свои вопросы в комментарии и я с удовольствием отвечу на них.


P.S: Под понятием "тестировщик" я объединил и, непосредственно тестировщиков, и QA, и QC, не будите занудство и не проявляйте проф. деформации :) peace.

Показать полностью

Как перейти в IT индустрию (Часть 1)

RobertWacker в Лига тестировщиков
Как перейти в IT индустрию (Часть 1) It, Python, Тестирование, Программирование, Работа, Собеседование, Опыт, Длиннопост

Всем привет! Решил я написать о своем опыте смены профессии. Может кого-то подтолкну на решение о смене профессии.


Предисловие:


На данный момент я работаю в государственном учреждении, по специальности, но со школьных времен меня интересовало программирование в виде хобби (может кто помнит Python Symbian). Не предав этому внимания, я неудачно поступил вместо программирования на «свою специальность» (пока называть её не вижу резона). В данный момент я пишу на PHP различные недосайты и недоскрипты, но ни один до конца, я так и не дописал. Тяжесть ошибки выбора идет за мной по пятам вот уже 8 лет... И я решил! Стоп! Не хочу прожить жизнь вместе с грузом ошибки выбора и прочим нытьем. Ну и если быть до конца честным, то после 5 месяца работы в госслужбе, я полностью разочаровался в ней. Да и зарплаты отличаются в 3-5 раз. Итак решено! Меняю профиль работы, а если все потеряю, то так тому и быть!


I. Разведка поля боя:


Дано:


1. PHP — начальные знания синтаксиса и немного ООП

2. Python — начальные знания синтаксиса и тоже немного ООП

3. HTML и CSS — на уровне блочной верстки и немного Bootstrap

4. SQL запросы select, insert, drop table =)

5. Прочитал книгу SWIFT для детей (кстати очень понравилась) =)


Не дано:


1. Знание PHP, Python фрэймворков

2. HTML5

3. CSS анимации, препроцессоров LESS и SASS

4. Javascript и фрэймворков (JQUERY и прч)

5. Опыт


Из всех представленных направлений на рынке труда, нам подойдут с минимальными требованиями и отсутствием опыта. Если кто-то думает, что в рамках программирования я отличаюсь от обычного обывателя, Вы сильно ошибаетесь. Все кто хоть раз пробовал писать на Pascal или делал HTML сайты, практически находятся на моем уровне. Самой подходящей специальностью оказалась профессия тестировщика. Я создал резюме на HH.ru и начал кидать отклики на вакансии.


Но стоит понимать, что в отличие от юных специалистов закончивших институт и проходящих в нем учебу, мы не можем себе позволить стажировку за условную плату или бесплатно, ибо опухнем от голода и останемся на холоде!

II. Подготовка к бою


Просмотрев тематические видео на Youtube, я узнал что такое тестирование и чем люди там занимаются. Понял, что это не просто тыкание приложения или программы в поисках ошибок, а целая наука со своей теорией. Прочитал книгу «Тестирование Дот Ком» Р. Савина по диагонали, которую рекомендовала к прочтению одна из блогерш по совместительству QA. Тестирование показалось мне рутинным и скучным занятием, которое в корне отличается от моего характера. Но выбирать не приходится, ибо главное туда попасть.


Вакансий компаний готовых принять меня без опыта на «дармоедство», оказалось чуть больше 3-х. Но я узнал, что некоторым фирмам требуются тестировщики для написания авто-тестов. Тестирование мне не нравится, а вот писать код я люблю! Соответственно позиция тестировщика-программиста мне была по душе.


III. Первый бой


1 вакансия (тестировщик программист Python):


требования — Начальные знания одного из языков программирования (базовые типы и умение работать с ними, циклы, функции)


будет плюсом — Знание Python, Selenium Webdriver, опыт разработки автотестов, понимание принципов разработки и тестирования ПО, знания веб-технологий (html, css, js, http)


процесс — собеседование по скайпу (я больше не смеюсь над видео, где эксперты дают интервью по скайпу, а потом встают в трусах), тестовое задание написать простой тест на Pyhon для тестирования 2 функций поисковика. Переделать тест с использованием фрэймворка (я выбрал unittest) и использовать PageObject патерн (простыми словами это концепция разделения одного скрипта на несколько, в одном адреса элементов HTML страницы, в другом сам код тестирования).


итог — все понравилось но выбрали другого кандидата (я немного расстроился), но! Я узнал что такое Selenium Webdriver и PageObject и получил опыт их использования.


2 вакансия (тестировщик):


требования — аналитическое мышление


Поступил звонок из компании:


HR — вы хотите быть именно тестировщиком или у вас в планах перейти на другую специальность?


Я — начать хотел бы в тестировании и со временем перейти на позицию программиста в вашей фирме.


HR — Жаль, нам нужны люди которые видят себя только в тестировании.


Мой совет, теперь уже на опыте. Никогда не говорите, что у Вас в планах есть переход на другую должность. Говорите, что это Ваша мечта и вы вообще счастливы, что они Вам перезвонили. Высказывайте свои амбиции, только в рамках данной вакансии.

3 вакансия (программист тестировщик Python):


требования — умение написать тестовую документацию, ориентироваться в видах и уровнях тестирования, уметь применять основные методы тест-дизайна


будет плюсом — разрабатывали автотесты на Python, использовали паттерны PageObject + Components, работали с Jenkins или TeamCity.


Данная вакансия в той же компании, что и вакансия №2. Почему-то я сразу её и не заметил. Пока отправил отклик и меня одолевают думки... Не откажут ли они мне, из-за событий 2 вакансии. В этом отклике я уже добавил, небольшой опыт написание авто-тестов на Python + Unittest + Selenium + PageObject. Не соврал же. =)


IV . Послесловие:


Решил посмотреть видео курс по Python-у, повторить виды, методы и уровни тестирования, посмотреть что-такое Jenkins и ждать ответа от 3-ей вакансии. Ничего не бойтесь и идите к своей мечте! Даже если она находится на 25 этаже ;)


p.s.: Буду рад замечаниям по орфографии, пунктуации и в целом по повествованию. Принимаются советы, мудрость и критика. Если кому-то будет интересно, продолжу писать.

Показать полностью

Солидность QA

omnomma в Лига тестировщиков

Работаю тестировщиком. Недавно прислали вакансию с необычной интерпретацией нашей профессии, где в названии указано "Инженер-испытатель программного обеспечения".


Как это видит работодатель (или рекрутер):

Солидность QA Тестирование, Вакансии, Солидность

Как это представляю я:

Солидность QA Тестирование, Вакансии, Солидность

Картинки с гугла)

Показать полностью 1

Тестирование ПО, как найти стажировку?

Vanvejden1979 в Лига тестировщиков

Доброе время суток пикабушники и пикабушницы! Нужен совет, пост не для рейтинга. Прочитан Савин и Канер, текущая профессия сотрудник техподдержки, инженер. Хочу попрактиковаться в тестировании ПО, где бы найти стажировку? Проблема одна, идти в стажеры со сменой работы не могу, надо семью кормить, а стажерам предлагают копейки. Идеально было бы пристроиться на удаленную работу, получил задание, сроки, исполнил. Чешу Гугл и т.д., но решил заодно спросить совета здесь, помогайте коллеги айтишники!)

"Быtие теsтeрa".

PankerenKomissar в Лига тестировщиков
"Быtие теsтeрa". Тестирование, Тестирование по, Тестировщики, Инженер, Длиннопост, Работа

Добрый день господа и дамы.


Как и обещал, истории из жизни тестировщика МП.


Как бы вам описать, главного героя повествования ?! А с другой то стороны, оно вам нужно?


Четверг, вечер, в предвкушении ПЯТНИЦЫ-развратницы !!!!! Закончив внеочередной цикл тестирования по своему функционалу, с нетерпением ждал окончания рабочего дня. За 7, минут до ухода, звонок с собрания команды данного проекта. "Нус задержусь минут на 10, заодно стояние в метро пропущу." - подумал я. Аналитик сразу начал с козырей - "Нус смотрите, у нас всё идёт хорошо, мы в график вроде бы укладываемся и завтра у нас Инной показ перед СБ". Инна, в этот момент, выпала из разговоров, провалившись в чертоги своего разума. Я же, будучи довольно наглым товарищем, поинтересовался - по какой причине мой функционал показывают не я и вообще без меня проходит данное мероприятие? "А, ну это .................... не твоё дело." - ответ Долбонафтера. Думаю вы поняли кто герой, данного поста. Тут вмешался инженер по внедрению, с претензиями:


1) Он узнал о презентации только что.


2) Такие мероприятия проводят на тестовых серварах, которые не работают более недели (о чём сообщали я и Инна в том числе и этому Долбонафту).


3) У тестировщиков (нужны именно двое т.к. я занимаюсь и самим МП и частично бэком, а у напарницы моей есть доступ о том что происходит на самих серверах) нету времени подготовить всё необходимое для online трансляции.


4) Отсутствует номер сборки которую надо показывать.


5) Нету информации о времени проведения презентации.


Коллегиально, было выдвинуто требование - послать сие мероприятие в пешее эротическое. Желательно на неделю. Инна как человек ответственный и отзывчевый согласилась провести презентацию. Я же подписался добровольно по причинам:


- Это мой функциона.


- Она моя напарница.


- Есть способы сжечь пердак Долбонафту.

От его высочества "организатора презентации" aka Долбонафт, требовалось уточнить время проведения, сборку и стенд на котором надо проводить показ. Чувствуете чем пахнет, а ?
Он организовал это мероприятие почти неделю назад, сам не знает о нём ни чего.  

"Сказочный долбоёб" сообщает -" Показываем сборку андроид недельной давности.". Проблема в том, что у нас обновы каждый день штук по 10, требуем конкретный номер сборки. Получили номер, я остался настраивать прогу для презентации, Инна пошла домой.
На почту пришло письмо с информацией о завтрашней презентации. В списках вижу Инну, инженера по внедрению, 2 начальника проекта, СБ-ники, разраб по iOS-у .............................. Перечитываю список ещё 3 раза. Закралась мысля что нас наебали. Пытаюсь дозвониться до Долбонафтера, результат 0. Пишу ему на почту, telegram, и шлю смс "Возьми трубку, шайтан!".

В итоге позвонил инженеру по внедрению, обрисовал всего дермодемона которого мы призвали, неосознанно, и интересуюсь как быть. Решили: в пятницу, около 9 утра созвон всех причастных к презентации, найти рабочий ноутбук, законнектить его с iPhone через wifi который раздаёт старенький самсунг и показывать экран Афони так, ибо разрешения на спец проги для простого рабочего компа - бюрократический ад продолжительностью в неделю. Когда я уходил домой, оказалось что переработак у меня на 3 часа, а сделано было нихуя полезного ))).

Пятница.
Утро 8.49.
До презентации:
Х час.
У мин.
Й сек.
С Вами.


С Инной проверяем работоспособность нашею Uberсистемы, проверям тестовы стенды, ржём над ситуацией. Созвон:

- День добрый, коллеги, всё готово к презентации ?
- К презентации по адроиду,частчно да, по iOS нет, номера сборки нам не предоставили, мы считаем что презентацию необходимо либо перенести на некоторое время либо вообще отменить, так как стенды,которые не работают уже 2-ю неделю, на данные момент починить не могут, не могут понять в чём проблема.
- Так давайте на втором стенде покажем ?!
- Сам нам говорил - только на первом + второй стенд то же мёртв.
- Так и как быть?
- Отменяем презентацию.
- Ок, а от меня вы чего хотите-то?
- Ты организатор, тебе и надо её отменить !!
- Не указывайте мне, на мои обязанности, если не подготовились так и скажите.
- Письма о не рабочих стендах писали с прошлой пятницы, номер сборки ты нам так и не дал, как мы можем презентовать что-то, без работающих стендов.
- Сборка номер P.0.X.
- ................................................... ты в курсе что из 92 тестов на ней проверили 6? Я не могу ручаться за то что она работает корректно.
- Ну за андроид ты ведь можешь ручаться?
- Я его неделю проверял, а эту сборку минут 30.
- Номер сборки я вам дал, показывайте функционал хоть со своих личных аккаунтов, главное покажите это СБ-кам !!


Далее шёл мат и претензии.

До презентации 2 часа, Я с инж. по внедрению пишу письмо СБ-кам с просьбой подключит аналитика aka Долбонафтер, к презентации так как на некоторые вопросы способен ответить только создатель ТЗ. За 15 минут до презентации, "Сказочный долбоёб" отменяет презентацию с формулировкой "Не работает тестовое окружение".

Презентацию перенесли на вторник (завтра) на 11 утра ))). Стенды нам так и не починили, сборку оставили ту же. Люблю свою работу и уважаю своих товарище по работе над проектом, но аналитик нам попался какой-то тормоз.

Следующий пост скорее всего будет именно про презентацию. Если вам понравилось то я искренне рад, если же история не понравилась, прошу прощения и жду аргументированной критики в комментариях.

И вот вам котя, что бы пост не казался таким уж и убогим.

"Быtие теsтeрa". Тестирование, Тестирование по, Тестировщики, Инженер, Длиннопост, Работа
Показать полностью 1

Маленький лайфхак

QA.Engineer в Лига тестировщиков

На проекте пара серверов. Там ведется и разработка, и тестирование. Пару раз была ситуация, когда я тестил что то "многошаговое", серваки тушили и мне только и оставалось что ругаться. В итоге было принято решение купить вот такой девайс на известном китайском сайте.


Когда сервак необходимо потушить в гонг бьют один раз и через 20 сек сервак тушится.

Когда сервак поднят бьют 2 раза и можно продолжать работать.


P.S. Звук очень приятный.


Может кому пригодится...

Маленький лайфхак IT, Лайфхак, Гонг, Привет всем QA

DevOps для тестировщиков

QAtester в Лига тестировщиков

Оригинал тут https://habrahabr.ru/company/luxoft/blog/310998/

История вопроса



В этой статье я хочу обсудить внедрение методологии DevOps с точки зрения тестирования и тестировщика. «Движение DevOps» (лучшего названия пока нет) развивается стремительно. Скорость внедрения новшеств в этой методологии, как и многие другие перемены, которые происходят в этой отрасли, очень высокая. При этом до сих пор нет четко сформулированного названия самого движения.



В зависимости от структуры вашей команды, от того, с кем вы разговариваете, методология DevOps может представлять собой как решение проблемы, так и самостоятельную цель. На некоторых предприятиях цель заключается в переходе к цифровым технологиям, и методология DevOps является частью общего подхода к обеспечению регулярного и высококачественного развертывания. Именно в этом смысле я рассматриваю DevOps в данной статье. Однако при реализации маркетинга технологий и услуг, связанных с методологией DevOps, эта цель может быть не совсем понятной. Проблема изменения культуры (или изменения поведения), требуемого для достижения успеха, зачастую недооценивается. Другое предположение, от которого я отталкиваюсь, заключается в том, что для тестировщиков, работающих в рамках методологии DevOps и находящихся под ее влиянием, эта методология является новинкой.



Я построил эту статью как введение в методологию DevOps для таких тестировщиков, а также как обсуждение ее влияния на методы тестирования. Если Вы являетесь опытным специалистом-практиком, использующим методологию DevOps, эта статья вам также может быть полезна. Если же Вы не являетесь тестировщиком, вы, по крайней мере, взглянете на вопрос с точки зрения тестировщика.



Для непосвященного читателя: что такое методология DevOps?



Простыми словами: DevOps — это понятие, обозначающее группу разработки и группу эксплуатации систем, которые более тесно сотрудничают между собой. В так называемом конвейере развертывания (от исходного программного кода до эксплуатации в производственной среде) разработчики автоматизируют какие-либо действия группы эксплуатации. Группа эксплуатации имеет возможность отслеживать действия разработчиков и оказывать на них некоторое влияние. При этом цель заключается в ускорении развертывания и внедрения программного обеспечения. Объединение группы эксплуатации (Ops) и разработчиков (Dev) (фактически в виде команды, использующей методы Agile) позволяет реализовать подход, который можно назвать «эксплуатация, основанная на методах Agile» (Agile Operations).



Очевидный результат успешного внедрения методологии DevOps заключается в сокращении количества времени, которое необходимо на то, чтобы изменение программного обеспечения прошло все стадии от идеи до эксплуатации в производственной среде. Когда разработчик говорит, что изменение программного обеспечения «сделано», переход к использованию этого изменения в производственной среде выполняется с помощью всеобъемлющей автоматизации. Автоматизированные средства и процессы используются при конфигурировании системы, в процессе сборки, при тестировании, развертывании в тестовой, промежуточной и производственной среде, при проведении мониторинга после завершения развертывания, при оценке и эксплуатации.



Итак, DevOps — это просто инструменты?



С одной стороны, цель методологии DevOps заключается в ликвидации узких мест в конвейере развертывания за счет использования автоматизации. Но автоматизацией многостадийных процессов все равно необходимо управлять. Многие автоматизированные процессы на самом деле не являются автономными — они не могут выполняться без вмешательства человека (для выполнения технического обслуживания и обработки нестандартных ситуаций). Полностью автоматизированный процесс DevOps не имеет смысла без учета влияния человеческого фактора. Несмотря на то что средства автоматизации выполняют много черновой работы, именно люди, управляющие процессом, обеспечивают его успешное (или неуспешное) выполнение.



Итак, DevOps — это просто разработчики (Dev) и группа эксплуатации (Ops), тесно сотрудничающие с использованием средств автоматизации?



Нет, опять неверно. Передача управления между автоматизированными процессами часто включает в себя другие процессы — обычно тестирование того или иного рода. Автоматизированные тесты создаются разработчиками и тестировщиками. Результаты этих тестов нацелены на предоставление достаточной информации, необходимой для выполнения других процессов или, что бывает чаще, необходимой людям, которые выполняют переход от одной стадии конвейера к другой. Тестировщики и разработчики, которые осуществляют тестирование, обеспечивают успешное и надежное выполнение процесса DevOps.



Голова кругом! И что же все-таки означает DevOps? Это прогрессирующая новейшая дисциплина. Данный вопрос детально рассмотрен в статье «What Is DevOps?», которая появилась за несколько недель до написания данной статьи. Как вы уже поняли, определение понятия DevOps еще не сформулировано окончательно. Возможно, никогда и не будет.



Что это значит для тестировщиков? Это значит, что до сих пор не существует «единственно верного пути» и что ваша роль в режиме DevOps, который постоянно развивается (а каждый режим постоянно развивается), еще окончательно не установлена. Существуют два момента, которые вы можете реализовывать:



1) обращать внимание на болевые точки и прилагать усилия к тому, чтобы уменьшить степень их негативного влияния;


2) выявлять возможности, которые позволяют оптимизировать процесс DevOps.



Если и существует единственная мантра, которая наилучшим образом описывает движение к методологии DevOps, то она звучит так: «Если это неприятно, делайте это чаще». Это может показаться похожим на клише, однако я буду пользоваться этим выражением в качестве контекста для внедрения и совершенствования практических навыков по тестированию с использованием методологии DevOps.



Если это неприятно, делайте это чаще



Трудности или неприятные ощущения, которые мы испытываем при выполнении определенной работы, влияют на нас отрицательно. Если нам не нравится какое-либо задание, то мы стремимся отложить его. Когда же мы, наконец, принимаемся за это неприятное дело — становится еще невыносимее. Визит к стоматологу, уборка в гараже, интеграция программного обеспечения, тестирование и т. д. Опыт говорит о том, что чем реже мы выполняем такие задания, тем неприятнее их выполнение. Мартин Фаулер (Martin Fowler) предложил три причины того, почему частое (или даже непрерывное) выполнение определенных заданий уменьшает неприятные ощущения.



Первая причина заключается в том, что большие и сложные задания трудно планировать, ими трудно управлять и их трудно контролировать. Разбиение больших заданий на несколько маленьких позволяет облегчить их выполнение и снизить степень риска, а если что-то пойдет не так, будет проще все вернуть в прежнее состояние. Вторая причина – многие задания (и тестирование в этом плане представляет собой наилучший пример) обеспечивают возможность обратной связи. Эта обратная связь, если она поступает на ранней стадии и достаточно часто, позволяет быстро реагировать на возникающие проблемы, прежде чем будет впустую потрачено время. И третья причина: если мы осуществляем какую-либо деятельность чаще, мы лучше справляемся с ней. Мы учимся делать эту работу эффективно. Кроме того, мы находим возможности автоматизировать ее тем или иным способом.



С точки зрения тестировщика эта мантра вынуждает более серьезно подходить к понятию автоматизации при осуществлении процесса тестирования. Если производится ручное вмешательство (обычно между автоматизированными стадиями в процессе DevOps), то оно должно рассматриваться как болевая точка: узкие места, причины задержек и потенциально ненадежные и склонные к появлению ошибок аспекты процесса.



Ручное тестирование неприятно. Да, вам может доставлять удовольствие проводить исследовательское тестирование, вы можете считать, что только вы как человек сможете обнаружить те заковыристые ошибки, которые автоматика никогда не найдет, что только вам как тестировщику можно доверять, чтобы не допустить катастрофу.



Вас как тестировщика может беспокоить, будет ли работа по тестированию выполнена надлежащим образом, если она поручается разработчикам или автоматизированным средствам. Если это для вас неприятно, делайте это чаще.



Тесты, автоматизация и доверие



Ведется много споров вокруг значения, например, проверок и тестирования, и вокруг того, насколько мы можем полагаться на тестировщиков, на проверки и на автоматизированные средства (The New Model and Testing v Checking).



Я не говорю, что мы должны полностью полагаться на автоматизированные проверки. Нам понадобится применить более сложный подход. Однако мы можем для целей этой статьи, по крайней мере, разделить тесты и деятельность по осуществлению тестирования на четыре компонента:



1) проверки, которые могут быть автоматизированы разработчиками в составе покомпонентных проверок и процессов непрерывной интеграции;



2) проверки, которые можно автоматизировать (обычно силами системных тестировщиков) для выполнения транзакций на уровне API, линий связи или всей системы;



3) тесты, включающие проверки совместимости и позволяющие продемонстрировать совместимость с браузерами, операционными системами и платформами;



4) тесты, которые может выполнить только человек.



В данной статье могу лишь сделать предположение, как осуществить такое разделение — каждая среда имеет свои особенности. Наиболее подходящий вопрос для данной статьи – как тестировщику «освободить себя» от поздних ручных проверок? Ранее я писал об исключении поздних ручных проверок. Это требует предусмотрительности и доверия.



Необходимо сконцентрировать внимание на следующих моментах:



1. Если это возможно, ручные проверки, которые могут быть выполнены на уровне компонентов, должны быть возложены на разработчиков. Как тестировщик, вы можете предложить выполнить эти тесты во время сеансов парной или коллективной работы. Вы можете написать их сами и включить их в режим непрерывной интеграции.



2. Для тестирования пользовательского интерфейса и комплексного тестирования может потребоваться использование автоматизированных средств. Такое тестирование следует свести к минимуму, так как оно долго выполняется, является нестабильным и часто требует обслуживания. Подумайте о том, нужно ли его выполнять при каждой проверке программного кода или можно отложить для использования только на крупных, менее частых релизах.



3. Какие неавтоматизируемые тесты можно выполнять на компонентах, которые еще не интегрированы в предвыпускную версию? Можно ли выполнять ручное тестирование в сеансах парной работы с разработчиками? Существуют ли альтернативы такому тестированию? Может ли помочь работа с архивными документами, прототипирование с использованием подхода BDD? Можно ли выполнять проверки пользовательского интерфейса на макетах или каркасных конструкциях?



4. Какие проверки необходимо выполнять только вручную в отличие от проверок, которые требуется оставить для регрессионного тестирования (они являются кандидатами для автоматизированного тестирования)?



Выше я упомянул о доверии. Другой вопрос заключается в том, как надежно тестировать систему, если не будет позднего ручного тестирования. Представьте себе среду, в которой все тестирование осуществляется автоматизированными средствами. Поверите ли вы, что разработчики надлежащим образом выполнят тестирование? Смещение забот о тестировании влево должно развеять ваши сомнения. Если вы как тестировщик действуете, как следопыт: для того чтобы идентифицировать и оценить риски, выбрать тесты и обеспечить, чтобы они были встроены в процессы разработки и автоматизации, то ваши опасения могут быть сведены к минимуму.



Естественно, вы должны перестать считать себя охранником качества, последним рубежом обороны, единственным человеком, которому не все равно. Вам приходится больше думать, как провидец, определитель рисков, управляющий рисками, следопыт, координатор и инструктор или наставник.



Практика, мониторинг и совершенствование



При всем желании если перестать полагаться на поздние ручные проверки, ошибки все же могут быть. Когда программное обеспечение выпускается в производство, обнаруживаются проблемы. Одной из ключевых дисциплин методологии DevOps с точки зрения эксплуатации является более глубокий мониторинг.


Мониторинг на каждом уровне — от компонентов и простых транзакций в приложениях до интеграции и обмена сообщениями и, конечно, самой инфраструктуры. Одна из целей мониторинга заключается в том, чтобы формировать сообщения об отказах до того, как пользователи испытают на себе их последствия. Это довольно амбициозное утверждение, но оно определяет конечную цель.



Когда проблемы встречаются в производственной среде, то задача заключается в том, чтобы использовать аналитическую информацию, полученную при выполнении мониторинга для того, чтобы не только отследить причину и устранить ее, но и для уточнения процесса тестирования (автоматизированного или ручного) и снижения вероятности возникновения подобных проблем в будущем. Роль тестирования и аналитической информации в функционировании всего конвейера определяется и обсуждается в статье «Thinking Big: Introducing Test Analytics».



Можно назвать автоматизированное тестирование процесса DevOps мониторингом. Когда мониторинг объединен с производственной средой, можно сказать, что мониторинг на протяжении всего процесса DevOps с заходом в производство расширяет сферу применения тестирования. Таким образом, методология DevOps не уменьшает роль тестировщиков.



Заключение



Недавно меня спросили: «В каком случае не следует пытаться применять методологию DevOps в организации?». Это хороший вопрос. Думаю в его основе лежит опасение, должна ли методология DevOps стать нормой и должны ли тестировщики обратить на это внимание. Мой ответ прост.


Почему бы вам не сделать так, чтобы разработчики и специалисты по эксплуатации разговаривали друг с другом? Почему бы вам не начать получать более надежные сборки и развертывания в тестовой и производственной среде? Почему бы вам не использовать лучшие технологии для более точного, эффективного и информативного конвейера? Методология DevOps является хорошим делом, однако не всегда легко достичь требуемого уровня ее использования. Не говоря уже о том, что она требует изменения культуры, а это не так просто.



С точки зрения тестировщика, методология DevOps оказывает влияние в большей степени на ранних стадиях проектов, вынуждает более серьезно задумываться об автоматизации тестирования, предоставления информации и принятия решений. Тестировщикам следует стремиться к использованию методологии DevOps, так как она дает возможности для выполнения действий в упреждающем режиме, получения более широких полномочий и уважения в проектной команде.

Показать полностью

Бесплатный ивент-практикум “Практические аспекты автоматизации тестирования на Selenium”

QAtester в Лига тестировщиков

Пройдет: 18 июня (суббота)

Начало: 12:00

Место: Киев, ул. Жилянская, 75, Академия ДТЭК, вход возле БТА банка, 12 этаж

Стоимость: бесплатно


Тестеры! Кто из Киева, не упустите возможности повысить свой скилл!


Подробнее: https://dou.ua/calendar/11174/

XCTest UI и Unit тестирование для iOS

QAtester в Лига тестировщиков

После творческого кризиса, снова в деле)))

Для тех, кому интересно узнать про тестирование iOS приложений, предлагаю посмотреть видео, в котором будут разбираться с возможностями, особенностями и сложностями при работе с нативным фреймворком XCTest для тестирования iOS-приложений.

Есть любитель поминусить просто так, но если найдется чел, который объяснит, почему пост достоин минуса, буду благодарен.

Отличная работа, все прочитано!