Фундаментальная проблема тестирования +7



Введение


Добрый день, хабровчане. Решал я тут давеча тестовое задание на вакансию QA Lead для одной финтех компании. Первая задача, составить тест-план с полным чек-листом и примерами тест-кейсов для проверки электрического чайника, решается тривиально:



А вот вторая часть оказалась вопросом: “Существуют ли какие-то проблемы, общие для всех тестировщиков, мешающие работать с большей эффективностью?”.


Первое, что пришло в голову: перечислить все более-менее заметные проблемы, с которыми сталкивался при тестировании, отсеять мелочевку, остальное обобщить. Но быстро понял, что индуктивный метод ответит на вопрос, относящийся не ко “всем”, а, в лучшем случае, лишь к “большинству” тестировщиков. Поэтому решил подойти с другой стороны, дедуктивной, и вот что получилось.


Определения


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


  • проблема
  • тестировщик
  • работа тестировщика
  • эффективность работы тестировщика

Обратимся к википедии и здравому смыслу:
Пробле?ма (др.-греч. ????????) в широком смысле — сложный теоретический или практический вопрос, требующий изучения, разрешения; в науке — противоречивая ситуация, выступающая в виде противоположных позиций в объяснении каких-либо явлений, объектов, процессов и требующая адекватной теории для её разрешения; в жизни проблема формулируется в понятном для людей виде «знаю что, не знаю как», то есть известно, что нужно получить, но неизвестно, как это сделать. Происходит от поздн. лат. problema, из греч. ???????? «брошенное вперёд, поставленное впереди»; от ???????? «кидать вперёд, выставлять перед собой; обвинять».


Смысла не много, по сути, “проблема” = “что-угодно, с чем надо разобраться”.
Тестиро?вщик — специалист (на виды разделять не будем, так как нас интересуют все тестировщики), принимающий участие в тестировании компонента или системы, результатом деятельности которого является:
Работа тестировщика — комплекс мероприятий относящийся к тестированию.
Эффекти?вность (лат. effectivus) — соотношение между достигнутым результатом и использованными ресурсами (ISO 9000:2015).
Результа?т — последствие цепочки (череды) действий (итог) или событий, выраженных качественно или количественно. Возможные результаты включают преимущество, неудобство, выгоду, потерю, ценность и победу.
Как и с “проблемой” смысла мало: что-то, что получилось в итоге работы.
Ресурс — количественно измеряемая возможность выполнения какой-либо деятельности человека или людей; условия, позволяющие с помощью определённых преобразований получить желаемый результат. Тестировщик — человек, а в соответствии с теорией витальных ресурсов, каждый человек является обладателем четырех экономических активов:
денежных средств (доход) — ресурс возобновляемый;
энергии (жизненная сила) — ресурс частично возобновляемый;
времени — ресурс фиксированный и принципиально невозобновляемый;
знаний (информации) — ресурс возобновляемый, это часть человеческого капитала, которая может и нарастать, и разрушаться[1].


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


Решение


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


  1. Работа с требованиями
  2. Формирование технического задания
  3. Разработка
  4. Тестирование
  5. Выпуск в производство
  6. Поддержка (goto п.1)

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


Как с этим быть?


