Метод прогрессивного Гейзенбага

В этом посте я расскажу:


  • о текущем статусе конференции Heisenbug 2018 Piter;
  • о том, как правильно писать периодические анонсы на Хабр;
  • о небольшом лайфхаке, как рисовать картинки с прогрессивным JPEG в стиле Тёмы Лебедева.

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



Читать дальше →

Анонс конференции Heisenbug 2018 Piter. Make Heisenbug, not warǃ

Конференция: Heisenbug 2018 Piter
Дата: 17-18 мая 2018 года
Место: Санкт-Петербург, Гостиница «Park Inn by Radisson Пулковская»

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


Анализ отзывов участников


Перед написанием этого анонса я открыл отзывы участников и просмотрел 292 ответа. Основная тема половины отзывов — необходимость (или её отсутствие) иметь доклады по мануальному тестированию. Это то, что я хотел бы обсудить с вами.


На позапрошлый Heisenbug ругались, что он превратился в какой-то Autobug. Надеюсь, никто не обидится, если я приведу один обезличенный отзыв по этой теме, как из палаты мер и весов:


«Если в двух словах — «автоматизация головного мозга». Следовало так и назвать конференцию. Была всего пара докладов про НЕ автоматизацию. Вы ведь и сами знаете, что автоматизация это всего лишь часть тестирования, и совсем не основная».

Читать дальше →

Практика написания Android-тестов. Лекция Яндекса

С праздниками, друзья! Если вы не против научиться на каникулах чему-то новому, прочитайте лекцию Кирилла Борисова — разработчика систем авторизации Яндекса. Кирилл объясняет, как построить процесс тестирования Android-приложений, знакомит с современными инструментами и спецификой их использования.


— Прежде чем двинуться вперед, давайте устроим небольшой соцопрос. Кто из вас знает, что такое тесты? Кто пишет тесты? А кто знает, зачем он пишет тесты? Читать дальше →

Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста


Здравствуйте. Меня зовут Илья Кудинов, мне 27 лет, и я тестировщик.
Все: Здравствуй, Илья!

Мы уже много писали о том, как здорово мы в Badoo тестируем наши продукты. А сегодня я (внезапно!) расскажу о том, как круто тестировать ВООБЩЕ. И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.

О чём она будет? Я поделюсь своим личным опытом, расскажу, как развивалась индустрия в течение шести с небольшим лет, что я за ней наблюдаю, и опишу своё видение карьерного пути тестировщика. Устраивайтесь поудобнее, настало время (неразборчиво, зачёркнуто) занимательных историй…

Дисклеймер


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

Если вы со мной в чём-то не согласны — добро пожаловать в комментарии. Я всегда открыт к диалогу. Читать дальше →

От танков до АЭС: оглядываясь на Heisenbug 2017 Moscow



Пока мы после конференции Heisenbug собирали и анализировали зрительский фидбэк, на Хабре появился подробный пост IvanPonomarev с его впечатлениями зрителя. И чтобы не повторять его, а дополнить, мы решили построить свой текст о конференции иначе.

Не описывать последовательно все два дня с вечеринкой, а посмотреть по зрительским оценкам, какие из не упомянутых Иваном докладов сильнее всего понравились аудитории (у всех таких оценки оказались выше 4.2), и рассказать немного о них. В итоге получился список «шесть вещей, которые привлекли зрителей Heisenbug» — по нему можно оценить и конкретные темы, и их разброс.

Читать дальше →

Переход из тестировщика в руководители проектов


Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.


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


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

Читать дальше →

Шоу, учебник, справочник и договор: анонс бесплатной YouTube-трансляции Heisenbug 2017 Moscow

Коротко о событии
Конференция: Heisenbug 2017 Moscow
Дата: 8-9 декабря 2017 года
Бесплатная трансляция (только первый зал): страница трансляции на официальном сайте.


Какой самый частый вопрос в комментариях на Хабре? «Будет ли запись?» Сразу возьмём быка за рога: запись будет, как всегда, через 3-4 месяца. Но из тех, кто задавал вопрос, смотреть её будет едва ли половина.


Чтобы понять, почему так происходит, нужно разобраться — как мы смотрим видео с конференций, зачем это вообще нужно?

Читать дальше →

[Из песочницы]  «Угнать за 60 секунд» на примере одного каршеринга

image
«Без разочарований не ощутишь вкус победы» © Мемфис Реймс

История началась банально. В каком то ролике на YouTube рассказывали про каршеринг. С демонстрацией функции «приветствия», когда вам не удается найти автомобиль на большой парковке. У меня тут же возникла мысль проверить — а не смогу ли я активировать функцию приветствия на абсолютно все автомобили этой компании?! Ну весело же. Крупный российский город. И в какой то момент тысячи автомобилей по команде начинают сигналить и моргать фарами. Почти как в фильме «Крепкий Орешек 4».

В результате все получилось куда интереснее. Ведь фактически я нашел возможность угона любого автомобиля.
Читать дальше →

Мобильный DevOps. Интервью с Jing Li


Так получилось, что инструменты DevOps обычно иллюстрируются на примере CI/CD какого-то масштабного веб-сервиса. Отчасти так получилось по историческим причинам, отчасти свою роль сыграли замечательные книги типа Google SRE Book.


К черту, давайте посмотрим на что-нибудь действительно новое. На Mobius 2017 к нам приезжает Jing Li из Viacom, с докладом “Android meets Docker”.


Накануне конференции, удалось найти несколько минут в его плотном графике и задать пару вопросов. В этом интервью Jing рассказывает о DevOps в мобильной разработке, приводит примеры задач, и дает конкретные рекомендации по улучшению вашего DevOps процесса.

Читать дальше →

[Из песочницы] Mountebank: гибкое мокирование web API

image Когда речь заходит о разработке современных IT-систем, вопрос мокирования внешних зависимостей всегда идет где-то рядом. Внешний сервис может быть недоступен на этапе разработки, либо его функционал разрабатывается параллельно и на него нельзя полагаться. Особенно остро этот вопрос встает на этапе написания автотестов, ведь проверять нужно не только штатное поведение вашей системы, но и исключительные случаи: недоступность внешнего сервиса, случаи когда внешний сервис отвечает ошибкой и так далее. Даже если вам повезло и ваш продукт имеет минимум зависимостей от внешних сервисов, скорее всего внутри он разбит на компоненты (классика жанра — backend/frontend), которые можно и нужно тестировать по отдельности. Это значит, что внешней зависимостью уже является api соседнего компонента, команда разработки которого совсем не горит желанием предоставлять вам инструменты для управления его состоянием. По моим наблюдениям команды тестирования предпочитают ограничиться самыми базовыми кейсами автотестов, объясняя это как-раз невозможностью переопределить поведение внешней системы. Решить эту проблему может мокирование API внешних систем. Обычно в этом месте тестировщики начинают грустить, т.к. предыдущее предложение означает, что помимо самих автотестов им нужно написать сервис, дублирующий по функционалу внешнюю систему, а в дополнение к этому нужно как-то управлять его состоянием, чтобы на одни и те же запросы он мог отвечать по-разному в зависимости от тест-кейса....Далее...
  • Новее
  • 1


Последние посты