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

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

5

Такой возник диспут.

"Тестировщик никогда не додумывает. Лучше задать вопрос. Вот этому стараюсь учить, да" (с)

Говорят нам преподаватели тестирования.

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

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

Что я делаю не так?
И что я делаю так?

Прошу мнений в комменты.

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

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

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

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

25

48NCCrj

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

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

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

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

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

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

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

9

Посмотрел лекцию для начинающих автоматизировать с 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 :-)

3

Очередная критическая разборка доклада, на этот раз на очереди Андрей Ладутько с беседой об аудите:

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

Начну с критики по содержанию доклада:

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

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

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

...читать далее Линч-пакет: Андрей Ладутько “Как оценить процесс тестирования на проекте”

1

За этот слайд нужно исключать из автоматизаторов! Скажите же мне, что лектора пытали производители тулов для автотестов!!
Тестирование__Занятие_№11_-_YouTube
Полностью лекцию можно посмотреть тут, увы это не единственное неграмотное место в ней.

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

П.С. из комментов (Дмитрий Новоселов): Типа, чем больше автотестов, тем больше убыток? Интересная мысль, имеет право на существование 😉
И еще комментария (Алексей Баранцев): Главное не запускать автотесты слишком часто. А то, гм, прибыли становится слишком много :)

2

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

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

SevPrioComicsFull1
Смотрите, задавайте вопросы!

 

1

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

Рекомендация по безопасности от OWASP (описано в линче): удаляйте сессию на сервере для критичных приложений через 15 минут неактивности, для среднекритичных - через 30, для остальных - через час.

Теперь история:

Время от времени я планирую сложные маршруты на сайте Deutsch Bahn (Немецкая Железная Дорога). Ну там, пересадка там или сям, часом раньше - часом позже, тут чуть быстрее - а тут чуть дешевле. Тот, кто ездит или летает по новым маршрутам меня поймет. И вот нужное соединение найдено! Можно расслабиться и заскочить в фейсбучек, ну на 3 минутки всего. И вот эти козлы дропают мою сессию через 30 минут!!! А я же всего через час вернулся!

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

Рекомендации - хорошо, рекомендации и здравый смысл - лучше!