Что дает объединение ручного и автоматизированного тестирования: опыт
Новые темы форума тестировщиков
Автор: Дмитрий Богачев
Читая статьи на тему web-тестирования, вырисовываются условно две темы: 1) ручное тестирование вымирает, автотесты (здесь и далее под автотестами имеются в виду Selenium UI и REST-тесты) – наше все; 2) автоматическое тестирование – не панацея, без ручного тестирования не обойтись. При этом из статей намечается тенденция на рост требований к качеству программного обеспечения и скорости развития продукта. Wrike — это как раз тот случай, когда эти требования критически важны.
Поиск инструментария тестировщиков для установки на мобильных устройст 2019-11-28 16:04 Добрый день. Просто дстало!
Дано: QC 11-й версии с большим набором документированных тестов проекта, багов, версий проекта и т.п. Некоторые сценарии просты, некоторые довольно запутанные; некоторые имеют 8-10 стэпов, некоторые - по 30. Во многих сценариях следует проверять точное соответствие сообщений системы требованиям спецификаций на 4-ёх языках.
Короче, при тестировании ОБЯЗАТЕЛЬНО нужно одним носом торчать в сценарии, а другим - в системе.
Проблема: система - embedded (банкоматы) и стоят они далеко от места работы тестировщиков и в разных местах. Приходится распечатывать сценарии (делить их между работниками) и пальчиком водить по ним во время тестирования, записывать баг на бумажечке (или в мыле) с последующим переписыванием или копированием... Короче: достало! Сам искал - не нашёл ничего.
Имею желание: - по максимуму - хочу инструментарий - программу для смартфона, интегрированную с сервером QC, чтобы позволял "бежать" существующие сценарии на смартфоне и там же открывать баги. - по мимимому - хоть какой-то мобильный тул с серверной частью, чтобы синхронизировать работу разных тестировщиков по запуску сценариев и открытию багов.
Вопрос: прежде, чем я заставлю своих больших поцев обратиться в Меркюри, может быть, кто-то уже изобрёл этот велосипед и решил схожую проблему?
Заранее спасибо.
Как грамотно построить архитектуру автотестов? 2019-11-28 17:01 Всем доброго времени суток! Не первый раз слышу от многих (более опытных) коллег в сети, что нужно строить архитектуру автотестов так же как и архитектуру основного ПО, в том смысле, что (внезапно) автотесты - это точно такое же ПО (только более узкоспециализированное) и оно подвержено точно таким же проблемам и особенностям как и обычное ПО. Есть наиболее распространенные паттерны проектирования, такие как, например, PageObject'ы, DataProvider'ы, etc. Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест? © 2010 | Software-Testing.Ru |
| В избранное | ||
