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

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

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

2

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

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

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

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

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

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

2

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

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

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

3

Немного наболело мне за понятие Quality Assurance (оно же Qualitätssicherung (нем.), оно же обеспечение качества (рус.)) в области разработки ПО.

Очень жалко, что это название досталось нам по наследству, от промышленного производства, понимается многими айтишниками на автомате буквально и из-за этого делаются опасные и иногда даже вредные выводы.
Давайте вспомним, что же делали работники Quality Assurance в дософтварную эпоху. На начальном этапе наши "тестировщики" брали готовые (или промежуточные) детали и измеряли их например штангенциркулем или скажем весами, на предмет соответствия ожидаемым значениям. Конечно со временем деталей стало производиться много, и "тестировщики" задействовали математико-статистический аппарат - измеряли из миллиона "одинаковых" деталей 200 случайных и оценивали количество ошибок математическими методами. Так или иначе, долгое время тестировались объекты, которые можно было объективно измерить и сравнить результат с эталоном.

И вот к нам пришло ПО (программное обеспечение). Особенность ПО по сравнению с большинством продуктов производства из прошлого, что "ошибки измерения" в ПО не лежат на поверхности. Более того, они там спрятаны настолько хорошо, что на данные момент  не существует практических методов доказательства того, что в софте отсутствуют ошибки, доказать можно только их наличие. Про это писали многие современные гуру тестирования (Болтон, Бах и другие), самое раннее упоминание в литературе, что я нашел от http://en.wikiquote.org/wiki/Edsger_W._Dijkstra в 1969 году. (Testing shows the presence, not the absence of bugs).

В результате мы приходим к тому, что никоим образом не может quality assurance assure the quality (Qualität sichern, обеспечивать качество), если речь идет о программном обеспечении. Повторюсь, QA может и должно искать и находить проблемы, но не доказывать или тем более гарантировать их отсутствие.

У меня всё.