Громкий бренд или имя спикера с высокой должностью помогают заполнить конференц-залы. Люди тянутся к “звездам”, чтобы быть в тренде и узнать об их ошибках и победах. Только вот в конце выступлений участники ставят таким спикерам далеко не самые высокие оценки.
В студии создания презентаций и инфографики VisualMethod выяснили у предпринимателей и корпоративных сотрудников, что больше всего их разочаровало в докладах на конференциях. Оказалось, когда опытные спикеры игнорируют организационные слайды и переходят сразу к описанию процесса или кейса, теряется доверие. Некоторые опрошенные даже назвали такое поведение спикеров высокомерным (“не представился вообще”) и невнимательным (“в теме одно, а на словах другое”). Подробно рассказываем о том, о каких слайдах важно помнить.

Проверка платных сервисов — один из ключевых инженерных вопросов в тестировании Badoo. Наше приложение интегрировано с 70 платёжными провайдерами в 250 странах мира, и баг хотя бы в одном из них может привести к непредсказуемым последствиям. 

В этой статье я расскажу о методах тестирования, которые мы используем в Badoo, и о границах применимости этих методов — этапах тестирования, на которых они максимально эффективны. 

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

Всем привет. Мы потихоньку выходим из тени и продолжаем серию статей о нашем продукте. После предыдущей обзорной статьи мы получили множество отзывов (преимущественно положительных), предложений и bug репортов. Сегодня мы покажем TestMace в деле и вы по достоинству сможете оценить некоторые фишки нашего приложения. Для более полного погружения советую обратиться к нашей документации по адресу http://docs-ru.testmace.com. Итак, поехали!

Привет, Хабр! Меня зовут Павел Лесюк. Я занимаюсь ручным и автоматизированным тестированием мобильных приложений, а также стараюсь автоматизировать рутинные действия, которые приходится выполнять из раза в раз. В целом я стараюсь сделать свою работу максимально эффективной и продуктивной. Во всем этом мне помогают запрещенные вещества вспомогательные инструменты разных направленностей.

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

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

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

Крупные компании в IT порой покрывают целиком территорию нашей страны. Такой масштаб требует постоянного изменения подходов, пересмотра ценностей. Конечно, не в каждой компании, но точно во многих проектах. А как известно, по ценностям впереди планеты всей – Япония.

Эта статья предназначена для интересующихся проектным управлением, практиков и теоретиков. Она позволит ознакомиться с японской методологией P2M (Project & Program Management for Enterprise Innovation), отличающейся от привычных западных подходов, в том числе ориентацией на создание дополнительных ценностей для компании и прямой корреляцией производимых изменений бизнеса с миссией предприятия.

Источник

Мы в Альфастраховании используем SAP ERP как процессную систему урегулирования убытков. И так уж получилось, что мы ее немножко дорабатываем, это неизбежно приводит к возникновению в коде ошибок. Если ошибки доходят до продуктивной системы — это плохо. Этого надо избегать, один из способов — регрессионное тестирование. В этой статье я расскажу о том, как именно мы проводим "регресс" для SAP, потому что делаем мы это (эх!) нестандартно.

Началось все это несколько лет назад. В те годы мы уже активно использовали регрессионное тестирование, но никак не могли сделать этого в SAP — используемые инструменты с SAP-ом не работали, изучать "заточенные" под SAP инструменты команда тестировщиков что-то не хотела. Уже точно и не вспомню почему, но я воспринял это как вызов (это было еще до того, как я переключился на дата инженерию) и решил "изучить" вопрос.

Результаты изучения (а также "делания") — в этой статье (ниже), кратко скажу так: мы автоматически тестируем SAP (и его ближайшее окружение), делаем это достаточно эффективно (во всех смыслах), мы не потратили ни рубля на лицензии и обучение, наш подход прост и вполне воспроизводим. И мы не используем никакие инструменты SAP для автоматического тестирования SAP (разве что в том месте, где мы встроились в его транспортную систему).

Фреймворк redux-saga предоставляет кучу интересных паттернов для работы с сайд-эффектами, но, как истинные кроваво-энтерпрайзные разработчики, мы должны покрывать весь свой код тестами. Давайте разберёмся, как мы будем тестировать наши саги.

Написание тестов должно вселять в нас уверенность в корректной работе кода. Часто мы оперируем степенью покрытости кода, и когда достигаем 100 %, то можем сказать, что решение корректное. Уверены в этом? Быть может, есть инструмент, который даст более точную обратную связь?

