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

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

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

8

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

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

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

Слайды:

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

12

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

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

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

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

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

CF4a68gVIAEcZp0

5

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

Похоже, что "виной" тому - Scrum. Дело в том, что одно из базовых понятий Scrum-е -  Developement Team (команда разработчиков). Теперь если понимать это буквально и консервативно - то выходит, что Development Team состоит только из людей, которые умеют программировать (к сожалению, много людей поверхностно понимающих Scrum именно так и думают). Что в корне ошибочно - на самом деле в команду входят все вышеперечисленные роли, если они важны для успешной реализации требований проекта.

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

Ну и вообще,  почему бы и нет?

Пришел на новый проект. Через неделю не могу в апп залогиниться в браузере со своего компа, а с других могу и автотесты с моего же компа - логинятся с теми же браузерами. Программист ищет баг уже 3-ий день, сегодня вокруг него еще 5 коллег сидело.
Я вообще не могу понять, как написать такой код, даже если захотеть, с такими странными эффектами.

А вы говорите не нужны юнит-тесты.

Дали мне сегодня весь проект запустить. Скачал из git. Запустил на сборку. Выдаёт ошибку в юнит-тесте.
Окей - говорю программистам. У нас не выдаёт, отвечают. Запускают - действительно не выдаёт, у меня при запуске теста из IDE тоже не выдаёт. А из командной строки - выдает. Программисты, хотите упражнение? Метод модифицирует web элемент таг с атрибутами вроде:

И assert сравнивает строковый результат, и у меня из командной строки валится потому что атрибут один меняет порядок (сперва attr2, затем attr1). Примерно так:

Симптомы - выше (где-то меняет, где-то не меняет). В чем проблема? Решение ниже.

...читать далее Походные заметки про простое тестирование

1

Записали выпуск Radio QA про тестирование и годы.

http://radio-qa.com/vypusk-9-testirovshhik-superstar/
А как считаете вы? С возрастом тестировщикам становится тяжелее или проще? Заполняйте опросы и пишите ваше мнение в комментах!

 

1

По мотивам ленты о тестировании подумалось:

Как_использовать_Agile_Manifesto_в_мобильном_тестировании___A1QA_Блог

 

Две самых крупных ошибки этого поста

  1. Выделение из 4 столпов Agile манифеста "двух ключевых".
  2. И что гораздо хуже, вычленение тестирования от процесса разработки (уж особенно в Agile)

Я думаю, пост должен помочь продавать тестирование в Agile-проект заказчикам, что я в принципе приветствую. Но не любыми же средствами :).

Запомните, тестирование - это часть процесса разработки. Я считаю, что Agile разработку нужно продавать, включая в неё тестирование без искусственного отделения от программирования.

Вот сказанул тут в чатике, а они это раз - и на картинку!А вы что думаете? Огрехи программиста увидеть проще, чем огрехи тестировщика или есть тонкости?

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

5

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

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

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

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

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

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

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

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

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

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

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