В одной из твиттерных дискуссий Michael Bolton заметил, что тестировать, как точки зрения пользователя - это всего лишь часть тестирования, и предложил тестировать с точки зрения тестировщика.
Когда его спросили как это, он привел следующие 6 пунктов, которых я постараюсь адекватно перевести.

  1. Тестировщик активно принимает во внимание прогнозируемые риски, и готов обращать внимания на новые, доселе непредвиденные.
  2. При моделировании пользователей, рисков, покрытия, тестовых оракулов и т.п., тестировщик обычно предпочитает выражение "один из", выражению "конкретный", чтобы не модель не получилась чересчур ограниченной.
  3. Тестировщик практикует диаметральную смену методов (быстро/медленно, тщательно/бегло, поиск багов/знакомство с системой), чтобы диверсифицировать подходы.
  4. Тестировщик изучает технологии, чтобы понять их силу, слабость, известные проблемы и потенциальные уязвимости.
  5. Тестировщик чередует фокусирование на конкретной системе и её компонентах, дефокусированием  и изучением картины в целиком.
  6. Тестировщик чувствуют себя ответственными за моделирование элементов продукта и его связей с пользователями. Тестировщик ответственны за адекватную отчётность.

    А чувствуете ли вы разницу между тестированием как пользователь и как тестировщик?

Прочитал в сети аргументы, что, мол, раз Atlassian выпилило поле Severity из набора полей в JIRA по умолчанию, то это значит, что индустрия пришла к тому, что Severity никому не нужно.

Полная ерунда. Поле Severity ушло из стандарта JIRA потому что индустрия, пришла к тому, что JIRA чаще используется НЕ в качестве баг-трекера, а в качестве таск-трекера. Для тасков, в отличии от багов - поле Severity действительно не нужно. Я поддерживаю решение Atlassian оставить набор полей по умолчанию таким, чтобы большинство проектов не должны были что-то изменять. Но там где вы используете JIRA как баг-трекер, добавьте в большинстве случаев Severity для багов. Зачем и почему - описано в видео:

8

Наконец-то сбылась мечта - высказаться про цель тестирования на QA конференции. Попасть на конференцию с темой, про которой у программных комитетов нередко автоматически выскакивает ответ - "да о чём тут говорить, все и так уже знают" было непросто, так что спасибо организаторам QAFest за оказанное доверие!

Рекомендации для просмотра: от 3+ месяца опыта в тестировании - до неограниченного. Если у вас меньше 3 месяцев опыта, то вероятно, вы еще не проникнитесь сутью вопроса по неопытности, просто посмотрите видео чуть попозже. Если у вас очень много опыта (например 5++ лет) - возможно, хотя и маловероятно, что вы действительно всё это уже знаете. Для остальных - гарантирую, что в видео будут вещи, о которых вы не задумывались раньше.

Видео (слайды дополнительно внизу):

Слайды:

Приятного просмотра, спорить и обсуждать можно в комментариях!

5

Все вы знаете, что UI-тесты бывают нестабильны.

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

Автоматизация_тестирования__как_избежать_распространенных_ошибок___DOU

 

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

...читать далее Почему нестабильны UI-тесты. А на самом деле?

4

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

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

Сам забываю об этом, поэтому решил написать пост для себя, в качестве напоминания.

5

Рядовой Сидоров, если вы такой умный, то почему строем не ходите!? (неизвестный прапорщик из известного анекдота)

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

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

Для того, чтобы понять как работает двигатель внутреннего сгорания, не обязательно уметь собирать двигатели. Образованный человек сможет понять, как работает программа без владения языком программирования. А сможете ли вы объяснить ему или другому стороннему программисту?

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

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

12

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

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

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

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

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

CF4a68gVIAEcZp0

4

 

41NCHGYJCzLИзвестным Егор стал  благодаря своему блогу, в котором он и начал выкладывать свои будоражащие мир идеи об объектно-ориентированном программировании (ООП), а так же после знаменитого выпуска 105 подкаста "Разбор Полетов", где Егор провел неравный, но весьма увлекательный бой,  с хорошо подготовленной группой профессионалов, которые обстоятельно заклевали покритиковали его подход.

Данная рецензия именно на книгу, и меньше на сам подход Егора к ООП.

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

...читать далее Рецензия на книгу “Elegant Objects” Егора Бугаенко

5

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

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

2

CV0BdxXWsAIvYoi

В субботу 23.04 буду в Москве на конференции по автоматизированному тестированию "QA Conference".
Я буду рассказывать про сравнительно узкую техническую тему - использование PageObjects в UI Automation.
И для заманухи - в докладе я покажу, в каких местах Copy&Paste кода - хорошая идея. :)

Этот и другие вбросы - в Москве, в гостинице "Салют" с 10 утра, приходите или смотрите online. Я думаю, что будет, как обычно, довольно живенько и спорно!

http://qaconf.ru/matrix.html