12

Давайте рассмотрим типичную для многих современных проектов ситуацию: мы начинаем только с программистами-на-все-руки (нет времени объяснять, надо кодить). Через некоторое время выясняется, что есть проблемы с качеством. Почему?

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

Более логичным выводом является то, что тестировщик должен уметь писать код, если в проекте создаётся слишком мало кода и этот код успевает отлично протестироваться. Вы знаете такие проекты? Сводите меня туда на экскурсию, я хочу у вас учиться!

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

Кесарю - кесарево, а слесарю - слесарево.

CF4a68gVIAEcZp0

5

Недавно заметил, что могу давать для одного и того же бага в одном и том же софте разные оценки "Severity" в зависимости от "истории болезни".
Например появляется какой-то незначительный баг, неудобство для пользователя - никаких последствий для функциональности. Логично ставлю "Minor". Если же неудобство появилось в новой версии программы, а до этого было "удобно" - то рука чешется поднять до "Moderate", и обычно я себе в этом не отказываю.
Логика довольна простая -"проблема" обнаруженная в месте, в котором пользователь столкнётся с ней впервые - легче, чем та же самая "проблема", которую пользователь не испытывал в предыдущих версиях. Ухудшение существующего положение вещей - всегда хуже, чем неоптимальное нововведение.

Получается, что оценка Severity не всегда является статичной по отношению к текущему состоянию приложения.

5

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

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

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

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

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

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

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

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

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

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

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

25

48NCCrj

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

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

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

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

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

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

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

11

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

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

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

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

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

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