Попробуйте найти элемент с помощью поиска элемента содержащего этот текст:

element = driver.findElement(By.xpath("//*[contains(text(),'" + comment + "')]"));

P.S. как я понял: comment - переменная, содержащая текст. Пример приведен на java.

Может кто-то со мной не согласится, но после тестового сценария должен быть 1 ожидаемый результат.

Чем больше логики закладываете в тесты, тем сложнее их будет поддерживать.

А разве разумно использовать ветвление в тестах?

Насколько я помню, они должны быть линейными.

Использование if, while - это должны быть исключительные ситуации.

xpath для страны 

//table//*[contains(text(), 'Russia')]

Это если не будет дублирования названия страны

Или так, с помощью объединения можно узнать справа стоящий документ

//table//*[contains(text(), 'Russia')] | //table//*[contains(text(), 'Dokument R')]

Можно код самой страницы если она локальная или хотя бы блока в котором находится этот textarea?

Ну или ссылку на страницу.

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

Можно почитать тут

Спасибо Оле Киселевой. 

Denwer -  локальный сервер (Apache, PHP, MySQL, Perl и т.д.) и программная оболочка, используемые Web-разработчиками для разработки сайтов на «домашней» (локальной) Windows-машине без необходимости выхода в Интернет.

CI - это некая программа, которая следит за вашим Source Control, и при появлении там изменений автоматически стягивает их, билдит, гоняет тесты (конечно, если их пишут). Ссылка на хабр

 

Антон, по первому пункту про отсутствие (или низкое качество) документации ситуация явно выходит за рамки обсуждения книги :). Если вернуться к контексту, то:
1) Я рассматриваю обучение "совсем начинающих" по аналогии с автошколой: сначала учим ПДД и "как правильно". Если есть желание ездить как в "Mad Max: Fury Road", то это это будет потом, в особых случаях при понимании и осознании всех условий и последтвий.
2) У начинающих тестировщиков и так часто бывает ступор, но информация о документации даёт хотя бы какой-то ориентир. Даже если документации нет: появляются идеи о том, какие вопросы задавать.

3) Чем больше будет людей, которых "с пелёнок" приучали к адекватным процессам, тем быстрее эти процессы станут адекватными. Да, не сразу. Но если ничего не предпринимать, ситуация точно не будет улучшаться.

 

1. Для начала, как мне кажется, нужно сначала показать новичку "автомобиль" и "дороги", чтобы он сам задал  правильный вопрос: "А как ездить по дороге?".

2. Стоит новичкам в одном предложении отметить, что в зависимости от ситуации может быть та или иная документация.

3. Абсолютно согласен, что надо приучать "с пеленок". Правда можно донести до читателя(новичка), что бывает не всегда так и стоит стремиться к таким "адекватным процессам".

Святослав, лично для себя считаю эту книгу весьма полезной, как справочник.

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

Я не имею такого опыта, как у вас, в прокачке 150-200 человек в год. Возможно в этой ситуации книга полезна.

Цель критики в адрес книги - сделать ее более понятной для новичков, так как информация в ней действительно полезная.

Алексей, спасибо за пояснение.

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

Судя по количеству вопросов от стажеров - нет.

Опираясь на Ваше мнение - нет.

Вывод очевиден. 

2.2.2. Важность требований

Продуктная документация (product documentation, development documentation49) используется проектной командой во время разработки и поддержки продукта.

Она включает:

o План проекта (project management plan50) и в том числе тестовый план (test plan51).

o Требования к программному продукту (product requirements document, PRD52) и функциональные спецификации (functional specifications53 document, FSD54; software requirements specification, SRS55).

o Архитектуру и дизайн (architecture and design56).

o Тест-кейсы и наборы тест-кейсов (test cases57 , test suites58).

o Технические спецификации (technical specifications59), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.

Отдал сегодня своим стажерам это на прочтение, на что получил закономерные вопросы:

- "А как тогда тестировать если всей этой документации нет?"

- "Бывают ли вообще проекты со всей этой документацией?"

- "А можно ли требовать это документацию?"

- "У кого ее требовать?"

