Или как получить неочевидные последствия, если отказаться от команды тестирования. Полтора года назад мы разрушили команду тестирования: отказались от регресса, передали E2E автотесты на Selenium в поддержку разработчикам и разошлись по командам, которые пилят фичи, чтобы предотвращать ошибки «в зародыше». В розовых мечтах нам казалось, что так будет больше пользы: QA работают над качеством, тестирование начинается рано, а разработчики пишут автотесты сами и никто им не мешает.



Но не фартануло получилось не совсем так. Розовые мечты окрасились дополнительными оттенками: никто не думает о качестве, автотесты всё хуже, а у разработчиков без команды QA (внезапно) стало больше работы. Так проявились последствия второго порядка, к которым мы не были готовы. Сейчас мы их исправляем и можем рассказать, что это за последствия, как они возникают, какой урон наносят и как попробовать их предугадать, чтобы не было так больно.

В феврале мы выясняли секреты крутого митапа. В этот раз попросили поделиться советами трех хорошо знакомых Хабру лекторов (Кирилла Анастасина, Вячеслава Уточкина и Евгения Жданова). За их плечами сотни публичных выступлений, и им есть чем поделиться.



Говорили про выбор времени, длительность, контент, подстраховку и прочие важные вещи. В итоге у нас опять набралось 16 пунктов.

Привет, Хабр! Меня зовут Женя. Десять лет назад я стартанул агентство аутсорс-тестирования «Кавычки». У нас в компании нет и никогда не было деления тестировщиков на джунов, мидлов и сеньоров. Хотя были попытки. Расскажу, почему так получилось и как можно жить без грейдов.

Было ли у вас ощущение, что ради тестирования вы делаете код труднее для чтения? Допустим, у вас есть код, который ещё не тестировался. У него есть ряд побочных эффектов, и вас просят сначала прогнать тесты. Вы начинаете следовать советам вроде передачи глобальных переменных в виде параметров или извлечения проблемных побочных эффектов, чтобы сделать вместо них заглушки в тестах.

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

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

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

Selenium WebDriver создавался как кросс-платформенный инструмент для управления веб браузерами. И вот уже почти 14 лет он делает эту работу очень и очень хорошо. Впрочем, автотесты из реального мира создают ситуации, в которых Selenium бессилен. Например, по сценарию нужно загрузить или скачать какой-либо файл. После нажатия кнопки "Загрузить" или "Скачать", поверх окна браузера появляется окно файлового менеджера операционной системы к которому Selenium уже не имеет доступа. Тест останавливается.

Я слышал рекомендации использовать утилиты типа AutoIt или Sikuli для работы с такими системными окнами. Мой совет — никогда так не делайте, это порочная практика, которая приводит к нестабильным тестам:

• Такое решение не кросс-платформенное. Приходится изобретать свой велосипед для каждой новой операционной системы.
• Хрупкое. Нет гарантии, что скрипт будет работать корректно если на машине открыто несколько браузеров.
• Это делает невозможным использование headless режима браузера

Меня зовут Ярослав Пернеровский. Я уже 15 лет в тестировании и около 8 лет в автоматизации. Сейчас я расскажу как нужно правильно обрабатывать такие ситуации.

Законы, теории, принципы и закономерности, полезные для разработчиков

Введение

Перевод репозитория github.com/dwmkerr/hacker-laws

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

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

Законы

Закон Амдала

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

Привет, Хабр.

На днях в комментариях к одному хабропосту я увидела фразу: "Думаю, будущее всё-таки за федерацией". Это, наконец, сподвигло меня на написание статьи, зреющей в течение года. Хотелось бы, чтобы все, кому интересны децентрализованные социальные сети, вынесли из неё что-то новое.

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

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

В этой статье я постарался:

• осветить «детские болячки» тест-менеджмента, стремящегося автоматизировать все, что не приколочено,
• пояснить, какую пользу может нанести бюджету проекта автоматизация тестирования без детального анализа ее скоупа и должной подготовки,
• составить Roadmap для подготовки к автоматизации проекта.

Источник 

Сразу скажем — мы в EnglishDom просто обожаем Джорджа Карлина и считаем его одним из величайших комиков всех времен и народов. Он чертовски харизматичный, остроумный и по-настоящему смешной.

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

Всем привет! Меня зовут Александр Афенов, я тимлид команды Order Processing в компании Lamoda. Сегодня я хочу вам рассказать о практиках обмена знаниями: какие проблемы эти практики решают, как мы к ним пришли, и как они влияют на жизнь разработчика.

