Subject:

Ещё одна грустная история из жизни

Issue ID #113 

Reported at 15.09.2013

Reported byNatalya Rukol

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

Severity Normal 

Tags

Жили-были в 2 параллельных вселенных 2 тестировщика: Нина и Гриша. Тестировали они одинаковое ПО в одинаковых командах, и был это калькулятор.

Гриша был раздолбаем редкостным. Кнопки потыкает, что заметит заведёт, и продолжает смотреть fishki.net

А Нина была девушкой гиперответственной. Ходила на курсы, скупала весь ассортимент книг по тестированию на amazon’e, читала статьи, внедряла новое на практике. Старалась ничего не пропустить: везде анализировала классы и границы, выявляла зависимые параметры, комбинировала проверки, готовила себе таблички с тест-анализом, помечала результаты проверок, оценивала покрытие кода, — в общем, делала всё, лишь бы не пропустить ошибки.

Тестировали они тестировали, и вот, наступил день финального тестирования предрелизной сборки. У Нины заранее был подготовлен тестовый набор для проверок: все возможные типы чисел, из различных классов эквивалентности (положительные и отрицательные, целые и дробные, состоящие из разных цифр и разного количества знаков, большие и маленькие). И она стала проверять все эти значения на всех операциях. Результат: всё работает! Довольная, показала это руководству, и продукт ушёл в релиз.

Гриша не знал, как правильно тестировать, да и не очень хотел в это вникать. Потыкал все кнопки — вроде работают. Сложил 2 числа — вроде работает. Умножил 15 на 42 — и получил огромный страшный краш системы. Завёл багу: оказалось, при умножении любого числа на 42 (и только на 42) продукт падает — вот такое пасхальное яичко было от уволенного разработчика. Багу поправили и выпустили продукт.

Чем всё закончилось? Тем, что во вселенной Нины краш нашли пользователи, а во вселенной Гриши критикалов пропущено не было.

