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

Введение


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



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


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


Определения


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


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

Обратимся к википедии и здравому смыслу:
Пробле́ма (др.-греч. πρόβλημα) в широком смысле — сложный теоретический или практический вопрос, требующий изучения, разрешения; в науке — противоречивая ситуация, выступающая в виде противоположных позиций в объяснении каких-либо явлений, объектов, процессов и требующая адекватной теории для её разрешения; в жизни проблема формулируется в понятном для людей виде «знаю что, не знаю как», то есть известно, что нужно получить, но неизвестно, как это сделать. Происходит от поздн. лат. problēma, из греч. πρόβλημα «брошенное вперёд, поставленное впереди»; от προβάλλω «кидать вперёд, выставлять перед собой; обвинять».


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


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


Решение


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


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

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


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


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


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

Подробнее
Реклама

Комментарии 41

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

      А что было про лифт?

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

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

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

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

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

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

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

                  0

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

                    0

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

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

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


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


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

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

            +4

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

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

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


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

                0
                Это и есть фундаментальная проблема — любой проект требует тестирования, но время, на него потраченное, должно стремиться к нулю.
                +1
                zakonbase.ru/content/part/438050?print=1

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

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

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

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



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

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



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

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


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

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

                        0

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

                          0

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

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

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


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

                                0
                                Коллега, что вы хотите услышать?
                                Доказать?
                                Можно бесконечно придумывать сложности и почему это плохо.
                                Или почему нельзя тестировть архитектуру…
                                Какой вы хотите получить ответ?

                                С чайником, например, его отрисовали, и тестировщики посмотрели и спросили.
                                Чайник красивый, но крышка так сделана, что мы не сможем стенд который ее будет открывать и закрывать автоматически. Мы не сможем провести ресурсные испыания. А это важно. И крышку меняют.
                                  0
                                  Коллега, что вы хотите услышать?
                                  Доказать?
                                  Можно бесконечно придумывать сложности и почему это плохо.
                                  Или почему нельзя тестировть архитектуру…
                                  Какой вы хотите получить ответ?

                                  Хочу сказать, что есть нюансы, о которых софтверщики не знают.

                                    0
                                    Не знают конечно, материальное производство это вообще другой мир.
                                    Кстати верно и обратное…
                        0

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

                        0

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

                          0

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

                            0
                            это называется «проблема бесконечного автомата»
                            0

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

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

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

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

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

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

                                    0
                                    Описать сценарии можно. Описать ВСЕ сценарии со всеми параметрами — я бы на это с интересом посмотрел :))
                                0
                                Это не проблема. Это принцип. Исчерпыающее тестирование невозможно. Все. :) Можно не заморачиваться :)

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое