fullsize – Страница 3

Почему тестировщики – это тоже разработчики 5

admin26.11.201526.11.20155 комментариев

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

Похоже, что "виной" тому - Scrum. Дело в том, что одно из базовых понятий Scrum-е - Developement Team (команда разработчиков). Теперь если понимать это буквально и консервативно - то выходит, что Development Team состоит только из людей, которые умеют программировать (к сожалению, много людей поверхностно понимающих Scrum именно так и думают). Что в корне ошибочно - на самом деле в команду входят все вышеперечисленные роли, если они важны для успешной реализации требований проекта.

Логичный выход из ситуации для меня - считать и называть "разработчиками" всех, кто принимает участие! В некоторых случаях это будет даже представитель клиента (если он является частью Scrum команды). Scrum безумно популярен в мире, поэтому приходится это учитывать. А если бы не он, возможно, я бы не был против называть разработчиками только программистов.

Ну и вообще, почему бы и нет?

Ошибка номер 1 в автотестах.

admin28.10.201529.10.2015Оставить комментарий

Эту ошибку при написании ui автотестов я, как мне кажется, встречаю чаще
всего.

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

Представьте, у вас есть такой простой набор тестов.

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

1 2	Заполнить корзину товарами - убедиться, что существует кнопка, на которой написано "Оплатить" Очистить корзину от товаров - убедиться, что существует кнопка, на которой написано "Оплатить" и она "disabled".

Набор чеков в коде, в стиле Selenide, будет примерно таким:

fill_shopping_cart();
button.shouldBe(visible)
      .shouldHaveText("Оплатить");
empty_shopping_cart();
button.shouldBe(visible)
      .shouldHaveText("Оплатить")
      .shouldBe(disabled);

fill_shopping_cart();

button.shouldBe(visible)

.shouldHaveText("Оплатить");

empty_shopping_cart();

button.shouldBe(visible)

.shouldHaveText("Оплатить")

.shouldBe(disabled);

Видите ошибку?

Если вы просто повторили язык теста, то чеки пройдут положительно и тест будет "зелёненьким", даже когда "Оплатить" будет всегда "disabled" (в частности, после выполнения заполнения корзины).

Более правильным, конечно, будет вариант

fill_shopping_cart();
button.shouldBe(visible)
      .shouldHaveText("Оплатить")
      .shouldBe(enabled);
empty_shopping_cart();
button.shouldBe(visible)
      .shouldHaveText("Оплатить")
      .shouldBe(disabled);

fill_shopping_cart();

button.shouldBe(visible)

.shouldHaveText("Оплатить")

.shouldBe(enabled);

empty_shopping_cart();

button.shouldBe(visible)

.shouldHaveText("Оплатить")

.shouldBe(disabled);

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

Походные заметки про простое тестирование

admin02.10.201506.10.2015Оставить комментарий

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

А вы говорите не нужны юнит-тесты.

Дали мне сегодня весь проект запустить. Скачал из git. Запустил на сборку. Выдаёт ошибку в юнит-тесте.
Окей - говорю программистам. У нас не выдаёт, отвечают. Запускают - действительно не выдаёт, у меня при запуске теста из IDE тоже не выдаёт. А из командной строки - выдает. Программисты, хотите упражнение? Метод модифицирует web элемент таг с атрибутами вроде:

<a attr1="abc" attr2="cde" />

1	<a attr1="abc" attr2="cde" />

И assert сравнивает строковый результат, и у меня из командной строки валится потому что атрибут один меняет порядок (сперва attr2, затем attr1). Примерно так:

<a attr2="cde" attr1="abc" />

1	<a attr2="cde" attr1="abc" />

Симптомы - выше (где-то меняет, где-то не меняет). В чем проблема? Решение ниже.

...читать далее Походные заметки про простое тестирование

Тестирование и возраст – “Тестировщик суперстар” 1

admin06.09.201507.09.20151 комментарий

Записали выпуск Radio QA про тестирование и годы.

http://radio-qa.com/vypusk-9-testirovshhik-superstar/
А как считаете вы? С возрастом тестировщикам становится тяжелее или проще? Заполняйте опросы и пишите ваше мнение в комментах!

О чем нужно не забывать, применяя Agile Manifesto к тестированию. 1

admin12.08.20151 комментарий

По мотивам ленты о тестировании подумалось:

Две самых крупных ошибки этого поста

Выделение из 4 столпов Agile манифеста "двух ключевых".
И что гораздо хуже, вычленение тестирования от процесса разработки (уж особенно в Agile)

Я думаю, пост должен помочь продавать тестирование в Agile-проект заказчикам, что я в принципе приветствую. Но не любыми же средствами :).

