О правдивости докладов на конференциях

Какое-то время назад купили билеты и прослушали онлайн конференцию Podlodka QA CREW. Это не реклама, она не лучше и не хуже других.

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

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

Не акцентируя внимание на проблемах, острых углах и косяках. И кажется, что замки воздушные и единороги розовые. Но реальность — сурова.

Один из докладчиков сказал, что вот такие-то карты покрытия это хорошо. И не сказал, какую часть продукта они реально затрагивают.

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

Третий говорил о высоком покрытии, но ни слова не сказал о невысокой сложности бизнес-логики...

Это плохо? Нет. Они напрямую врали? Нет. Ребята рассказывали о том, чем гордятся, о том, чего хорошего они сделали.

Может быть, плохи эти трое, а другие докладчики на конференциях не такие?

Как вам сказать...

Я познакомился с инженерами Badoo на Codefest и отчаянно завидовал степени автоматизации, мощной системе CD, осознанности подхода. Пока один мой коллега не устроился к ним работать и не рассказал, что всё это великолепие в одной небольшой команде, а весь продукт до сих пор на ручной регрессии. Врали ли ребята из Badoo? Нет. Просто не уточняли, что "у нас" это не "у нас в Badoo", а "у нас, нескольких инженеров из Badoo".

Другой пример. Я всей душой душой люблю замечательные доклады Ерошенко или Писаренко из Яндекса. Они рассказывают про систему нагрузочного тестирования, про системы визуализации покрытия и прочий аллюр. Но, как говорят в у них в компании, "Яндекс большой". Я работал в Яндекс.Маркете и там далеко не так безоблачно, как на картинах этих докладчиков.  Яндекс действительно большой.

Показывают хорошее, плохое не показывают. О цене, которую пришлось платить говорят мало. Это очевидная мысль, сейчас её называют "синдром инстаграма". Речь о выводах.

Если в докладах настолько не вся правда, что уже практически неправда, то какой смысл смотреть их и обсуждать с докладчиками?

Я не нашел ответа.

Книги по тестированию

Я говорю о необходимом, а не о достаточном. Чтоб стать квалифицированным специалистом, необходимо знать теорию, но этого недостаточно. Знание одной теории не сделает тебя приличным специалистом точно так же, как им нельзя стать, занимаясь только практикой.

Не каждая книга является качественной, полезной и ценной. Я стараюсь читать всю литературу по профессии, но уже скорее для того, чтоб не упустить что-то годное.

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

 

Тестирование

ISTQB, Foundation Level, материалы для подготовки.

Слова интеграционные тесты могут значить что угодно. Перед следующими шагами нужно определиться с терминологией.

Lessons Learned in Software Testing, Cem Kaner.

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

ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения.

На удивление неплох.

A Practitioner's Guide to Software Test Design, Lee Copeland.

Как придумывать тесты, лучше этой книги ничего нет.

Автоматизированное тестирование ПО, Дастин.

Для а-а-а-автоматизаторов, привет адекватности из прошлого века.

Проектирование

Купер, Об интерфейсе.

У него есть более попсовая психбольница, в этой книге меньше воды, больше примеров и по делу.

Аналитика

Коберн, Cовременные методы описания функциональных требований к системам.

Просто, понятно, эффективно, один хороший и острый инструмент.

Виггерс, Разработка требований к программному обеспечению,

Наоборот.

 Программирование

"Про гит"

Это уже гигиена разработки

Шаблоны тестирования xUnit, Месарош

Сколько а-а-а-автотестеров ознакомились с ней?

Процессы

Блэк, Ключевые процессы тестирования

Всё придумано до нас. Наши проблемы уже решали и описали их в большом справочнике.

Голдратт, Цель 1-3

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

Чего тут нет

Нет хороших книг по devops и по ITSM, хотя должны быть, наверное. Ещё нет чего-то годного из психологии.

Надо ли что-нибудь добавить? Сейчас 14 позиций. Чтоб не делать список бесконечным, предлагая добавить, предлагайте и выкинуть.

Roadmap тестировщика в контуре

У нас в контуре есть гайд о том, каким мы видим проектировщика.

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

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

Когда нибудь придет время  и он будет торчать наружу, пока же лежит в корпоративном гите.

Итак:

Тестировщик в Контуре

Per aspera ad astra

О чем речь?

Текст поможет ответить на вопросы **Кто я и как мне стать круче?** и понять, кем хочешь быть в профессии и что сделать, чтоб стать лучше.

Стажер, младший тестировщик (0)

Чтоб стать

Связная речь, обучаемость, интерес к профессии и минимум один из следующих пунктов:

