В прошлый раз я отвечал своей клиентке, тестировщице, работающей в организации, одержимой тест-кейсами. Назовем ее Фрида. У нее были другие вопросы насчет того, как отвечать своим тест-менеджерам.
Что, если они захотят, чтобы другой человек прогнал мои тесты, если я недоступна?
- Ваши тесты, или ваше тестирование? – спросил я.
- Насколько я понимаю, мои тесты. Я несогласна с этим, но пытаюсь посмотреть на вопрос с их точки зрения, - ответила Фрида.
Должен признаться: я читаю 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-инъекции – вы не найдете без хотя бы некоторых специальных знаний, но этим тестирование безопасности не ограничивается.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Тестирование безопасности на мобильных устройствах – сложная задача для тестировщика. В нем объединяются проблемы мобильных устройств и сложности тестирования безопасности. Вот, к примеру, ряд сложностей, о которых я узнала, исследуя вопрос:
Мобильные устройства изначально более безопасны по сравнению с традиционными веб-приложениями, потому что это личная вещь пользователя. Из-за этого куда сложнее "заглянуть под капот", чтобы увидеть, как работает приложение.
Из-за вышеописанной сложности тестирование мобильной безопасности зачастую требует инструментов, которых у среднестатистического тестировщика может и не быть под рукой – к примеру, XCode Tools или Android Studio. Тестирование безопасности на физическом устройстве может также требовать рутованного или джейл-брейк телефона (это телефон, измененный таким образом, что пользователь получает администраторские права или устраняет пользовательские ограничения. Рут-права можно получить на Android, а джейл-брейк провести для iPhone. Нет, не делайте этого со своим личным устройством).
Сложно найти информацию по тестированию мобильной безопасности, если вы начинающий – большая часть документации предполагает, что вы уже достаточно хорошо ориентируетесь в продвинутых концепциях тестирования безопасности или разработке мобильных приложений.
Меня зовут Виталий Котов, я довольно много занимаюсь автоматизацией тестирования и мне это нравится. Недавно я участвовал в проекте по настройке автоматизации «с нуля» на стеке TypeScript + Protractor + Jasmine. Для меня этот стек был новым и необходимую информацию я искал на просторах интернета.
Самые полезные и толковые мануалы мне удалось найти только на английском языке. Я решил, что на русском тоже надо такой сделать. Расскажу только основы: почему именно такой стек, что надо настроить и как выглядит самый простой тест.
Сразу оговорюсь, что довольно редко работаю с NodeJS, npm и в целом с серверным JavaScript (тем более с TypeScript). Если где-то найдете ошибку в терминологии или какое-то из моих решений можно улучшить — буду рад узнать об этом в комментариях от более опытных ребят.
