На прошедшем Я.Субботнике по тестированию, который проходил в Нижнем Новгороде 28 января, сотрудники компании Яндекс и приглашенные спикеры делились опытом работы в интересующей нас области. Темы докладов были разнообразными и интересными. Убедитесь сами - ниже вы можете ознакомиться с опубликованными материалами:
Облачные тестовые среды Яндекс.Маркета, Олег Бекетов, Яндекс
Тестирование веб-приложений интересно тем, что оно требует наиболее широкого владения различными видами тестирования. Одно из ключевых мест занимает тестирование защищенности (security testing) или проверка отсутствия известных уязвимостей.
Почему тестирование защищенности имеет такое большое значение именно для веб-приложений?
Веб-приложения ориентированы на массовое использование, поэтому сбои в работе, вызванные действиями злоумышленника, могут оказать негативное воздействие на большое количество ни в чём неповинных пользователей.
Веб-приложения могут хранить конфиденциальную информацию, утечка этих данных может иметь очень серьёзные последствия.
Доступ к веб-приложению имеет множество “недоверенных” пользователей, при этом владельцы или разработчики приложения как правило не могут контролировать или ограничивать их действия.
Обмен информацией между браузером и сервером происходит по открытым каналам с использованием открытых протоколов, поэтому сложно контролировать данные, передаваемые клиентами.
Разработка веб-приложений не всегда ведётся с должным вниманием к обеспечению защищенности и надёжности, потому что рынок в первую очередь требует “быстро”!
Разумеется, тестирование защищенности не ограничивается тестированием самого веб-приложения. Уязвимость может находиться в веб-сервере, операционной системе, почтовой системе, ftp-сервере или ещё где-то. Но задача создания защищенного окружения в большей степени находится в зоне ответственности системных администраторов, а вот защищенность вашего собственного веб-приложения -- целиком на совести его разработчиков и тестировщиков.
На тренинге мы рассмотрим как общие принципы компроментации защиты веб-приложений, так и отдельные наиболее распространенные виды уязвимостей, которые могут быть использованы даже не слишком квалифицированным злоумышленником, что существенно повышает вероятность их эксплуатации.
У многих тестировщиков, а также и у многих менеджеров, при звуке слов "автоматизация тестирования" в мозгу возникает идиллическая картинка в стиле научно-фантастических романов: роботы выполняют рутинную и тяжёлую работу, а человек занимается интеллектуальным или творческим трудом.
Но это никакая не фантастика, это вполне реально и достижимо!
Да, можно освободить тестировщиков от выполнения некоторых типовых задач, переложив эту работу на плечи роботов. Таких рутинных действий тестировщик совершает больше, чем кажется на первый взгляд. Автоматизировать можно не только собственно выполнение тестов, но и подготовку тестового стенда, генерацию тестовых данных большого объёма или высокой сложности, помощь в проверке результатов, полученных при ручном тестировании (сравнение текстов, картинок), создание отчётов или иных документов.
Однако нельзя просто пойти и купить робота, который начнёт немедленно приносить вам пользу. Можно либо взять "универсального" робота и обучить его, либо взять конструктор и собрать узкоспециализированный автомат для решения ваших конкретных задач.
Процесс внедрения автоматизации – это как раз и есть процесс создания или обучения роботов.
Внедрение автоматизации затрагивает многие стороны процесса разработки. Это отнюдь не чисто инженерная задача, требующая только владения инструментами автоматизации и навыками программирования.
Прежде чем перейти к технической части, необходимо выбрать оптимальную стратегию внедрения и дальнейшего развития автоматизированных тестов. Нужно скоординировать работы по автоматизациями с деятельностью специалистов по ручному тестированию, потому что предстоит провести отбор тестов для автоматизации, а может быть и переработку этих тестов. Предстоит также согласовать свои действия с разработчиками, а может быть даже договориться о специальных доработках тестируемого приложения для более удобной автоматизации.
Ну и конечно без инженеров в этом деле не обойтись. Правильно выбрать средства автоматизации, интегрировать с инструментами групповой работы (баг-трекер, сервер непрерывной интеграции, системы отчётности) – при решении этих технических задач талант инженера-автоматизатора может раскрыться в полной мере.
Но главная опасность подстерегает впереди – рано или поздно станет ясно, насколько оправданным и экономически целесообразным оказалось внедрение автоматизации в тестирование. Нужно будет оценить достигнутые результаты и принять новые решения относительно дальнейшего развития систем автоматизации.
Чтобы научить вас правильно планировать процесс внедрения автоматизации, успешно решать технические задачи и адекватно оценивать текущее состояние процесса мы разработали тренинг, особенность которого заключается в том, что его ведут два тренера – "менеджер" и "инженер".
Это позволит вам увидеть проблемы, которые возникают при внедрении автоматизации тестирования, с двух разных (можно даже сказать противоположных) точек зрения.
Тренинг будет полезен всем, кто внедряет с нуля или улучшает текущие подходы к организации автоматизированного тестирования: тест-менеджерам, специалистам по автоматизации и тест-дизайнерам, взаимодействующим с группой автоматизации.
Пользователь JIRA не видит клиентов в списке Clients при создании заявки.
Можно сделать это поле необязательным, тогда заявки создаются.
Но это - не вариант, должна быть привязка к Клиенту.
Какие нужны права и настройки, чтобы пользователи видели клиентов в списке?