Какие выводы?

  • Roman Sheyko

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

  • Sergey P. Vysotsky

    Нина молодец, а Гриша нет
    Сравнивать тестировщиков по найденным дефектам нельзя
    Таблички нам нужны не для того чтобы найти все-все дефекты
    Формального доказательства отсутствия дефектов не существует в природе (см. Дийкстру)

    Я там еще шесть логических дыр насчитал — кто найдет тот молодец

    • Andrey Myasnikov

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

      А мораль мне кажется в том, что:
      1) быть ортодоксом одного подхода плохо.
      Нужно во всем знать меру. Нет задач — читай книги или сиди на фишках.
      2)Знания бесполезны, если их не применять.

      • Sergey P. Vysotsky

        Это какая-то неправильная компания, если ей не важно куда направлены усилия ее сотрудников.

        А пользователю не важно Гриша там или нет. Он видит только компанию. И если у компании шарики за ролики не заехали, то она должна понимать откуда ноги растут и что Гриша/Нина тут ни при чем.

        • Andrey Myasnikov

          А я говоил, что неважно КУДА направлены? Читайте внимательней. Я сказал, что сотрудник может _пытаться_ сколько угодно, но важен только _достигнутый_ результат.

          • Sergey P. Vysotsky

            Или все же важен _только_ достигнутый результат?

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

          • Andrey Myasnikov

            Результат — отсутствие репортов от пользователей.
            Кастомер доволен. Что надо ещё?

          • Sergey P. Vysotsky

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

            А для достижения результата в виде «отсутствия репортов пользователей» я могу предложить много решений, которые куда проще чем вся работа Гриши и/или Нины.

            Доказательства что не упадет на 58 тоже нет.

            Это результат? Мне кажется это профанация.

          • Andrey Myasnikov

            Ну, наконец-то мы к этому пришли!
            Какие будут ваши предложения?

          • Sergey P. Vysotsky

            Наркомания и беспросветный алкоголизм. Или мы все еще про Гришу и Нину?

          • Andrey Myasnikov

            Заманчиво. Одно другому не мешает.

          • Sergey P. Vysotsky

            Тогда мы возвращаемся к тому с чего начали — Нина молодец, а Гриша нет. Просто исходя из имеющихся в посте данных.

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

      • algo_dogs

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

  • Anton Khayrutdinov

    Прохладная история. Осталось только добавить, что через месяц Гриша по пьяни разбился на своем новеньком Туареге. (http://habrahabr.ru/post/163849/#comment_5654881, если кто не читал)

  • Саша

    Нине надо было использовать fuzzing.

  • Maxim Zakharov

    Нина цинично лгала и симулировала бурную деятельность, скрываясь за буллшитом.
    Если бы она действительно «оценивала покрытие кода», то не пропустила бы эту бомбу, которая отразилась бы в любом coverage tool.

    Курсы не помогут, надо еще и в голове что-то иметь.

    • Anton Khayrutdinov

      Суров. Между прочим, линейное покрытие кода покажет 100% на закладке вида
      raise UnhandledException if magic_number == 42
      У кого 100% сondition coverage, тот пусть первый бросит камень.

      • Maxim Zakharov

        Судя по крашу системы, бомба должны быть сложнее.
        Наша emma такие штуки вроде ловит, хм… но эксперимент проводить лень.

        А вообще, по одному случаю судить сугубо неправильно, о чем в следующей записи нам и расскажет Наташа. Еще она, наверное, добавит, что на больших сроках Нина Гришу порвет как тузик грелку.

  • Марина Селиванова

    Даже жалко стало Нину — так на нее наехали. Скажите, опытные, умудренные жизнью гуру от тестирования — неужели вы никогда не пропускали подобных багов? Не верю :)

    Никакое планирование, написание тесткейсов и т.п. не обеспечит нахождения всех ошибок (ну не знаю, разве что вы тестируете идеального сферического коня в вакууме). Поэтому очень удобно и полезно после выполнения этих самых запланированных проверок просто «потыкаться» — бывает такое находишь, что волосы дыбом встают.

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

    Следование формальным методам не гарантирует отсутствия дефектов в приложении. Простого тыканья по нескольким кнопочкам недостаточно для оценки качества приложения.
    Истина как всегда где-то между этими двумя крайностями.

    • Andrey Myasnikov

      Читайте пост внимательней. Они не работают вместе )

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

  • Olga Burykina

    Есть такое понятие: «чувствовать баги», профессиональная интуиция. Грише повезло, но, не исключено что, он обладает этими качествами. И какой бы старательной умницей не была Нина, но тестировщик из нее будет не самый лучший. Зато Нина может хорошо себя проявить в плане управления, планирования, формализации тестирования, то есть тим-лид.

    • Andrey Myasnikov

      Интуиция приходит с опытом.
      Что такое интуиция? Это неосознанное принятие решения. То есть минуя сознание, подсознанием проводятся расчеты на основе опыта. А в сознание приводится только ответ.

      Получается, что Гриша опытней Нины по вашим расчетам?

      • Olga Burykina

        По моим расчетом получается, что Грише повезло в этом конкретном примере.

        • Andrey Myasnikov

          Стоп стоп стоп. Тогда причем тут интуиция?
          А то начали за здравие, а кончили за упокой.

          • Olga Burykina

            Как расширение темы и попытка предсказать, какими тестировщиками возможно смогут стать Нина и Гриша. Знаю лично отличных тестировщиков, которые именно «чувствуют» нутром баги без всякой теории и знаний о классах и т.д.

  • Аноним

    Есть решение!!!!!!

    1. Сгенерировать кучу мануальных тест-кейсов,
    которые покроют все комбинации:
    http://codepad.org/OfiUwxtA

    2. Попросить расширить штат тестировщиков до 2000
    человек

    3. Увеличить время регрессионного тестирования до
    1-го года.

    Конкретно тестировщик мало что может сделать, если сам
    создатель системы решил внести в нее деструктивный элемент. А если это было
    сделано умышлено, то тут уж точно – только везение может помочь.

    • Andrey Myasnikov

      Дима, это превосходно! Вот только не 2000, а 3000!
      Управляем рисками, чо )

      • Аноним

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

        Хорошо, что мы используем ексели, майндмапы и чеклисты для реального тестирования, а те тест-кейсы так и остаются write-only

        • Andrey Myasnikov

          А чего смеяться. Перестраховка она и есть.

  • Павел

    Это два разных метода, для достижения лучшего результата следует использовать оба. Причем делать это должны разные люди.
    Ситуация, кстати, не сферическая в вакууме, видел обе ее ипостаси:
    На днях, за день до выставки, брат нашел критическую проблему в новой прошивке устройства, вбив единственное значение при котором система шла вразнос.
    Много лет назад обслуживал узлы оперативного учета нефти. На одном цеху операторы жаловались, что «компьютер», считающий сколько в перекачанной эмульсии нефти, а сколько воды, дурит и не считает нефть. Замена компьютера результата не дала. 3 дня вникали в ситуацию — оказался 0 в таблице температурных коэффициентов на значении, близком к рабочей температуре на конкретной насосной станции.

  • Pingback: Ещё одн&#10...

  • ilka

    элементарно
    1 надо было тестировать под дебагом
    2 оторвать яйки програмисту

Social Widgets powered by AB-WebLog.com.