Comments 41
А что было про лифт?
Уверенность, что у них самый, самый проект, с идеальными условиями, именно для Вас!
И какой ответ на него? Просто не догоняю про Торвальдса — там же он только только elevator называется, а с лифтом не имеет ничего общего вроде.
Сорри, но в упор не пойму вот это ваше "чек-лист для проверки функционала пассажирского лифта" и тем более какая-то адаптация. Лифты надо проверять, к примеру, на безопасность. При этом делают это сертифицированные организации, а не простой тестер. А компоненты тех же лифтов испытываются тоже. А по функциональности оно все раскидано по разным стандартам, и то — это только базовые вещи, влияющие на безопасность. А то, что не влияет — это только сам разработчик знает.
Именно поэтому лучшим решением вопроса является отсылка к стандартам, где это все прописано
Вы не проверите лифт на функциональность, руководствуясь только стандартами. Я это хочу сказать.
docs.cntd.ru/document/gost-22011-95
docs.cntd.ru/document/1200144600
а вы почитайте повнимательней стандарты и поймете, что очень сильно заблуждались
Я как-бы в этой сфере кручусь немного. И то, что вы пишете — это стандарты, направленные на:
а) безопасность
б) стандартизацию, чтобы потребитель мог запланировать лифт в своем здании, не привязываясь к конкретному производителю.
А вот функциональность — самое интересное, в этих стандартах не описана. Например стандарт требует:
При установке группы из двух и более пассажирских лифтов, имеющих одинаковые номинальную скорость и, как правило, число остановок, должна быть применена система группового управления с общим вызывным аппаратом управления на каждой посадочной площадке.
Ок. Что такое система группового управления? Как ее проверять, какими тестами? Какой реакции вы ожидаете в каждом из тестов? Какие критерии оценки вы будете использовать?
Статья закончилась гораздо раньше, чем я мог ожидать, а чего-то нового/срыва покровов так и не дождался. Даже проблема оценки тестирования не затронута. Решений тоже очевидные и общие (а иных в такой постановке вопроса не дашь).
В итоге о чем, для кого и для чего статья не понятно.
это такое состояние проекта, когда время на тестирование равно нулю
Подождите, а разве не любой проект требует тестирования? Проверки, что при А на входе получится Б на выходе как того требует ТЗ?
требования к лифтам. Кто будет решать задачу про тестирование лифта.
Не забудьте добавить туда функциональные требования.
Хорошая статья. спасибо!
Выводы вполне очевидны и многими давно используются:
- Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
Не совсем, тестирование должно начинаться раньше. Хорошо когда тестирование начинается тогда же когда ведется разработка требований(SRS).
Идеально если в момент разработки архитектуры
- Чем больше в проекте фич (чем он сложней) тем больше времени придется тратить на проверку того, что новая функциональность не поломала старой. Отсюда чем сложней проект — тем больше требуется автоматизации регрессионного тестирования.
И да и нет. Очень зависит от многих факторов.
Матрицы влияния сильно упрощают жизнь.
И опять же насколько у вас хорошо поставлен процесс QA, не тестирования, а именно QA
- Каждый раз, когда мы пропускаем баг в продакшн, и пользователь его находит, — нам приходится тратить дополнительное время на прохождение по жизненному циклу проекта начиная с п.1 (Работа с требованиями, в данном случае, пользователей). Так как причины пропуска бага в общем случае неизвестны, нам остается только один путь оптимизации — каждый, найденный пользователями баг должен быть включен в регрессионное тестирование, чтобы быть уверенным, что больше он не появится.
В зависимости от многих факторов… И не должен и не каждый… Поскольку это дорого!
Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
Не совсем, тестирование должно начинаться раньше. Хорошо когда тестирование начинается тогда же когда ведется разработка требований(SRS).
Идеально если в момент разработки архитектуры
Вопрос и к вам и к автору — и как вы собираетесь это применить применительно к чайнику?
Например, построением тестового стенда для проверки во время самой разработки
Ну есть у вас стенд, а чайник где? Платы еще не разведены, над корпусом маркетологи с CADовцами колдуют.
У нас есть MVP, его и тестируем…
Ага, значит собрали прототип чайника на макетках и понесли в лабораторию испытывать на IEC 60335, так?
И даже при успешном прохождении испытаний, шанс чего катастрофически мал, идем в лабораторию еще раз после того, как сделали финальный корпус и платы, так как результаты предыдущих испытаний становятся недействительными.
Надеюсь, вы в курсе сколько стоит всего лишь один цикл испытаний такой техники.
Доказать?
Можно бесконечно придумывать сложности и почему это плохо.
Или почему нельзя тестировть архитектуру…
Какой вы хотите получить ответ?
С чайником, например, его отрисовали, и тестировщики посмотрели и спросили.
Чайник красивый, но крышка так сделана, что мы не сможем стенд который ее будет открывать и закрывать автоматически. Мы не сможем провести ресурсные испыания. А это важно. И крышку меняют.
Нюансы можно уточнять бесконечно. Я постарался решить задачу теоретическими методами. Задача была в определении проблемы общей для всех тестировщиков, остальное — частности
Я думал, что фундаментальна проблема тестирования — это практическая невозможность протестировать все состояния системы под тестами. Даже с применением всяких областей эквивалентности комбинаторный взрыв приведёт к тому, что все состояния всё равно не протестировать. Собственно проблема в том, чтобы выбрать, что тестировать, а что нет.
Эта проблема касается только white-box тестирования, для black-box, такой задачи вообще не стоит
Фундаментальная проблема тестирования