Вы тест-менеджер, ведущий тестировщик или только планируете ими стать?
Значит, вам должны быть знакомы такие ситуации:
трудно найти подходящих сотрудников на проект, еще труднее начать им доверять;
в коллективе много хороших специалистов, но они не умеют работать в команде;
непонятно, кого и чему стоит обучать, а кому с вами не по пути;
сотрудники продолжают оправдываться и перекладывать ответственность на других;
на проекте высокая текучка;
удалённый формат работы вызывает сложности в коммуникации;
сотрудники не проявляют инициативы и вы вынуждены ходить за ними с кнутом.
> Узнали в чём-то свою команду?
> Устали ломать голову и искать теоретическое решение?
> Хочется реальной практики: с кейсами, инструментами и отработкой в деловых играх?
Двухдневный интенсив от Натальи Руколь и Анастасии Смирновой «Позитивное управление тест-командой» пройдет 29-30 августа в Санкт-Петербурге и 16-17 сентября в Киеве.
Тестирование удобства использования и доступности – это два зачастую игнорируемых типа тестирования приложений. Тестирование удобства использования относится к пользовательскому опыту и проверяет, насколько приложение легко в использовании и интуитивно понятно. Тестирование доступности проверяет, насколько легко пользователям с ограниченными возможностями взаимодействовать с приложением. Об обоих типах – в сегодняшней статье.
В конце марта в питерском офисе Wrike прошел Allure server meetup. В несколько часов удалось поместить концентрированную информацию по новому инструменту Allure server, по современным практикам работы с тестовой документацией и автотестами и по интересному опыту взаимодействия тестирования компании Wrike и нового вендора на рынке TMS систем.
Антон Башкиров (Wrike QA Lead) рассказал про концепцию и сам продукт Allure server, про то как наши потребности в быстрой и дешевой тестовой документации и централизованной работе с ней срастались и взаимно проникали с идеями команды qameta.io. Обрисовал дальнейшие наши планы по работе с Allure server.
Иван Варивода (Wrike QA automation) осветил очень важную для нас историю тестового карантина, позволяющего поставить на поток вывод из запусков, починку и возвращение стабилизированных автотестов. Опять же, это решение, построенное сначала отдельно от Allure server, и интегрированное в эту систему в коллаборации с разработчиками.
Для тех, кто не смог прийти, под катом публикуем видеозаписи докладов.
В прошлый раз я отвечал своей клиентке, тестировщице, работающей в организации, одержимой тест-кейсами. Назовем ее Фрида. У нее были другие вопросы насчет того, как отвечать своим тест-менеджерам.
Что, если они захотят, чтобы другой человек прогнал мои тесты, если я недоступна?
- Ваши тесты, или ваше тестирование? – спросил я.
- Насколько я понимаю, мои тесты. Я несогласна с этим, но пытаюсь посмотреть на вопрос с их точки зрения, - ответила Фрида.
Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Люди довольно серьезно настроены в отношении BDD. Я часто слышу, скажем, такие мнения:
"Зачем мне использовать BDD-фреймворк вместо традиционного – например, JUnit, NUnit, pytest? Дополнительный уровень шагов Gherkin мешает коду автоматизации, и вместо него я могу напрямую писать код для этих шагов. BDD-фреймворки требуют кучу лишней работы, а толку от этого никакого. Моя команда все равно не пользуется практиками разработки через реализацию поведения".
Я могу понять эти мнения, особенно в исполнении тех, кто участвовал в проекте с плохими BDD-практиками. Даже если команда не использует их во всей полноте, я все равно уверен, что BDD-фреймворки тест-автоматизации лучше, нежели традиционные, для большей части тестирования характеристик (на уровне выше юнит-тестов, для черного ящика). И вот почему.
Chrome - один из самых популярных браузеров на сегодня. По различным источникам его используют от 59% до 63% всех пользователей, в то время как следующий популярности имеет приблизительно 10%.
При тестировании веб-приложений любой сложности необходимо уметь пользоваться Chrome DevTools. Хоть этот инструмент и называется инструментом разработчика, в тестировании он также незаменим. С его помощью мы можем посмотреть структуру нашего сайта, поработать с JS-консолью, изучить исходящий http-трафик и много другое.
Как раз http-трафику посвящено это видео, из которого вы узнаете, что такое HTTP-протокол, какими характеристиками обладает http-запрос и многое другое.
Это и другие видео вы можете увидеть на нашем youtube-канале. Подписывайтесь, чтобы регулярно получать новые видео по тестированию!
Привет! Меня зовут Арсений Батыров, я работаю в Яндексе, а также веду курсы по тестированию. В работе мне часто приходится выбирать девайсы для проведения тестирования в различных условиях. Помимо очевидных параметров вроде dpi и ОС я часто опираюсь на статистику распространенности устройств, чтобы точно покрыть все наиболее популярные комбинации. В этой статье перечислены сервисы с различной статистикой, которыми я пользуюсь при подборе устройств. Если для вас эта проблема актуальна — добро пожаловать под кат.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Тестирование производительности, как и ряд другой терминологии тестирования ПО, может интерпретироваться по-разному разными людьми. Некоторые объединяют под этим термином все типы тестов, замеряющих поведение приложения, и включают в него нагрузку и стресс-тестирование. Прочие используют его, говоря об отклике приложения при обычных условиях. Я буду пользоваться вторым вариантом определения.
Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.
Интро
Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:
Недоделки. Это ошибки, которые допустили разработчики, пока пилили новый функционал. Такие ошибки находят при исследовательском или приемочном тестировании новых фич на девелоперских стендах команд.
Баги в регрессе. Это дефекты, которые находят ручные регрессионные тесты или автоматические UI и API тесты на стенде для интеграции кода.
Баги с прода. Это проблемы, которые нашли сотрудники или клиенты и обратились в службу технической поддержки.
Автор: Дейв Вестервельд (Dave Westerveld) Оригинал статьи Перевод: Ольга Алифанова
Уязвимости безопасности и сохранности данных – наибольшие риски, с которыми сталкивается любой продукт. Один публичный инцидент может разорить компанию, или, как минимум, нанести по ней серьезный удар – это помимо урона, нанесенного командному духу. Логично сделать вывод, что тестирование безопасности – это очень важно.
Однако не думаю, что вы пробовали в нем разобраться. Это довольно сложный, запутанный мир, и для того, чтобы стать эффективным тестировщиком безопасности, понадобится много специальных знаний и высокий уровень технической подготовки. Не у всех есть время или склонность к изучению необходимого минимума для этого рода тестирования, но это не значит, что мы не можем помочь повысить безопасность.
Хорошее тестирование дает на выходе более безопасный продукт. Множество угроз безопасности – межсайтовый скриптинг, сниффинг пакетов, SQL-инъекции – вы не найдете без хотя бы некоторых специальных знаний, но этим тестирование безопасности не ограничивается.
