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

[vladshulkevich]

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

[lingvo]

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

[urtow]

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

[vladshulkevich]

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

[urtow]

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

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

[snayp]

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

[vladshulkevich]

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

[lingvo]

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

[vladshulkevich]

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

[lingvo]

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

[hitromudr]

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

[lingvo]

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

[hitromudr]

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

[lingvo]

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

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

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

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

[selotec]

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

[hitromudr]

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

[a1ex322]

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

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

[hitromudr]

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

[vladshulkevich]

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

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

[ValdemarV]

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

[SergeyTitkov]

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

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

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

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

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

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

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

[lingvo]

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

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

[hitromudr]

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

[lingvo]

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

[hitromudr]

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

[lingvo]

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

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

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

[SergeyTitkov]

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

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

[lingvo]

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

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

[SergeyTitkov]

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

[hitromudr]

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

[VolCh]

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

[vladshulkevich]

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

[hitromudr]

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

[Ndochp]

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

[hitromudr]

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

[Ndochp]

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

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

[hitromudr]

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

[SergeyTitkov]

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