Некоторое время назад я гуглил интернет по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая новый музон и думая о новой фиче в проекте. Как появилось время, решил восполнить этот пробел, заодно написав полезную статью по этому поводу.

Тестирование в больших компаниях, в enterprise, чаще всего дело сложное и неблагодарное. Разрыв между бизнес-подразделениями и IT огромный: когда разработчик имеет видение на уровне кода, а проверку – на уровне модульных тестов, а заказчик мыслит работающими или неработающими даже не услугами, а целыми процессами, выходящими за рамки одной команды разработки, а то и целого подразделения\компании. И просит организовать бизнес-тестирование, или сквозное тестирование, или тестирование на основании сценариев от начала и до конца (end 2 end).

Вроде бы о тестировании мобильных приложений есть уже тысячи материалов, так что удивить тут сложно. Но пока аспекты вроде UI уже затёрты до дыр, про тестирование геолокации рассказывают гораздо реже. И когда на нашей конференции Heisenbug Николай lamamer Козлов и Александр z3us Хозя (Badoo) поделились своим опытом, зрителей конференции доклад очень заинтересовал. Как и геолокацию получить, и телефон пользователю не разрядить? Зачем в этом тестировании селфи-палка? Насколько близко расположены лондонские пабы и что из этого следует?

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

Предисловие

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

Я считаю, у меня сейчас есть чувство, что я нашел то, что искал.

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

Сразу, конечно, хочу оговориться, что все нижеописанное не в полной мере история, но и не универсальное руководство. Это обобщения из того пути, который я прошел из военного ВУЗа до психологии, маркетинга, и в итоге пришел в IT сферу.

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

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

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

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

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

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

В начале 2019 года мы (совместно с порталами Software-testing.ru и Dou.ua) провели исследование уровня оплаты труда QA-специалистов. Теперь мы знаем сколько стоят услуги тестировщиков в разных уголках планеты. А ещё мы знаем какими знаниями и опытом должен владеть QA-специалист, чтобы сменить душный кабинет и скромный оклад, на пляжный шезлонг и толстую пачку валюты. Хотите узнать обо всём подробнее? Читайте нашу статью.

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

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

Но процесс релокации фрилансера в разных странах немного отличается от переезда штатного специалиста. Рассмотрим его на примерах разных стран Европы, Азии и Северной Америки.

Для удаленной работы есть миллион причин. Торчать по 8-9 часов в офисе вовсе не так здорово, как это показано в сериалах. В один прекрасный день, летом 2018-го, я просто решила, что мне нужно больше личного пространства и собралась увольняться, тем более на моей должности в то время я доросла до максимума и дальнейших перспектив не предвиделось.



Моя работа была чем-то средним между саппортом, тестировщиком, оператором SQL и Excel-ниндзя, а хотелось углубиться в тестирование.

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

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

Мы продолжаем рассказывать о проектах весеннего хакатона DevDays, в котором участвовали студенты магистерской программы «Разработка программного обеспечения / Software Engineering». Первая часть рассказа.



Кстати, хотим пригласить читателей присоединиться к VK-группе магистратуры. В ней мы будем публиковать самые свежие новости о наборе и учебе. Видеозапись со дня открытых дверей также можно будет найти в группе. Напоминаем: мероприятие пройдет 29 апреля, подробности на сайте.

Гибкая методология разработки — отличная идея, которую слишком усложнили. Agile Lite — попытка упростить ситуацию. Вам не нужны книги или семинары, чтобы объяснить Agile Lite. Нужен только небольшой текст с несколькими пунктами. Вот этот текст.

Agile Lite довольно прост. Его можно применить к любому проекту при условии, что работа разбивается на более мелкие задачи (issue). Как и другие гибкие методологии, он использует короткие циклы разработки  — спринты. Но в отличие от них, Agile Lite явно признает распространённость выгорания в индустрии разработки программного обеспечения и пытается смягчить его напрямую путём внедрения цикла «три недели разработки/одна неделя отдыха.