• Высшее техническое образование
• Серьезный объем подготовки
• Опыт работы в профессии

События этой весны в тестировании Екатеринбурга

• Тест-сессия для студентов
• Секция тестирования на Дампе
• Курсы по тестированию от Кати
• Курсы по тестированию от Ильи
• Гуру на Урале: Сергей Мартыненко, лекция для студентов (в разработке)
• Гуру на Урале: Сергей Мартыненко, лекция для сообщества тестировщиков (в разработке)
• Пятая городская сессия тестирования от Targem (в разработке)

Искренне радует тот факт, что в создании трех из семи этих событий я не принимаю участия.

Курс Основы тестирования программного обеспечения от mail.ru

На этой неделе закончил на универсариуме курс по тестированию от mail.ru

Итоги коротко:
Площадка универсариума - твердая пятерка. Удобно, понятно. Я ее не замечал во время прохождения курса, именно так и нужно делать площадки.

Лектор и оформление лекций. Вел курс директор по качеству мейлрушной почты Алексей Борисович Петров.
Аналогично, все сделано на крайне высоком уровне - материалы в pdf, голос, прозрачная доска, на которой он пишет текст, монтаж - наглядно, без нареканий. От смысла не отвлекался совершенно.
Кстати, Алексей на прозрачной доске пишет справа налево и его почерк не страдает. Респект.

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

Рекомендую.

А теперь о деталях, которые я отметил для себя в ходе просмотра. Просто заметки к лекциям.

- Говорится о цене исправления ошибки, но нигде не говорится о цене поиска, а уж тем более, о цене сопровождения. А это важно.

- Расстраивает пренебрежительное отношение к терминам. Во-первых, у ПО нет "функционала", есть функциональность. Во-вторых, прилагательное полуавтоматизированный является тавтологией. Есть цепочка: автоматический - автоматизированный - ручной. Термин полуавтоматизированный не имеет смысла.

- План тестирования и стратегия тестирования - все же отдельные артефакты.

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

- Огорчило, что вы рассказывается о цене создания артефактов, но ничего не говорите о цене владения. У человека, который в начале проекта, пока было время - написал тысячу тест-кейсов - как вы и посоветовали - ближе к середине будут серьезные проблемы с огромной кучей неактуальной макулатуры.

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

- Арифметическая ошибка в подсчетах. 600 всего, 40 починено, 200 выпущено, 100 найдено пользователями. Если бы было починено 480, то были бы исправлены не 80% дефектов с которыми столкнулись пользователи, а 40. Вы почему-то считаете, что все те 80 дополнительных дефектов, которые предлагали починить входят в сто, которые нашли пользователи. А они входят в 200 которые вы выпустили. Надеюсь Алексей при общении с руководством более аккуратен с цифрами и не удваивает ключевые показатели.

- "Автоматизация неэффективна при частых изменениях" - все с точностью до наоборот и мне кажется странным, что специалист такого опыта и уровня позволяет себе так говорить. Автоматизация крайне эффективна ИМЕННО при частых изменениях. Причины называются в соседних пунктах. В случае редких изменений неплохо себя покажет обычный ручник, а там где нужен быстрый отклик - там и помогут роботы.

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

- Вызывает некоторое сомнение высокая точность измерения вовлеченности сотрудников по проектам. Плюс минус 10%? На какой период времени рассчитывается процент? Также кажется странным управление через ресурсы времени, да еще с такой степенью детализации, а не через вехи, цели и дедлайны. Неужели столь низко доверие к своим сотрудникам? Это нормально для бадишопа на аутсорс, но у мейлру же собственная разработка.

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

Тестирования требований пост

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

Мое мнение на этот счет - школа укладывается в парадигму "надо думать заранее", так как требования как правило идут до разработки; а также в парадигму "кто если не мы", так как почти всей описанной у Наташи работой, на мой взгляд, должны заниматься аналитики.

И по стечению обстоятельств получилость так, что в это же время Юля @yuzaks  устроила у нас локальную движуху под названием "Ревью аналитики".

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

В чем суть, смысл и процесс?

Делаем раз - собираем штук 16 аналитиков и 3 тестировщиков. делим на команды. Выбираем аналитиков-жертв, просим несколько годных постановок (ТЗ, требований).

Делаем два - читаем книгу 15 главу книги Карла И. Вигерса Разработка требований к программному обеспечению. В 15 главе как раз - о тестировании требований.

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

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

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

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

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

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

Обратно же, если сделать шоу регулярным и не столь малочисленны, то хуже тоже не будет.

Посмотрим, как дело пойдет дальше.