Фёдор Борщёв — CTO в маркетплейсе стройматериалов «ГдеМатериал», сооснователь rumetr.com и популяризатор чистоты кода. Пишет в блог, телеграм-канал @pmdaily и в советы о разработке в Бюро Гобрунова.

Я сейчас меняю работу — со средней позиции менеджера по логистике на позицию полного джуниора в аналитике данных. И, чтобы срезать пару углов на новом карьерном пути, посмотрел вебинар Фёдора и сделал его конспект. Мне кажется, что советы Фёдора будут интересны другим, поэтому публикую конспект.

За три часа Фёдор прошёлся по темам:

• управление проектами;
• общение с людьми;
• продукт и бизнес;

• личные цели.

Я бы хотел получить такое письмо три года назад, когда только начинал изучать Data Science (DS). Чтобы там были необходимые ссылки на полезные материалы. Статья не претендует на полноту охвата необъятной области DS. Однако для начинающего специалиста будет полезна.

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

Хитрость в том, чтобы сразу определить значение слова «действительный».

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


^{en.wikipedia.org/wiki/Email_address#Valid_email_addresses}

Ни для кого не секрет, что область применения Python довольно широка: начиная от web-технологий, игровой индустрии и заканчивая проектами NASA. Python работает практически везде: от карманных компьютеров и смартфонов до серверов сети и практически на всех известных платформах, таких как Windows, Linux/UNIX, macOS, Palm OS, Raspberry PI и так далее. Благодаря фреймворку Kivy в 2011 году Python освоил и мобильные платформы в плане разработки приложений под iOS и Android, а в 2015 с помощью библиотеки KivyMD Python научился использовать Material Design.

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

Вопрос, казалось бы, простой на первый взгляд… можно погуглить, и всё станет ясно. Но практически все статейки в сети дают либо «космические» числа — вроде 400-600 мегапикселей (Мп), либо это и вовсе какие-то убогие рассуждения.

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

Начнём с общей структуры зрительной системы

1. Сетчатка
2. Зрительный нерв.
3. Таламус(ЛКТ).
4. Зрительная кора.

Сетчатка состоит из трёх типов рецепторов: палочки, колбочки, фоторецепторы(ipRGC).

Некоторое время назад я написала статью о своем опыте организации работы QA Инженера на проекте. Сейчас хочу продолжить эту тему, но уже в более узком ее направлении — автоматизации тестирования. Речь пойдет о том же самом проекте, он небольшой, но развивающийся под запросы постоянных клиентов. Быть может мой подход не очень подойдет командам, где работают много десятков сотрудников и каждый отвечает за свою часть (по-моему, в таких проектах работа каждого должна быть строго регламентирована, иначе такой махиной управлять просто невозможно, хотя и они найдут здравое зерно), но он точно будет интересен тем, кто, как и я, однажды пришел на новую работу, и встал на перепутье как самому организовывать свое место под новым солнцем.

Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты»

---

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

IP ATC Asterisk — это мощный комбайн в области IP-телефонии. А web-интерфейс FreePBX, созданный для Asterisk, значительно упрощает настройку и снижает порог вхождения в систему.
Если вы можете придумать какую-либо задачу, связанную с IP-телефонией, то почти наверняка это можно реализовать в Asterisk. Но будьте уверены, что от вас потребуется упорство и выдержка.

Перед нами встала задача настроить e-mail уведомления о пропущенных вызовах. Точнее говоря, оповещать через e-mail о тех случаях, когда входящий вызов перешёл в очередь, но никто (из агентов) так и не ответил на этот входящий вызов.

На удивление мы не обнаружили штатных средств для решения этой задачи во FreePBX. О том, как мы решили эту задачу, расскажу под катом.

Цель этого поста: показать технику отладки в debian/ubuntu, связанную с "поиском первоисточника" в системном конфигурационном файле.

Тестовый пример: после долгих издевательств над tar.gz копией установленной ОС и после её восстановления и установки апдейтов мы получаем сообщение:

update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
W: initramfs-tools configuration sets RESUME=/dev/mapper/U1563304817I0-swap
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/foobar-swap)
I: Set the RESUME variable to override this.

Цель: понять, откуда это значение (U1563304817I0) пришло и как его правильно поменять. Это первый попавшийся пример, не особо интересный сам по себе, но удобный, чтобы показать практические методы работы с Linux.

Шаг номер 1: Откуда пришёл RESUME?