Всем привет! Меня зовут Сергей, я — Senior Manual QA Engineer в »Петрович‑Тех», и в этой статье я предлагаю разобрать граничные значения на практических кейсах.

Думаю, почти любой тестировщик вспоминает граничные значения первыми из всех техник тест‑дизайна. Особенно на собеседовании. Граничные значения звучат просто и понятно, про них легко рассказать, потому что даже из названия ясно, где и как они применяются.

Несмотря на то, что техника простая — она решает много проблем. Это не попарное тестирование, о котором я писал здесь, где есть куча инструментов на выбор, надо правильно составить входные данные, потом анализировать их и выдавать результат. Тут всё проще: мы руководствуемся чистой логикой.

Разберем в статье конкретные примеры использования этой техники.

Здравствуй, Хабр! Меня зовут Оняков Федор, я старший Web-программист в Петрович-Техе. Но сегодня мы будем говорить не о моей работе: уже больше четырех лет я развиваю свой умный дом и помогаю делать умные дома друзьям и коллегам.

Одни приходят к умному дому из соображений экономии, другие – ради комфорта, третьи – из любопытства. Среди историй есть драматические: был приятель, который чуть не затопил 9 этажей соседей, другой чуть не устроил пожар из-за камина. После они всерьёз занялись автоматизацией бытовой инфраструктуры. Истории объединяет смена точки зрения: люди думали, что умный дом – это какое-то баловство для богатых, а сейчас выстраивают автономные системы, упрощающие жизнь.

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

Всем привет! Меня зовут Сергей Герасимов, я – Senior QA Manual Engineer (да, хвастаюсь) в компании “Петрович-Тех”.

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

Звучит просто, но что кроется за ней?

В своей прошлой статье я рассказывал о тестировании оплат, техниках тест-дизайна, которые использовал, и всячески открещивался от попарного тестирования. Но вот злой рок дошел до меня, и сегодня я расскажу о недавнем опыте использования “попарки” на практике. 

Рубрика «Кем работать в IT» — это интервью с представителями IT-профессий, в которых специалисты рассказывают о тонкостях своей работы: плюсах, минусах, подводных камнях и заработной плате. Мы надеемся, что джунам и стажёрам она поможет больше узнать о том, что их ожидает на карьерном пути, а профессионалам — посмотреть на свою специальность через чужой опыт и, может быть, открыть для себя что-то новое.

Для этой статьи о своём опыте работы нам рассказал Андрей Носков, ведущий разработчик 1С в «Петрович-Тех».

Привет, Хабр! Меня зовут Марина, и я бизнес-аналитик в Петрович-Техе. 

У каждого бывают моменты, когда хочется сменить все — от домашнего интерьера до карьерной стратегии. Три года назад я хотела перемен и перекрашивала дома кухню, а затем это желание меняться привело меня в ИТ.

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

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

Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”.

Представьте: пользователи не могут начать работу в системе. Не испытывают сложности через день или неделю, а прямо на старте не имеют возможности начать пользоваться продуктами компании.

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

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

Привет, Хабр! Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

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

Приступим!