Привет. Меня зовут Даша, тестирую мобильное приложение 2ГИС на iOS. Хочу поделиться нашим процессом ведения фич, который помогает не только сэкономить время, но и прокачать личные скиллы. Прочитайте статью, чтобы узнать, как нам удаётся удерживать в едином контексте продактов, дизайнеров, разработку. Мы верим, что ревью первой тестовой сборки всеми заинтересованными действительно облегчает людям жизнь. А коммуникация — ключевой момент в ведении фичи.

Начнём со сладкого и приведём примеры из практики тестирования.

Представьте себе готовый к запуску интернет-магазин. Ничего не предвещает беды. Маркетологи разработали стратегию продвижения, были написаны статьи в профильные интернет-ресурсы, оплачена реклама. Руководство ожидало до 300 покупок еженедельно. Проходит первая неделя, менеджеры фиксируют 53 оплаты. Руководство магазина в ярости…

Многие считают тестирование на production окружении вредной практикой: оно не помогает предотвратить попадание проблем к конечным пользователям, а больше констатирует их наличие. Кроме этого, тестировщик отрывается от стандартного рабочего процесса и методик, применяемых на тестовом окружении. Меня зовут Оля Михальчук, я QA-инженер в финтех-компании ID Finance. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту.

Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.

Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.

Первым делом вам стоит понять, на каком вы проекте

Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:

• проекты без тестирования;
• проекты с недобросовестным тестированием;
• проекты с тестированием.

В последнее время JIRA активно используют организации, не имеющие прямой связи с IT. Специалистам, не знакомым ранее с JIRA, бывает сложно понять структуру JQL-запросов, если не привести примеры.

Для упрощения восприятия, мы решили собрать всю документацию, локализовать и разместить в одном месте. И начнем мы с «базового» и «быстрого» поиска.

Сегодня я предлагаю затронуть вопрос ручного тестирования проектов на VueJS.

Независимо от уровня автоматизации процессов тестирования, практически всегда остается “живое общение” тестировщика с будущим релизом. Естественно, что оно должно быть комфортным и эффективным.

В своих проектах на VueJS мы внедрили простые, но эффективные решения, которые значительно облегчили жизнь нашим тестировщикам. Ими я и хочу с вами поделиться.

Управление временем – это на самом деле не решение, а часть проблемы

Автор статьи: Адам М. Грант, американский ученый-психолог и писатель; профессор Уортонской школы бизнеса; автор трёх бестселлеров Нью-Йорк Таймс, а также книги «В работу с головой. Паттерны успеха от IT-специалиста».

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

«Это прозвучит, как шутка, но на самом деле всё серьёзно, — признался он. – Единственное, что мне пришло в голову – пить меньше воды, чтобы не бегать так часто в туалет».

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

Я работаю в игровой компании, которая разрабатывает онлайн-игры. На текущий момент все наши игры делятся на множество “маркетов” (один “маркет” на страну) и в каждом “маркете” есть дюжина миров, между которыми распределяются игроки при регистрации (ну или иногда они могут выбрать его сами). Каждый мир имеет одну базу данных и один или несколько web/app-серверов. Таким образом, нагрузка делится и распределяется по мирам/серверам почти равномерно и в итоге мы получаем максимальный онлайн в 6K-8K игроков (это максимум, в основном в разы меньше) и 200-300 запросов в “прайм”-тайм на один мир.

Такая структура с делением игроков по маркетам и мирам изживает себя, игрокам хочется чего-то глобального. В последних играх мы перестаём делить людей по странам и оставили только один/два маркета (Америка и Европа), но до сих пор со множеством миров в каждом. Следующим этапом будет разработка игр с новой архитектурой и объединением всех игроков в одном единственном мире с одной базой данных.

Сегодня я хотел немного рассказать о том, как мне была поставлена задача проверить, а что если весь онлайн (а это 50-200 тысяч пользователей одновременно) одной из наших популярных игр «отправить» играть в следующую игру, построенною на новой архитектуре и сможет ли вся система, в особенности база данных (PostgreSQL 11) практически выдержать такую нагрузку и, если не сможет, узнать, где же наш максимум. Расскажу немного о возникших проблемах и решениях подготовки к тестированию такого количества пользователей, самом процессе и немного о результатах.