2

Команда, в которой 10 разработчиков и ни одного тестировщика похожа на футбольную команду без защитников. Кстати, и 1 защитник особо погоды не меняет.
Из прошлогоднего креатива про то, как бы было, если бы в футболе размышляли, как некоторые личности из IT сферы.

- Мы должны выиграть в сжатые сроки, поэтому нам более важно иметь много нападающих.
- Защитники стоят ненамного дешевле нападающих, но практически не участвуют в голевых моментах.
- У нас просто нет денег на защитников, пока обойдемся тем чем есть.
- Когда мы забьем достаточно голов, наши нападающие уйдут помогать в защиту.
- У нас нападающие тоже защищаются (иногда)!
- Защитников выпустим в самом конце игры, если к тому моменту пропустим слишком много голов.
- (Перед началом матча) Зачем защитники? Нас же еще никто не атакует.
- Очень хороший защитник, но ведь он хочет зарплату, как у нашего среднего нападающего, не можем взять.
- Защитник - первая ступенька в карьере футболиста. Хорошие защитники через пол-года идут в полузащитники, затем в нападающие.
- Главная задача защитников - автоматизировать защиту.
- Вратарь (ака тест менеджер): я не должен уметь играть ногами и головой, это скиллы защитников.
- Нападающий: с какого я в свою половину поля пойду - у нас же четыре защитника есть.
- Защитник нам не нужен, он будет треть матча сидеть без работы!
- Пока наша команда атакует, защитники могут приседать на месте, чтобы улучшать свою физическую форму.
- Мы очень дешево закупили пожилых близоруких астматиков с плоскостопием. - Ничего, для защиты сгодятся!

(с) моё

- В защитники уходят те, кто не могут стать хорошими нападающими, это недонападающие.

(с) Андрей Ладутько

 

11

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

Я так часто иронизирую над автоматизацией тестирования, что может возникнуть ощущение, что я её ненавижу или считаю малозначимой. Это не так. Вот на днях как раз отловил довольно серьёзный баг, который *как я сперва подумал* ни в жизни не обнаружил бы, тестируя вручную. Автоматизируя тест-кейсы веб приложения, внезапно заметил, что вместо одного элемента окна диалога мне вернулся массив. Оказалось, что диалог, который используется во многих местах приложения всегда создается после открытия, но не удаляется из кода страницы после закрытия. Со временем "мусор" накапливается и тормозит отображение страницы.

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

...и вот, что оказалось. "Нас часто спрашивают"™, как выжить тестировщику, который не умеет писать программный код, в современном жестоком IT-мире, где всякий встречный пытается автоматизировать всё, что не успевает на счет 3 залезть на дерево. Отвечаю так. Приобретайте новые навыки, конечно, но... Не надо путать навыки автоматизации, без которых, *как я все еще не сомневаюсь*, можно обойтись от слова совсем, и навыки технической, пользовательской и исследовательской грамотности! Буквально неделю назад, я посмотрел небольшой курс c CodeSchool  (на сайте много неплохих бесплатных курсов, и еще больше хороших платных) про использование Developer Tools в Chrome, почерпнул для себя много нового, в частности методику проверки утечки памяти вручную (вот например, соответствующая часть инструкции на сайте Chrome). Выясняется, что быстрее и надежнее вышеупомянутую ошибку (и многие другие) можно было выявить ручным тестированием с использованием технических средств.

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

P.S. В Фейсбуке горячая дискуссия:  https://www.facebook.com/alexei.vinogradov/posts/1109312402419661

2

В Новосибирске с удовольствием сходил на квартирник:

http://2015.codefest.ru/lecture/1044 (видео писалось и будет выложено через некоторое время)

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

Ожидания оправдались, у тестировщиков и программистов оказалось очень широкое понимание вопроса. Услышал такие распространённые заявления, как "ручное тестирование медленно и должно быть заменено автоматизированным", "тестировщик не умеющий программировать скоро не будет нужен", "программисты должны взять на себя работу тестировщиков (в т.ч. и ручное тестирование), чтобы не терялось время на коммуникацию". Впрочем и за-тестировочные мнения тоже были :).

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

А вот известное видео, на котором автоматизатор пытается научить ручного тестировщика автоматизировать тестирование:

2

Коллеги и все, кто в теме.
Почему считается, что тестировщики ищут как сломать программу?

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

Исключения, конечно тоже есть - тестирование безопасности (например penetration testing), но я им не занимаюсь практически.
А вы, тестировщики, ищете как сломать?

codefest

Собираюсь посетить одну из лучших IT-конференций на русскоязычном пространстве - CodeFest в Новосибирске.

В программе поучаствую квартирником (открытая дискуссия с экспертами) о нас, зарубежных айтишниках. Так же приглашены эксперты из США, Великобритании, Эстонии, Нидерландов и Швеции. Приходите 🙂

Программа

Недавно на сайте QAHelp задавали вопрос, по каким признакам можно понять, что проекту скоро конец. Изучил вопрос и привел такие признаки:

  • когда в ваш офис начинают приходить деловитые посторонние и оценивающе поглядывать на мебель и оргтехнику
  • когда шеф внезапно составляет списки, в каком порядке получать зарплату и очень настаивает на том, чтобы его имя стояло первым
  • когда на входе табличка в офис сменилась на "Бутик У Жоржа - скоро открытие!!"
  • когда вас спрашивают, а не говорите ли вы, абсолютно случайно, по-китайски

и, наконец, самый главный признак:

  • когда руководитель проекта, направив взгляд в потолок, произносит: "а я бы не удивился, если бы мне сказали, что проекту конец".

1

Подведу краткие итоги стартового периода. За последний месяц более 1300 пользователей насмотрели более 3000 страниц блога, что в общем-то говоря очень много для довольно узкоспециализированного блога. Спасибо за интерес 🙂 За все три месяца суммарная цифра примерно вдвое больше. Написано 25 постов различной длины, в среднем почти 2 в неделю.

Audience_Overview_-_Google_Analytics

Большинство людей приходят по ссылкам из других ресурсов, в первую очередь это портал http://software-testing.ru, который транслирует основные (но не все) посты блога, затем ссылки на отдельные посты на различных сайтах (например, с http://dou.ua - очень посещаемый ресурс), фейсбуке и твиттере.
Если вам понравился стиль блога и вы хотите получать тексты постов по мейлу сразу после публикации - справа есть поле для подписки - просто введите свой email.
Посетители приходили аж из 43 стран, на первом месте Украина, на втором - Россия, далее с большим отставанием Беларусь, Эстония и Германия. Что заинтересовало посетителей из Омана, Кувейта и Барбадоса - сказать не берусь, но будем надеятся, что и в этих странах к тестированию станут подходить серьёзнее. 🙂
Так же рад тому, что посетители комментируют посты, в некоторых получались очень интересные дискуссии. Продолжайте дальше!

4

Не могу не поделиться прекрасным. Презентации, посвященные в основном автоматизации и автоматизаторам, не новые, но раньше не видал.

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

Краткое введение в тему:

А теперь подробно о том, как писать хорошие автотесты:

Опасности использования BDD: ...читать далее Автоматизация тестирования: советы от Captain Chaos

А теперь об успехах юзабилизаторов. Компания LinkedIn твёрдой рукой ведет Slideshare к триумфу плохого UX во славу "требований". Казалось бы, что главное в платформе, демонстрирующей слайды? Слайды? Вряд ли, иначе трудно объяснить, почему на огромном экране они занимают примерно 10% пространства.