Выводы вполне очевидны и многими давно используются:


  1. Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
  2. Чем больше в проекте фич (чем он сложней) тем больше времени придется тратить на проверку того, что новая функциональность не поломала старой. Отсюда чем сложней проект — тем больше требуется автоматизации регрессионного тестирования.
  3. Каждый раз, когда мы пропускаем баг в продакшн, и пользователь его находит, — нам приходится тратить дополнительное время на прохождение по жизненному циклу проекта начиная с п.1 (Работа с требованиями, в данном случае, пользователей). Так как причины пропуска бага в общем случае неизвестны, нам остается только один путь оптимизации — каждый, найденный пользователями баг должен быть включен в регрессионное тестирование, чтобы быть уверенным, что больше он не появится.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (36):

  1. vladshulkevich
    /#20733348

    Прикольно. Мне тоже это задание прилетало. Там еще было «лифта или чайника на ваш выбор». Думаю, распишу им лифт по лифтовому алгоритму Торвальдса, но потом забил. Ибо: для джуна своя воронка подбора, для мидла — своя, а для синьора никакой воронки нет, его надо хантить. Итак, есть ли какая-то проблема, общая для всех эйчаров?

    • urtow
      /#20733452

      Хантите меня! Я еще автоматизировать умею!

      • vladshulkevich
        /#20733720

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

        • urtow
          /#20734032

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

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

    • snayp
      /#20736498

      Уверенность, что у них самый, самый проект, с идеальными условиями, именно для Вас!

  2. vladshulkevich
    /#20733434

    «Составить тест-план с полным чек-листом и примерами тест-кейсов для проверки лифта»

    • lingvo
      /#20737488

      И какой ответ на него? Просто не догоняю про Торвальдса — там же он только только elevator называется, а с лифтом не имеет ничего общего вроде.

      • vladshulkevich
        /#20737782

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

        • lingvo
          /#20738482

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

          • hitromudr
            /#20741716

            Именно поэтому лучшим решением вопроса является отсылка к стандартам, где это все прописано

            • lingvo
              /#20742136

              Вы не проверите лифт на функциональность, руководствуясь только стандартами. Я это хочу сказать.

              • hitromudr
                /#20742382

                docs.cntd.ru/document/1200135770
                docs.cntd.ru/document/gost-22011-95
                docs.cntd.ru/document/1200144600
                а вы почитайте повнимательней стандарты и поймете, что очень сильно заблуждались

                • lingvo
                  /#20742910

                  Я как-бы в этой сфере кручусь немного. И то, что вы пишете — это стандарты, направленные на:
                  а) безопасность
                  б) стандартизацию, чтобы потребитель мог запланировать лифт в своем здании, не привязываясь к конкретному производителю.


                  А вот функциональность — самое интересное, в этих стандартах не описана. Например стандарт требует:


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

                  Ок. Что такое система группового управления? Как ее проверять, какими тестами? Какой реакции вы ожидаете в каждом из тестов? Какие критерии оценки вы будете использовать?

  3. selotec
    /#20735348

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

    • hitromudr
      /#20736688

      — В вашей столовой так плохо кормят!.. И порции слишком маленькие…

  4. a1ex322
    /#20736500

    это такое состояние проекта, когда время на тестирование равно нулю


    Подождите, а разве не любой проект требует тестирования? Проверки, что при А на входе получится Б на выходе как того требует ТЗ?

    • hitromudr
      /#20736520

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

  5. vladshulkevich
    /#20736950

    zakonbase.ru/content/part/438050?print=1

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

  6. ValdemarV
    /#20739876

    Хорошая статья. спасибо!

  7. SergeyTitkov
    /#20739878

    Выводы вполне очевидны и многими давно используются:

    1. Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.



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

    1. Чем больше в проекте фич (чем он сложней) тем больше времени придется тратить на проверку того, что новая функциональность не поломала старой. Отсюда чем сложней проект — тем больше требуется автоматизации регрессионного тестирования.



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

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


    В зависимости от многих факторов… И не должен и не каждый… Поскольку это дорого!

    • lingvo
      /#20740234

      Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
      Не совсем, тестирование должно начинаться раньше. Хорошо когда тестирование начинается тогда же когда ведется разработка требований(SRS).
      Идеально если в момент разработки архитектуры

      Вопрос и к вам и к автору — и как вы собираетесь это применить применительно к чайнику?

      • hitromudr
        /#20741674

        Например, построением тестового стенда для проверки во время самой разработки

        • lingvo
          /#20742152

          Ну есть у вас стенд, а чайник где? Платы еще не разведены, над корпусом маркетологи с CADовцами колдуют.

          • hitromudr
            /#20742436

            У нас есть MVP, его и тестируем… либо вы слишком рано начали стенд собирать

            • lingvo
              /#20743440

              У нас есть MVP, его и тестируем…

              Ага, значит собрали прототип чайника на макетках и понесли в лабораторию испытывать на IEC 60335, так?
              И даже при успешном прохождении испытаний, шанс чего катастрофически мал, идем в лабораторию еще раз после того, как сделали финальный корпус и платы, так как результаты предыдущих испытаний становятся недействительными.


              Надеюсь, вы в курсе сколько стоит всего лишь один цикл испытаний такой техники.

    • hitromudr
      /#20741704

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

  8. VolCh
    /#20741098

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

    • 24twelve
      /#20741150

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

    • hitromudr
      /#20741660

      Эта проблема касается только white-box тестирования, для black-box, такой задачи вообще не стоит

      • Ndochp
        /#20741738

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

        • hitromudr
          /#20741816

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

          • Ndochp
            /#20743836

            В спеке написано: и результат поиска должен выдаваться в течение 5 секунд.

            В реализации в зависимости от неких констант/данных/числа строк в ключевой таблице используется тот или иной алгоритм.
            Из классов эквивалентностей спеки вы не выйдете на тестирование всех алгоритмов поиска.

      • 24twelve
        /#20741746

        Почему? Возьмем, например, пользовательские сценарии. Их модель часто используют для black-box тестирования. И даже эти сценарии очень сложно хотя бы зафиксирировать на бумаге полностью.

        • hitromudr
          /#20741856

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

          • 24twelve
            /#20744680

            Описать сценарии можно. Описать ВСЕ сценарии со всеми параметрами — я бы на это с интересом посмотрел :))