После неожиданного успеха цикла статей о ретроспективных уроках автоматизации мне показалось, что нужно уделить больше времени областям, в которых у меня достаточно опыта, и к которым я неравнодушен. Это исследовательское тестирование – или, как я буду называть это далее, просто исследование.
Зачем это нужно? Мне кажется, что я посылаю некоторым людям смешанные сигналы – мне пришлось отклонить ряд запросов на консультации по автоматизации, потому что люди решили, что я эксперт в этой сфере. Мне очень льстит быть так высоко оцененным, но положа руку на сердце, я не могу претендовать на эту честь. Я любитель-самоучка, у которого достаточно смелости на то, чтобы иметь мнение, и есть блог, где этим мнением можно поделиться. Что касается уровня моих навыков, я считаю, что они находятся на необходимом минимуме. В любом случае, я не разделяю взгляд на автоматизацию, сконцентрированный на инструментарии, и полагаю, что большая часть проблем, связанных с автотестами, в том, что люди недостаточно хорошо понимают тестирование. Ретроспективные уроки автоматизации отклонились от моей первоначальной цели – создания отсутствующего звена между тестированием и автоматизацией, слишком отойдя к технической стороне автотестов. Если основной задачей цикла была демонстрация, что имеет смысл автоматизировать для помощи тестированию, необходим еще один цикл, показывающий, что наиболее важно с точки зрения тестировщика, и что автоматизаторы должны знать о целях и сути экспертного тестирования.
Я решил, что этот цикл будет называться "Ретроспективные уроки исследовательского тестирования". Он также будет полезен тем, кого интересует исследовательская часть тестирования, и кто устал от просьб строго следовать сценариям, хотя толка от этого немного.
Можно ли автоматизировать всё, что угодно? Потом всех тестировщиков уволим, конечно. Зачем они теперь нужны, «ручного» тестирования не осталось. Правильно ведь?
Это рассказ о будущем тестирования с точки зрения DevOps. Здесь будут конкретные цифры и чисто практические выводы, как так получается, что у хороших специалистов всегда есть работа. (Или нет работы! Глядите на фотографию Шекспира и бойтесь, сейчас будет решаться ваша судьба).
В основе материала — расшифровка доклада Баруха jbaruch Садогурского, Developer Advocate в компании JFrog. Текстовая версия и видео доклада — под катом.
На конференциях, митапах и в социальных сетях тестировщики систематически сообщают мне, что они должны "дать добро" на продукт или деплой перед тем, как продукт выпущен в продакшен, или уйдет на ревью к клиенту. Тестировщики заявляют, что после того, как они проделали какую-то работу по тестированию, они должны "одобрить" или "отклонить" продукт. Вот типичный дословный отчет от одного из них:
"В моем нынешнем контексте, несмотря на мои обоснованные возражения, на меня смотрят как на привратника, и я нахожусь на такой позиции в рабочем процессе, которая буквальным образом предоставляет мне зеленую кнопку "одобрения" и красную кнопку "отклонения". Я должен выбрать нужную кнопку после "проведения контроля качества" рабочего продукта. Отдельным бонусом идет список противоречивых требований заказчика и/или набросок с кучей примечаний (зачастую противоречащих устным запросам, которые нигде не фиксировались)".
В этой части ретроспективных уроков автоматизации я продолжу рассуждать о принципах автоматизации и сконцентрируюсь на наиболее значимом из них (как минимум, по моему опыту) – на принципе изоляции тестов.
Один из моих читателей сообщил, что информацию об этом принципе можно найти также по запросу "Герметичный шаблон тестирования". Узнать больше можно здесь:
Дизайн мобильного приложения — один из главных факторов для пользователя, а значит и для разработчика. Хороший дизайн удерживает пользователя в приложении, плохой и нелогичный - заставляет его удалить. Ошибки дизайна, найденные в готовом приложении, исправлять очень дорого - ведь все приложение уже работает по установленным правилам. Поэтому тестировщик может помочь команде разработки, отметив возможные ошибки и неточности еще в момент их появления. Чтобы сделать процесс проще, создатели мобильных ОС сделали документы, где описаны основные принципы дизайна приложений и возможные трудности. Эти документы называются гайдлайнами, и хороший тестировщик должен иногда обращаться и к ним. В этом видео мы рассказываем о том, какие гайдлайны есть для Android и iOS:
Это и другие видео вы можете увидеть на нашем youtube-канале. Подписывайтесь, чтобы регулярно получать новые видео по тестированию!
Наша компания разрабатывает систему КОМПАС-3D для построения трехмерных моделей и чертежей. Проект зрелый – в этом году ему исполнилось 30 лет. Над продуктом работают 9 команд в двух городах – Коломне и Рязани.
В системе автоматизированного тестирования мы используем Telegram для уведомлений, управления тестами и администрирования. Технически боты реализованы очень просто. Главная ценность заключается в их интеграции с системой автотестирования. Итак, что у нас делают Telegram-боты.
Первый айфон увидел свет всего лишь чуть больше десяти лет назад. Теперь мы живем в веке, когда смартфоны расплодились повсеместно. Наши смартфоны – это швейцарские ножи: это карты, адресные книги, календари, камеры, плееры, и, конечно, средства коммуникации. Тестирование ПО будет неполным без тестирования на мобильных устройствах. В этом тестировании приходится учитывать столько всего, что я решила разбить статью на несколько частей, и сегодня я расскажу о сложностях мобильного тестирования. Затем мы перейдем к ручному тестированию, а потом – к автоматизированному.
Итак, сложности! Ниже перечислено двенадцать причин, благодаря которым тестировать на мобильных устройствах так сложно. Я решила, что будет забавнее иллюстрировать каждую из них, описывая баги, с которыми я сталкивалась. Некоторые из них были найдены в ходе моей работы, а некоторые – на моем личном устройстве, где я выступала как конечный пользователь.
Ещё недавно считалось, сервис должен просто работать. Нарисовали, заверстали, написали скрипты — вроде всё ок, можно катить на прод.
Но конкуренты не дремлют, поэтому начинается гонка не только за новыми функциями, но и за скоростью работы. Любое зависание приложения или долгий ответ сервера (не говоря уже про всплывающие 500-е ошибки) портят впечатление от сервиса и вынуждают пользователя уходить куда-то ещё. Наверняка, каждый сталкивался с ситуациями, когда вместо покупки билета на самолет, поезд или концерт на экране отображалось «Internal server error», и вы в ярости хотели разбить монитор.
Я — Виктор Бодров, работаю в Яндекс.Деньгах в команде исследований производительности и хочу рассказать о том, чем полезно изучать производительность прямо на продакшене
Все мы знаем, что перехват сессии – это очень плохо, и от него надо защищать себя и свои приложения. Однако удобопонятную информацию о том, что это такое и как это тестировать, найти трудно. В этой статье я опишу различные виды перехвата сессий, а затем дам пошаговую инструкцию, как тестировать на эту уязвимость, используя OWASP Juice Shop и Burp Suite.
Перехват сессий – это ситуация, когда злоумышленник получает доступ к авторизационной информации и использует ее, чтобы представиться другим пользователем или получить доступ к информации, которого быть не должно. Перехват бывает разных видов:
16 марта прошла вторая встреча PHP-сообщества в офисе Badoo. По правде говоря, получилась целая мини-конференция — так много участников было в этот раз.
Обсуждали вопросы автотестов для PHP-разработчиков, разбирали реальные кейсы из практики, дискутировали о качестве кода и много общались. Спасибо участникам и спикерам за полезную субботу!
Под катом — слайды, записи докладов и панельная дискуссия со спикерами из Badoo, EPAM, Avito и Lamoda.
