А что за данные? Не проще ли их получать через API?

Причём вбил он без какого-то злого умысла, а просто "не подумав".

Даже в авиации защита "от дурака" одна из самых труднореализуемых задач. Наиболее эффективно она до сих пор решается тщательным отбором и обучением персонала. Можно, конечно, внедрить правила, что нельзя писать слово "хью" на заборе, но всегда может придти кто-то с другим словарным запасом и новыми идеями.

minidom весьма прожорливая до памяти библиотека и, имхо, не очень удобная. Попробуйте lxml

Обойдите дерево тэгов, если внутри корневых тэгов встречается тэг oldprice, ищите там price и делайте нужную проверку.

У меня несколько проектов на базе ТестКомплита. Документация ведется либо в обычном док-файле, либо в вики. 

Но вам действительно придется познавать все методом тыка, сочувствую. Но в помощь вам прекрасно разработанная документация по самому инструменту.

Ну это как правила хорошего тона. Никто же не пишет в вакансиях, что кандидат должен быть свеж по утрам, опрятно одет и т.п. Есть вещи, которые сами по себе подразумеваются. И даже если компания не использует общепринятый подход к проектированию (не знает еще о нем, например), то значит вы тот самый товарищ, который мог бы это изменить.

По-хорошему у каждой задачи помимо текущего статуса должно быть решение по нему. Напрмер, статус Closed может иметь решение или Fixed или Not a bug. Статусов не должно быть много, 4-5 обычно за глаза хватает. А вот решения могут быть разными для разных групп пользователей. В JIRA это прекрасно реализовано. Чтобы не было ошибок, нужно внимательно проработать воркфлоу задачи.

Если коротко, то нельзя.

Вообще считается, что надо найти некую волшебную область, которая вам очень понравится или - того хуже - Ваше Предназначение, и все пойдет как по маслу, но на самом деле это миф, не более правдивый, чем о половинках мэ и жо. 

Это не мифы :) Любое дело, которое нравится, будет спориться. Вдохновение - окрыляет. Это работает в любой области.

Но и это - "Хватит мечтать, займись делом!"  - тоже суровая и важная правда, потому что само ничего не приходит.

А пример исходного кода элемента можете показать?

У вас есть элемент h4 со значением 08pnlq - вам нужно проверить его наличие? 

Что вы подразумеваете под name? 

Cem Kaner - kaner@kaner.com

Просто глаз за вашу цифру зацепился. А вообще я отвечал Марине на ее сообщение выше. Идея в том, что не надо слепо рваться в столицы за длинным рублем. В моей команде работали тестировщики из Киргизии, Вьетнама, Филиппин, Индии само собой, Пакистана - из небольших городков и деревушек (а в масштабах земного шара это все вообще глухая провинция), было интересно их на карте находить. А наш ПМ был из Кении. Они там у себя на местах очень крутыми товарищами считались. 

А еще лично знаю многих, кто наоборот уезжает из столиц в провинцию, снижая тем самым удельный вес своих расходов, и бонусом получая хорошую экологию, а кто-то и море круглый год. 

Какие 20 тысяч?! Работа тестировщика начинается от 10$ в час - https://app.crossove...e-jobs?label=16 - это удаленная работа, то есть можете никуда не уезжать из своего условного Канбанограда. Это 90 тысяч рублей. ПРОБУЙТЕ!

Я так (там) работал почти два года. 

8 часов в офисе != 8 часов под контролем 

Контроль там как в шахматах - нажал кнопку на часах, делаешь ход (работаешь). Устал / надоело / решил сменить занятие - остановил часы. Главное отработать 40 часов в неделю. Это очень удобно, так как дает ощущение полного контроля своего времени. Других плюшек действительно нет :) 

Самый главный минус это то, что проект, на котором работаешь, может в любой момент остановиться или закрыться - например, стейкхолдер решил, что что-то пошло не так. Вас, конечно, уведомят за три дня, но потом полная неясность. Хотя, если себя хорошо зарекомендовали, то долго сидеть на скамейке запасных не будете. 

Со стороны кажется, что обсуждение идет по вопросу "Нужно ли 100%-е покрытие функционала тестами" и не отвечает на поставленный вопрос "Как, собственно, ускорить тесты?". Первый вопрос - философский и мировозренческий. Второй - чисто технический :)

Про построение процесса разработки, это вы правильно сказали. Собирался заняться этим одновременно с построением процесса тестирования. 

Так вы уточните свою роль тогда - тестирование или управление всем проектом?

Опишите подробно, как происходит подписание ЭЦП в вашем случае - просто отправляется файл с ключом, запускается какой-то софт или может еще как-то?

Если все происходит в браузере, то можете попробовать Selenium Webdriver (требует навыков программирования).

- при условии если установлен был NCALayer, подгружается путь к файлу где находится ЭЦП

Судя по этому, перед подписанием документа предварительно должен быть запущен NCLayer. Возможно, этот процесс тоже придется автоматизировать либо сделать, чтобы он был запущен всегда по умолчанию.

Если вы действительно что-то тестируете, то прислушайтесь к совету Романа (Spock).

А если вы ваяете какого-то бота, то Selenium IDE это вообще мимо. Такие штуки собираются индивидуально, по сути проектируется и пишется отдельный софт.

Значит должны быть тест-кейсы или чек-листы. Вот по ним и определите, что именно нужно проверять на странице.

Зависит от требований.

На одном проекте у всех лейблов проверяем не только значение, но и координаты на экране. А на другом вообще их не трогаем.

А вручную проверяли их? Или у вас сразу автоматизация идет?

Тогда сперва нужно понять, что у вас за приложение, что за лейблы, какие есть (задокументированные) требования к их отображению и т.п. 

Вообще есть какая-то тестовая документация? Как тестировали эти вещи вручную?

Из-за этого получается так, что тесты становятся очень большими и долго проходят. Я читал, что тест должен проверять основной функционал, а не все подряд что находится на странице. 

Тест должен проверять то, что требуется. 

Какая у вас проблема стоит:

- определить необходимость проверки лейблов?

или

- увеличить скорость прохождения тестов?

Прыткие молодые люди.

Что характерно - в списке вакансий этого проекта только менеджер продаж :))