5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1

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

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

 

1

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

Как_использовать_Agile_Manifesto_в_мобильном_тестировании___A1QA_Блог

 

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

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

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

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

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

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

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

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

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

25

48NCCrj

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

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

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

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

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

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

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

10

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

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

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

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

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

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

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

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

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

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