«

»

Сен 06

Мысли о «QC-демотиваторах» от Александра Калугина (PMarcor). Задача №1.

Помнится, на первой веб-конференции Stratoplan (Стратоконф-1), выступал Александр Калугин, автор блога http://PMarcor.com с темой «Motivational Debt & Software Engineering или «не все задачи одинаково полезны»»

Как я и писал ранее «Примерно половина задач, от которых не прет программистов – весьма даже прет тестировщиков».

Александр проанализировал эту ситуацию и посвятил теме демотиваторов в области тестирования целый пост.

 Я позволю себе прокомментировать каждую из задач.

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

Задача №1. «Здесь не ступала нога разработчика…»

Часто, автоматизация невозможна, или очень сложна, и приходится ходить вручную по регрессионному набору. А из песни слова не выкинешь… Если есть тест-кейс – то уж будь любезен… И ходишь 25 билдов подряд по кейсам, которые к изменениям разработчиков не имеют отношения…

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

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

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

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

Рассмотрим пример:

Есть у нас консоль, которая просит ввести два числа и сразу после второго числа выводит сумму введенных двух чисел. Мы знаем что в этом методе были сделаны изменения. Нам его надо протестировать.

Есть у нас старый добрый тест, который прогоняется уже три регрессии подряд:

  • Ввести 120, нажать ввод.
  • Ввести 5, нажать ввод.
  • Ожидаемый результат: в третьем поле отображается сумма 125.

Не находит этот тест ошибок. Ну вот так вот — не находит. Хороший тест, правильный такой.

А теперь, во время тестирования, проверим такой вариант:

  • Ввести 125, нажать ввод.
  • Ввести 3, нажать ввод.
  • Ожидаемый результат: в третьем поле отображается сумма 128.

Выполняем и видим на экране: -128

Обидно, правда?:)

Какой код это может вызывать?

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

using System;

namespace sum_mass
{
    class Program
    {
        static void Main(string[] args)
        {

            sbyte Summ = 0;
            for (int i = 0; i < 2; i++)
            {
                int count = i+1;
                Console.WriteLine("Введите " + count + "-ое число");
                Summ += sbyte.Parse(Console.ReadLine());

            }

            Console.WriteLine("Сумма введенных чисел равна:" + Summ);
            Console.ReadKey();
        }
    }
} 

Ошибка возникает из-за того, что для хранения суммы используется поле sbyte типа. Тип sbyte в C# может описывать значение от -128 до 127. И, при использовании значений больше или меньше этих чисел, мы «бегаем по кругу».

Почему это отловилось на этапе регрессионного тестирования? Хороший вопрос. Отличнейший. Но так бывает. И это повод пойти и пройти квест: «Менеджер, а что это такое и почему?».

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

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

8 комментариев

Перейти полю для комментария

  1. Andrey Aderkin

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

    1. Сергей Атрощенков

      Андрей, а всегда-ли введенные значения стоит оставлять на совести инженера?
      Мне не уютно с тем уровнем отчетности который можно получить с подобными тестовыми наборами.
      1. Проверить суммирование двух полей, тип поля суммы byte.
      Что человек проверял? А точно ли его проверки покроют тип байт, и отловят проблему переполнения sbyte?:)
      Мне тоже не нравится детальные шаги, но как сохранить понимание того, что было протестировано (вплоть до того, какие значения вбивались), для анализа и изменения тестов — я не знаю.

  2. Sergey Martynenko

    Странные вы вещи говорите.

    > Ошибка возникает из-за того, что для хранения суммы используется поле sbyte типа. Тип sbyte в C# может описывать значение от -128 до 127.

    Если это не было отловлено на этапе первого тестирования, то встает резонный вопрос. Почему? Как пропустили тест на переполнение?!?!

    > И ходишь 25 билдов подряд по кейсам, которые к изменениям разработчиков не имеют
    отношения…

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

    1. Сергей Атрощенков

      Если это не было отловлено на этапе первого тестирования, то встает резонный вопрос. Почему? Как пропустили тест на переполнение?!?!

      Согласен, как я писал выше:

      почему это отловилось на этапе регрессионного тестирования? Хороший вопрос. Отличнейший. Но так бывает. И это повод пойти и пройти квест: «Менеджер, а что это такое и почему?».

      Сергей, согласитесь, что не везде тестирование происходит по всем канонам, не везде проверяются даже граничные значения, не говоря уже про переполнение. Не везде выполняется ревью кода, т.к. по бизнес-сценариям могли быть допустимы значения 127+127 и sum всю жизнь было byte, но вот подумал программист и тип изменил во время рефакторинга.

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

      И ходишь 25 билдов подряд по кейсам, которые к изменениям разработчиков не имеют
      отношения…

      >А зачем? Если код нормальный, то это бессмысленная трата времени и денег. Если код плохой, то нужно не тестировать, а код рефакторить.

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

  3. Helen Radilova

    но вот подумал программист и тип изменил во время рефакторинга.:))))

    У вас не программист, а полтергейст какой-то. Суть сущность непредсказуемая.

    Ежели программист отрефакторил что-то, а тестировщик не в курсе, то начинайте сначала тестить… регрессионное все не выловит.

    1. Сергей Атрощенков

      для Вас подобное поведение программистов и отсутствие доступа к исходникам тестировщика — что-то необычное?:)

  4. Сергей Атрощенков

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

  5. Helen Radilova

    достаточно ввести ревью кода разработчиками, а не гиками-фанатами)))))

    не спасет. У Вас пример просто такой. Одноярусный :))). Проект софта нужен.
    Все эти просмотры/ревью проекта/кода денежков стоят :))).
    Поищите в сети — ГОСТ Р 51904.
    Там расписано кратенько — что проверять.Требования, проект,код.
    Ну ежели вовсе идеял нужен -то ГОСТ РВ 0019 (там вояки на тестировщиках оттянулись по полной. Но всего на 80 стр. И расписали — что с требованиями-как проверять, что с проектом, что с кодом и тыпы .)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>