Поговорим о JMeter’е? Скорее всего, если вы в теме, то давно уже прочли всё об этом инструменте для нагрузочного тестирования. Но мне есть чем вас удивить. За три года работы в QA я понял, что JMeter очень универсален и может использоваться в самых разных целях. Например, для:

• поиска неуловимого бага с падением сайта у части юзеров;
• быстрого прогрева кэша на тысячах продуктовых страниц;
• тестирования бэкенда мобильного приложения;
• создания 2000 записей с данными пользователей в базе приложения в сжатые сроки.

Если заинтересовались — добро пожаловать под кат. Получилось объемно, поэтому разобью статью на две части.

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

Салют! Уже на следующей неделе стартуют занятия в новом потоке курса «QA-специалист», в связи с этим делимся с вами полезным материалом, переведенным специально для студентов курса. Поехали.

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

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

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



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

Этих людей часто объединяет то, что в свое время им попался плохой учитель в школе или плохой ментор уже на карьерном пути.

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

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

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

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



Думай медленно, решай быстро — Даниэль Канеман
Это самое волшебное, что случалось за последние годы в плане гиковой литературы. Эта штука последовательно открывает когнитивные искажения и учит настраивать мышление. При этом увлекательно. Вообще, подход к тому, что мышление — это набор техник, которые можно тренировать и оттачивать, он, наверное, правильнее подхода «это шаманство». Канеман в отличие от следующей в списке книги, показывающей особенности реверсивного мышления, не даёт новых техник — но показывает, где и какие ошибки мы совершаем при обычных процессах. Такой серьёзный дебаг мозга.

Кто про что, а я про баги.

В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Краткая предыстория

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

def test_dist():
    p1 = (0, 3)
    p2 = (4, 0)
    assert dist(p1, p2) == 5

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

Это приводит нас к генеративному тестированию (generative testing): написанию тестов, покрывающих случайное множество в пространстве состояний. Самым популярным стилем генеративного тестирования является property based testing, или PBT. Мы находим «свойство» (property) функции, а затем генерируем входные значения и проверяем, соответствуют ли выходные значения этому свойству.

def test_dist():
    p1 = random_point()
    p2 = random_point()
    assert dist(p1, p2) >= 0

Преимущество PBT заключается в покрытии большего пространства. Его недостаток — утеря специфичности. Это уже не оракул-тест! Мы не знаем, каким должен быть ответ, и функция может быть ошибочна, но таким образом, что обладает тем же свойством. Здесь мы полагаемся на эвристики.

Прежде чем взяться за работу над user story, очень важно определить для себя критерии приемки. Это можно сделать, когда вы детализируете бэклог или планируете  ближайший спринт. Некоторые команды для этого проводят специальные встречи, которые называются 3 Амиго (подробнее о них в прошлой статье), митинги, kick-off по спецификации или встречи-исследования.

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

Но есть простой способ сделать такие встречи короткими и очень продуктивными. И называется этот способ Example Mapping или составление карт тест-кейсов.

Продолжаем рассказывать о полезных инструментах для пентестера. В новой статье мы рассмотрим инструменты для анализа защищенности веб-приложений.

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

LogRock: Тестирование через логирование

Уже более 2-х лет мы работаем над своим проектом Cleverbrush. Это софт для работы с векторной графикой. Работа с графическим редактором подразумевает огромное количество вариантов использования приложения. Мы пытаемся экономить деньги и время, поэтому оптимизируем все, в том числе тестирование. Покрывать тест кейсами каждый вариант это слишком дорого и нерационально, тем более что все варианты покрыть невозможно.

В ходе разработки был создан модуль для React JS приложений — LogRock (github).

Этот модуль позволяет организовать современное логирование приложения. На основании логов мы производим тестирование. В этой статье я расскажу Вам о тонкостях использования данного модуля и как организовать тестирование через логирование.

На Хабре есть публикация, описывающая написание тестов с использованием Puppeteer и Jest. Рекомендую к ознакомлению, если вы ещё не знаете, что такое Puppeteer. В данной статье, на примере React-компонента, будет описываться способ тестирования вызовов callback-функций. Например, есть компонент с props onChange, и необходимо протестировать, что при некоторых действия пользователя будет вызвана callback-функция с ожидаемыми переданными параметрами. Для этого будет использоваться библиотека Puppeteer-io. Но для начала рассмотрим небольшой примерчик на html и чистом javascript без привязки к библиотекам или фреймворкам…