Кстати, понравилась цитата из книги:

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

Есть вопросы

В последнее время неоднократно сталкивался с такой ситуацией и не до конца уверен, что я в ней прав..

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

В результате тестирования выясняется, что одн из фич- реализована, но не работает (или баг все еще воспроизводится).

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

Мне не нравится второй вариант, так как мы добавляем или меняем некий объем кода, который должен менять функциональность, но не делает этого. Поэтому я за первый вариант.


Мне интересно ваше мнение на эти счета. Вот только не надо нудить о приоритетах, срочности, критичности. Чаши весов (сроки и необходимость фичи) уравновешены и выбор зависит целиком от ваших религиозных взглядов и мировоззрения.

может быть у вас есть свои варианты - но с учетом условий.

Вторая городская сессия тестирования.

Регистрация открыта. Присоединяйся. Засылай всем  знакомым и незнакомым тестерам.
http://testsession.timepad.ru/event/139949/
(сегодня почему-то тормозит timepad)

Группка в ВК для вопросов, обсуждений и ответов.
https://vk.com/event77162421
Вот рассказ о первой

Терминологии пост

Из русского глоссария rstqb:

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

Я считаю этого недостаточно. Сообществу срочно нужны:

• bang-bang testing
• gangbang testing
• ping-pong testing
• thailand testing

Видяшки про DUMP 2014

Выложили видео с дампа. В том числе с моими тестерами:

• Тестирование без тестировщиков
• Тестирование на аутсорс
• Опыт внедрения тестирования
• Автоматизация тестирования верстки
• Когда тесты пишут разработчики
• RobotFramework
• Управление конфигурациями и тестовой средой

Тест с прищуриванием

Очередное из Купера

 Есть хороший способ убедиться, что визуальный дизайн эффективно задействует иерархию и отношения, – дизайнеры называют этот прием тестом с прищуриванием (squint test). Закройте один глаз и посмотрите на экран прищуренным вторым глазом. Обратите внимание на то, какие элементы слишком выпирают, какие стали нечеткими, а какие
объединились в группы. Эта процедура часто вскрывает не замеченные ранее проблемы в композиции интерфейса.

The Domain Testing Workbook

Жаль, но не думаю, что эта книга стоит времени на перевод.
Прочтения - да. Поэтому только начало книги:

Секция 1: Что такое тестирование доменов?

Секция состоит из 2 глав:
- Введение в тестирование доменов
- резюме ключевых технических концепций

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

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

Секция 1. Часть 1: Введение в тестирование доменов

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

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

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

пример серии испытаний

Уже давно мы начали книгу Testing Computer Software (kaner, 1988) ч простого примера, иллюстрирующего эту технику. начнем работу с этого примера и сейчас:
Вам дали программу с таким описанием:
Программа создана для сложения двух чисел, которые вы введете. каждое число должно состоять из одной или двух цифр. программа отображает то, что вы ввели и сумму. Нажмите после каждого числа. Для запуска программы наберите ADDER.

В книге описан такой пример:
- Начните с простых тестов, раскрывающих, как программа работает с разными переменными:

2 + 3 Программа вообще работает?
99 + 99 99 действительно верхняя граница?
-9 + -99 Допустимы ли отрицательные значения?

- Дошли до проверки простых, очевидных рисков:

0+0 Программа работает с нулями?
-99 + -99 Обрабатывает ли программа двузначные числа из трех символов?
100 + 100 Как будут обработаны трехзначные числа за границей?
-100 + -100
+
Что будет, если ничего не ввести?
123456 + 0 Как много цифр она воспримет?

- Проверьте входной фильтр, гарантирующий, что программа принимает только легитимные числа. Примеры:
1.2 + 5 Разделитель точка? Если она отклонит это, как насчет 1.0 или 1.?
A + b Буквы?
/ + 1
или
1+ : ASCII соды цифр начинаются от 48(0) до 57(0). ASCII 47 это / а ASCII 58 это :

1 Попробуйте ввести произвольное количество пробелов в начале и в конце.

- Рассмотрите обработку пользовательских действий во время ввода чисел, такую как:
- Время ожидания между цифрами. Это таймаут?
- Повторное редактирование чисел после перед вводом. У вас есть возможность переполнить строку ввода, если программа хранит все, что вы вводите до нажатия (Сейчас мы должны называть эту входную строку, как буфер ввода и считаем этот тест слишком простым для переполнения буфера).
- Рассмотрите возможные значения результатирующей переменной:
- Если программа держит входные значения в виде byte, то их размерность может быть от -128 до + 12. Тесты, сумма в которых выходит за эти границы, может вызвать переполнение.

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

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

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

