2

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

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

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

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

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

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

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

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

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

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

4

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

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

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

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

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

5

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

Теперь про анализ. У меня такое замечание/дополнение по процедуре анализа ошибок найденных исследовательским тестированием, да и другими методами тестирования тоже. Я очень понимаю желание проанализировать ошибку до нахождения точных границ фейла ("когда ввожу число 500  - работает, 501 - уже нет"), но со временем пришел к выводу, что обычно этого делать не надо. Достаточно зафиксировать входные параметры, при которых ошибка возникает ("ввел число 650 - не работает") и продолжать поиск других ошибок.

Аргументы такие: ...читать далее Анализ багов при исследовательском тестировании

13

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

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

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

Надеюсь, всегда запоминается последняя фраза ;-).

Наконец опубликовано видео с моего доклада на SQA Days 16. Хотите сделать ваше ручное тестирование быстрее и гибче? Обязательно посмотрите 🙂

Любопытно, что после доклада были задана большая часть тех вопросов, которые я уже слышал и ожидал. Ответы на остальные, а также уточнение ответов на сложные вопросы с конференции сделаю в одном из следующих постов.

Если у вас есть свои вопросы - задавайте, постараюсь ответить. В конце поста добавлю и пример с решением, который описывал в докладе.

Видео:

Слайды:

...читать далее No-Test-Cases: избавьтесь от тест-кейсов в ручном тестировании

Нашел интересную мысль в книге Голдратта "Теория ограничений".
Голдратт в книжке описывает производство и свою TOC (theory of constraints), но мне кажется модель узнаваема и применима для IT-компаний и других методов улучшения процессов.

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

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

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

В своей книге Голдратт указывает, что даже если все подразделения кроме одного улучшат свои процессы, то "наказанными" останутся они, а не то подразделение, которое оставило все как есть. Поэтому его вывод - применение ТОС должно начинаться с головы, т.е. необходимо полное одобрение самого высшего начальства, способного повлиять на глав подразделений. Ну или же иметь полное согласие между всеми руководителями подразделений.

Знакомо?

6

В этом году я познакомился с фреймворком Selenide, который позволяет писать более компактные и читаемые тесты на языке Java с использование технологии Selenium Web Driver. Доклады на эту и другие темы автора фреймворка Андрея Солнцева показывают, что разработчики глубоко понимают проблемы UI тестирования и успешно работают над их решениями. Давайте же пользоваться!

Все хорошо, но есть проблема. Если посетить на сайте проекта раздел "Быстрый старт", то вам предложат воспользоваться одним из продвинутых тулов для разработчиков (maven, gradle, ivy). Необходимо ли это? Вовсе нет. Начать писать тесты и эффективно использоваться Selenide можно и владея только самым базисом тест-автоматизации - Java, Eclipse, основы Selenium. У вас есть 5-10 минут? Этого достаточно, убедитесь сами.

Нам понадобится:

  • Java SDK 1.6+
  • Eclipse for Java (практически любая версия) http://www.eclipse.org/downloads/
  • Браузер Firefox (с ним по умолчанию работают Selenium и Selenide)

...читать далее Selenide: теперь по-настоящему быстрый старт

На докладах не был, диагноз по видеозаписи.

Александр Щукин "Тестирование сетевого оборудования через консольный интерфейс" http://sqadays.com/ru/talk/24015

Доклад технически описывает опыт построение консольных автотестов для специфической области (сетевое оборудование), когда доступ к тестируемому оборудованию неудобен (VPN, медленно).

Алексей Николаев "Альфабанк: НТ в Облаке при Agile на примере интернет банка" http://sqadays.com/ru/talk/25773

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

Мария Терёхина "Улучшение процесса тестирования: контентные модели" http://sqadays.com/ru/talk/25603

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

Татьяна Смехнова "История HERE Maps for Windows: меняемся не изменяя качеству" http://sqadays.com/ru/talk/25556

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

Дмитрий Химион "Инструменты автоматизации тестирования - дефективные"  http://sqadays.com/ru/talk/24213

Тулзы. Достать чернил и плакать. Я не понял, зачем измерять среднюю температуру тулзов по больнице. Кроме того, чтобы писать навзрыд.   Критерии для оценок тулзов сами по себе интересны -их можно применить к конкретно вашим тулзам. Больше писать не буду, а то разревусь.

Рина Ужевко "Тестируем графику силами Art QА" http://sqadays.com/ru/talk/23936

Узнал про новую для меня ветвь тестирование - Art QA. Хорошие, но несколько специфические (игры и графика) примеры. Включу в свой доклад для студентов о профессии тестировщика 🙂

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 может и должно искать и находить проблемы, но не доказывать или тем более гарантировать их отсутствие.

У меня всё.