На основе своих наблюдений пришел к выводу:

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

Впадет в ступор потому, что:

- документации всей может не быть

- вообще может не быть документации

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

- восприятие такой информации он может принять за общепринятую стандартизированную практику, которая применяется везде,

но в действительности это далеко не так.

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

"пункты 2 и 5 достаточно часто бывают, 3 реже, но тоже делают"

Так же один из фронтендщиков сказал такое: "А зачем вся эта документация для сайта-визитки?". 

Вроде бы он пошутил, но на самом деле стоит задуматься.

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

Так же хочу отметить, что 8 этапов в разделе "2.1.2. Жизненный цикл тестирования" перенасыщает начинающего тестировщика

информацией. Проще для понимания описано в книге Савина, там всего 3 пункта и они достаточно содержательны для базового понимания.

P.S. Все это исключительно личное мнение и наблюдение за своими стажерами.

Брать код регистрации(смс) можно и нужно из бд.

Про инструменты можно погуглить

1. robotium, appium - android  

2. UI Automation -IOS

Давайте посмотрим в корень проблемы, сайты на которые вас ведет редирект, сторонние?

Если нужно чекать ссылки на сайте попробуйте юзать Xenu, Screaming frog или аналогичные тулзы.

1. Стратегию тестирования описываю в тест-плане.

2. Работа отдела, Работы с ошибками, Написания сценариев и пр - это больше относится к внутренней документации отдела.

P.S. Это личные выводы.

Недавно на одном из приложений для IOS ввел всем известный набор символов "لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ

冗" - ничего не произошло. Но если удалить 2 последних символа то приложение падает, актуально для iphone 5s.

У знакомого IOS разработчика от этого набора символов xcode повис =)

P.S. Фейсбук запрещает публиковать этот текст

Yandex Tank работает на Ubuntu 12.04 LTS (Precise Pangolin) и Ubuntu 14.04 LTS - посмотрите в инструкцию

Ну к примеру, Вы бы могли разделить между тестировщиками некоторые "области ответственности" - каждый тестирует свою часть.

И по факту на продакшене узнаете, кто хорошо тестировал, а кто не очень.

P.S. Это сугубо личное мнение.

 (как это можно сделать, например, в testNG). 

 

Вы просили "например" - я ответил.

Как запилите в mocha TestNG - дайте знать

в TestNG можно 2мя способами

1. жесткая зависимостсь 

@Test
public void serverStartedOk() {}
 
@Test(dependsOnMethods = { "serverStartedOk" })
public void method1() {}

В таком случае если один упадет тест, то все зависимые тестовые методы не выполнятся

2. через priority

@Test(priority=1)
public void method1() {
		
}
 	
@Test(priority=2)
public void method2() {
		
}

В таком случаем выполнится тест с приоритетом 1, затем 2 и тд.

В вообще есть документация по TestNG

Так же есть видео от Алексея Баранцева по этой теме, правда тоже для TestNG

На одном из проектов доходило до 12 обновлений за 8 часов, тут уже не только глаз, но и что-то другое в мыле=)

Вариантов отвлечься не было, поэтому комбинировал, десктопные браузеры - смартфоны - беседа за чашкой кофе с разработчиками(в основном была беседа о проекте).

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

Я может что-то не понимаю, но Зачем проверять тот же самый функционал под разными ролями?
Одной проверкой првоеряешь, что функционал пашет.

Второй проверкой проверяешь, что роли имеет нужную сферу доступа до функционала.

Наверное потому, что может быть такой сценарий:

Выставил права в админ-панели, а в БД флаг не был установлен. Может быть так, что к БД нет доступа.

Как Вы в таком случае будете утверждать что эта роль имеет соответствующие права?

А вы думаете это просто проверять верстку автотестами?)

Ну оно то теоретически возможно, но оно того не стоит.

Проверьте можно ли закрыть алерт по нажатию клавиши Enter или Esc ?

Если да, то можно таким образом решить эту проблему, пускай и не так изящно.

Всем доброго времени суток.  

Ищем тестировщика, г.Воронеж.

Описание вакансии тут.

По всем вопросам, пишите в личку.