В 1988 мы представили и объяснили эти идеи тестирования, но не поместили этот список в единую структуру. Мы думаем, что это распространённая проблема. Многие авторы описывают технику, но не исследуют весь ее процесс. Они останавливаются после описания того, что, на их взгляд, было самой важной частью.

Из блога Баха

Оригинал статьи Баха.

RST методология: "Ответственный тестировщик"

В методологии Быстрого тестирования мы выделяем три основные роли: Лидер. Ответственный тестировщик и Помощник. Различия этих ролей ситуационны. Одно и то же лицо может быть помощником в одной ситуации, лидером в другой и ответственным тестировщиком в третьей.

Ответственный тестировщик

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

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

пример тестирования без ответственного тестировщика: Человек А пишет текст, называет его "тест-кейс", передает его Человеку Б. Этот человек читает текст и выполняет инструкции. Это может хорошо звучать, но что делать, если у Человека Б недостаточно квалификации, чтоб оценить, правильно ли он понял и провел тест, в то же время, как Человек А не наблюдает за ним, а значит не в состоянии оценить его работу. Это все равно, что машина без водителя. Никто не берет на себя ответственность. Никто не может сказать было ли тестирование проведено хорошо и никто не пример мер, если оно было плохим. Если проблема объявится позже, то каждый из этих людей может справедливо обвинить в ней другого.

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

Ответственный тестировщик подобен водителю автомобиля или командиру воздушного судна.

Помощник

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

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

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

В некоторых ситуациях, когда лидер отвечает за тестирование, но у него еще нет ответственных тестировщиков в команде, он сам становится таковым. Лидер в окружении помощников и является ответственным тестировщиком команды.

О книгах

Заказал бумажную The Domain Testing Workbook by Cem Kaner.

Альбом: bug

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

Это все под позитивным влиянием Наташи Руколь. Она берет количеством.

UPD: Купил электронную. Завтра прогляжу, стоит ли книга времени, если да - опубликую расписание, ну и посмотрим, буду ли придерживаться.

Намедни постил картинку, где напротив книги Г. Майерса Искусство тестирования программ было написано, что читаю.
Собственно, дочитал.

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

Дальше - немного цитат и мыслей.

1. О критериях завершения тестирования

Альбом: bug

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

2. Главный принцип локализации ошибок

Альбом: bug

3. О отладке, экспериментах и поиске багов

Альбом: bug

Да, черт возьми! Как по мне - самый шик: найти багу, а потом запустить приложение и удостовериться в том, что она есть. Современные средства разработки стирают грань между не тратить время на рутину и не думать.

4. О бранных алертах

Альбом: bug

Просто понравилось.

4. О том, что полезней всего, но что никто не делает.

Альбом: bug

Хм.

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

А платят мне за то, что я согласен заниматься этим.
Дискас?

Рутина

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

Рутина

Занятная статья.
http://habrahabr.ru/company/yandex/blog/204192/

Особенно интересно то, что вот почти все эти штуки мы с ребятами в свое время создавали, может даже и покруче местами. Но как излагает! Модификаторы, билдер, граф состояний...

Да, надо уметь продавать тестирование.

Уникальная красота снежинки - это не про вас.

Обожаю эксперименты над людьми.
Поэтому намедни написал коллегам-тестерам письмо примерно следующего содержания:

Subj: Игра: угадай человека по резюме
Анонимно заполняем некое подобие резюме, вечером сравниваем и пытаемся узнать кто есть кто.
Цель: fun
Так как опыт у всех разный и по нему проще простого срисовать человека, то будем считать, что все работали только один год и только у нас. Этот опыт и описать так, как вы бы показали это будущему работодателю. Не пишите, где учились, когда родились. Только опыт и скилы последнего года.
Хвастаться можно. Врать - нет.


Всего у нас 13 (вроде бы) человек.
Итоги порадовали и удивили. Попадания у всех примерно 50%.
Точнее всего - 80% у руководителя группы. Я промахнулся мимо одного своего бойца! Из трех моих меня узнал только один. И это при том, что наша группа занимается автоматизацией, в отличие от остальных.

Самое смешное в движухе - оглашение правильных и неправильных ответов.
Рекуомендую, узнаете, насколько вы похожи и непохожи.

Вот тут okiseleva высказывает разные мысли, и цитирует некоторые книжки, мне очень понравилась мысль (насколько я понял, okiseleva не совсем согласна):

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

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

Другой вопрос как быть с touch интерфейсами, где нечаянные нажатия или промахи — обычное дело.