Запомните, тестирование - это часть процесса разработки. Я считаю, что Agile разработку нужно продавать, включая в неё тестирование без искусственного отделения от программирования.

Как отличать хорошего тестировщика от плохого?

admin10.08.201510.08.2015Оставить комментарий

Вот сказанул тут в чатике, а они это раз - и на картинку!А вы что думаете? Огрехи программиста увидеть проще, чем огрехи тестировщика или есть тонкости?

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

Анонс Radio QA: Как развиваться тестировщику?

admin13.07.2015Оставить комментарий

Многие наверное уже слышали, что в ближайшем выпуске подкаста Radio QA Андрей Солнцев, автор UI-Testing фрейморка Selenide будет проводить тестирование экспертов. Заключаться это "тестирование" будет в том, что молодой и любознательный тестировщик Александр подготовил набор коварных вопросов по разным темам ручного тестирования. Эксперты должны будут в прямом эфире не упасть лицом в грязь и ответить на вопросы так, чтобы Александр понял ответ 🙂 Вести выпуск будет Андрей, а в качестве экспертов приглашены директор по качеству Mail.ru Алексей Петров, живущий сейчас в Тайланде инженер Стас Катков (многолетний опыт в тестировании) и ваш покорный слуга.

Начало эфира в 17:30 мск, в четверг, 16 июля. Приходите на прямой эфир, там можно будет пообщаться в чатике и покритиковать экспертов :).

Подробности о передаче можно прочитать на сайте.

Разница между ручным тестировщиком и автоматизатором 25

admin08.07.201509.07.201525 комментариев

48NCCrj

Итак, раз уж я в прошлом выпуске Radio QA cпалил в чатике заготовку, то вот вам она еще раз постом.

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

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

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

Отсюда же очевидно, что проекты, которым нужен хороший доктор, должны искать именно высококвалифицированных тестировщиков, а не кликеров (которых по данной терминологии с трудом претендуют на звание "санитаров").

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

Кто не согласен - прошу в комменты!

Правда о явных и неявных ожиданиях в Selenium 10

admin07.07.201507.07.201510 комментариев

Посмотрел лекцию для начинающих автоматизировать с Selenium

Очень приветствую создание и распространение обучающего материала, это правильно и нужно! Правда есть "но".
К сожалению не обошлось в этом материале без принципиальных фактических ошибок. В частности часть про явные и неявные ожидания (explicit/implicit waits) лектор предваряет ремаркой о том, что тема про эти два вида ожидания довольная сложна для понимания, и немедленно подтверждает тезис тем, что путает их между собой и даёт неверное пояснение.

Давайте же разберёмся, в чем разница. Страница помощи Selenium-а абсолютно невнятно освещает этот вопрос, поэтому попробую проще своими словами.

Explicit Wait - явное (непосредственное, прямое) ожидание используется "здесь и сейчас" на один конкретный поиск элемента. В частности, даже паттерн "sleep" (ждать и ничего не делать) является примером explicit wait, но его применение не поощряется.
На практике рекомендуется использование WebDriverWait в сочетании с методами класса ExpectedConditions, которые позволяют сократить ожидание. Если элемент появился раньше времени, заданного при инициализации WebDriverWait - Selenium не будет ждать, а продолжит исполнение теста.

Пример кода на Java:

WebDriver driver = new FirefoxDriver();
driver.get("http://someurl");
// ждем до 10 секунд
WebElement explicitWait = (new WebDriverWait(driver, 10))
// или пока не появился элемент с id=bar 
  .until(ExpectedConditions.presenceOfElementLocated(By.id("bar")));

WebDriver driver = new FirefoxDriver();

driver.get("http://someurl");

// ждем до 10 секунд

WebElement explicitWait = (new WebDriverWait(driver, 10))

// или пока не появился элемент с id=bar

.until(ExpectedConditions.presenceOfElementLocated(By.id("bar")));

Implicit Wait - неявное (косвенное, скрытое) ожидание устанавливается один раз в коде вне операции поиска и действительно до изменения. Значение по умолчанию - 0, т.е. никакого ожидания. Implicit Wait применяется ко всем последующим операциям поиска неявно (т.е. скрытно, без указания напрямую в методе поиска, как мы видели в примере выше). ...читать далее Правда о явных и неявных ожиданиях в Selenium

Почему почти все хотят автоматизацию тестов на проекте?

admin29.06.201529.06.2015Оставить комментарий

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

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

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

Кстати, о тонких чувствах ручных тестировщиков, ушедших в автоматизацию, в субботу 04.07 в 16:00 мск выходит подкаст на Radio QA 🙂