Автор: Баз Дейкстра (Bas Djikstra) Оригинал статьи Перевод: Ольга Алифанова
В этой короткой серии статей я исследую библиотеку Python requests и ее использование для тестов REST API. Это четвертая статья в серии, и в ней мы разберемся с имитацией ответов для юнит-тестирования.
Любой компании необходим взгляд со стороны на состояние информационной безопасности сервисов и продуктов. Эту задачу можно решить разными способами, один из которых — участие в Bug Bounty программах.
Bug Bounty программа как свежая сила в деле багхантинга
Bug Bounty («вознаграждение за ошибку») — это программа, которая предусматривает денежное вознаграждение или другие бенефиты за нахождение багов, эксплойтов и уязвимостей в работе ПО. Программы Bug Bounty реализованы многими компаниями, в том числе Facebook, Google, Reddit, Apple, Microsoft и др.
Автор: Баз Дейкстра (Bas Djikstra) Оригинал статьи Перевод: Ольга Алифанова
Если вы пишете тесты Selenium на C#, то, возможно, заметили, что начиная с версии 3.11 ряд часто используемых штук помечен как устаревший – в частности, PageFactory и класс ExpectedConditions. Для тех, кто не знает, почему это произошло – вот объяснение Джима Эванса, основного разработчика связки Selenium C#.
Все это перемещено в новое место и доступно в форме отдельных пакетов NuGet (DotNetSeleniumExtras.PageObjects и DotNetSeleniumExtras.WaitHelpers, соответственно). Когда я писал эту статью, этот репозиторий никто не поддерживал – а следовательно, поддержка недоступна, и будущее его туманно.
Мы – Владимир Мясников и Владислав Егоров — представители команды интеграционного тестирования Mir Plat.Form (АО «НСПК»). Сегодня мы расскажем про разработанный и развиваемый нами инструмент автоматизации, позволивший сократить рутину во внутренних процессах команды.
Предисловие
Платёжная экосистема Mir Plat.Form включает в себя несколько десятков систем, большинство из которых взаимодействуют между собой по различным протоколам и форматам. Мы, команда интеграционного тестирования, проверяем соответствие этих взаимодействий установленным требованиям.
На данный момент команда работает с 13 системами уровня mission и business critical. Mission critical системы обеспечивают выполнение Mir Plat.Form своих основных функций, обеспечивающих стабильность и непрерывность функционирования банковской карточной системы РФ. Системы уровня business critical отвечают за поддержку предоставляемых клиентам Mir Plat.form дополнительных сервисов, от которых зависит непосредственная операционная деятельность компании. Частота выкатывания релизов в ПРОД варьируется от раза в неделю до раза в квартал, всё зависит от системы и готовности участников к частоте обновлений. В общей сложности мы насчитали около 200 релизов, прошедших через нашу команду в прошлом году.
Автор: Рикард Эдгрен (Rikard Edgren) Оригинал статьи Перевод: Ольга Алифанова
На EuroSTAR 2019 я читал доклад о характеристиках качества вместе с Хенриком Эмильссоном. Больше всего в этих конференциях мне нравится то, что ты никогда не знаешь, что произойдет. Как-то раз я закончил свой ответ фразой "если тестировать легко, вы что-то не так делаете". Помню, как доволен я был, сказав это. Эта фраза отлично подходила для контекста, в каком-то смысле подытоживая мое отношение к тестированию и причины, по которым я его так люблю.
Я забыл об этом, читая лекцию, но вспомнил, когда мы получили обратную связь от аудитории. Обратная связь была очень хорошей, но всем понравиться нельзя (если это происходит, вы что-то делаете не так).
Один из участников (не помню, кто, да это и не важно) был очень негативно настроен и сказал, что говоря, что "если тестировать легко – вы что-то делаете не так", мы показываем себя плохими, непрофессиональными тестировщиками.
Настало время объяснить, что я имею в виду. Кто-то наверняка со мной не согласится, но это может привести к интересным обсуждениям (или неконструктивным комментариям).
Всем привет! Меня зовут Егор Иванов, и я специалист по автоматизации тестирования. Довольно долгое время до этого я проработал в различных компаниях из сферы BI. Я обожаю визуализацию данных и считаю, что без нее невозможно строить рабочие процессы и уж тем более процессы в тестировании. Поэтому хочу, чтобы ее использовали как можно больше людей, так как визуализация данных очень важна, а в виде дашбордов она еще и прекрасна.
Надеюсь, материал будет полезен и для тех, кто уже использует дашборд, — возможно, вы увидите новое применение для этого инструмента. А те, кто незнаком с ним, познакомятся и, возможно, также начнут его использовать.
Многие из нас видят дашборд каждый день. Он пришел к нам из транспорта — это приборная панель автомобиля.
Слева - дашборд автомобиля, справа - информационный дашборд в IT
Автор: Мэтт Хойссер (Matt Heusser) Оригинал статьи Перевод: Ольга Алифанова
"Не можем ли мы в сообществе разделять функциональное/исследовательское/юзабилити-тестирование и регрессионные проверки?"
(твиттер Мэтта Хойссера)
Недавно я побывал на SauceCon, ежегодной конференции Sauce Labs. Sauce предоставляет платформу (и облачные мобильные устройства при необходимости) для запуска скриптов Selenium. Слушая, как докладчик говорил о "тестировании", не проводя черту между регрессом и функциональным тестированием, я написал об этом твит.
Знаю, знаю, есть множество типов тестирования, а не только эти два, как мог я забыть про тестирование производительности, безопасности, и так далее, и тому подобное! Вот он, ужасный я, "всего лишь" упоминающий "функциональное" тестирование. Ладно, хорошо, но я так-то не об этом.
Я хочу рассказать о двух тонких различиях и объяснить, почему они важны.
Привет! Меня зовут Мария Лещинская, я QA-специалист в Surf. Наша компания разрабатывает нативные приложения с 2011 года, а с 2018-го мы занимаемся ещё и разработкой под Flutter.
В этом материале сравним возможности тестирования нативных и кроссплатформенных приложений. Я поделюсь впечатлениями от работы с Flutter и расскажу, какие инструменты мы в Surf используем при тестировании, чем Flutter удобен и с какими проблемами мы столкнулись.
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
В ходе карьеры мне задавали массу вопросов о тест-архитектуре: как начать тестировать, если ничего не делалось годами? Сколько тест-проектов должно быть? Сколько различных типов тестирования нам нужно? Кто должен отвечать за тестирование в процентном соотношении? Как масштабировать тестирование? Как разобраться с большими приложениями? Как разобраться с существующими тестами, если в них черт ногу сломит? Какими инструментами пользоваться? В каком количестве браузеров надо тестировать (их что, больше двух?!)
Начнем с начала: все приложения уникальны, каждая компания имеет свою структуру, свои ресурсы и бюджет, и все компании находятся на разных стадиях зрелости (это не значит, что они должны стремиться на следующую ступень – возможно, они находятся именно там, где должны). Тут не существует универсальных решений, и поэтому я рекомендую проконсультироваться с экспертом. Но я хочу поделиться своим прошлым опытом на случай, если вам это поможет.
В современном мире программных разработок важность API-интерфейсов является очевидной практически для любого специалиста. Данные интерфейсы дают возможность любым двум отдельным приложениям легко обмениваться данными друг с другом, а также упрощают пользователям приложения выполнение привычных действий без использования графического интерфейса приложения.
