Введение
Добрый день, хабровчане. Решал я тут давеча тестовое задание на вакансию QA Lead для одной финтех компании. Первая задача, составить тест-план с полным чек-листом и примерами тест-кейсов для проверки электрического чайника, решается тривиально:
- ГОСТ 7400-81. Электрочайники и электросамовары бытовые. Технические условия (с Изменениями N 1-8)
- ГОСТ IEC 60335-1-2015 Бытовые и аналогичные электрические приборы. Безопасность. Часть 1. Общие требования
Лучшего тест-плана с полным чек-листом придумать сложно.
А вот вторая часть оказалась вопросом: “Существуют ли какие-то проблемы, общие для всех тестировщиков, мешающие работать с большей эффективностью?”.
Первое, что пришло в голову: перечислить все более-менее заметные проблемы, с которыми сталкивался при тестировании, отсеять мелочевку, остальное обобщить. Но быстро понял, что индуктивный метод ответит на вопрос, относящийся не ко “всем”, а, в лучшем случае, лишь к “большинству” тестировщиков. Поэтому решил подойти с другой стороны, дедуктивной, и вот что получилось.
Определения
Первое, что я обычно делаю, решая новую задачу, — это пытаюсь понять о чем она вообще, а для этого надо понять смысл слов, которыми она поставлена. Ключевые слова, в которых надо разобраться, следующие:
- проблема
- тестировщик
- работа тестировщика
- эффективность работы тестировщика
Обратимся к википедии и здравому смыслу:
Пробле?ма (др.-греч. ????????) в широком смысле — сложный теоретический или практический вопрос, требующий изучения, разрешения; в науке — противоречивая ситуация, выступающая в виде противоположных позиций в объяснении каких-либо явлений, объектов, процессов и требующая адекватной теории для её разрешения; в жизни проблема формулируется в понятном для людей виде «знаю что, не знаю как», то есть известно, что нужно получить, но неизвестно, как это сделать. Происходит от поздн. лат. problema, из греч. ???????? «брошенное вперёд, поставленное впереди»; от ???????? «кидать вперёд, выставлять перед собой; обвинять».
Смысла не много, по сути, “проблема” = “что-угодно, с чем надо разобраться”.
Тестиро?вщик — специалист (на виды разделять не будем, так как нас интересуют все тестировщики), принимающий участие в тестировании компонента или системы, результатом деятельности которого является:
Работа тестировщика — комплекс мероприятий относящийся к тестированию.
Эффекти?вность (лат. effectivus) — соотношение между достигнутым результатом и использованными ресурсами (ISO 9000:2015).
Результа?т — последствие цепочки (череды) действий (итог) или событий, выраженных качественно или количественно. Возможные результаты включают преимущество, неудобство, выгоду, потерю, ценность и победу.
Как и с “проблемой” смысла мало: что-то, что получилось в итоге работы.
Ресурс — количественно измеряемая возможность выполнения какой-либо деятельности человека или людей; условия, позволяющие с помощью определённых преобразований получить желаемый результат. Тестировщик — человек, а в соответствии с теорией витальных ресурсов, каждый человек является обладателем четырех экономических активов:
денежных средств (доход) — ресурс возобновляемый;
энергии (жизненная сила) — ресурс частично возобновляемый;
времени — ресурс фиксированный и принципиально невозобновляемый;
знаний (информации) — ресурс возобновляемый, это часть человеческого капитала, которая может и нарастать, и разрушаться[1].
Хочу отметить, что определение эффективности в нашем случае не совсем корректное, так как чем больше знаний мы используем, тем ниже получается эффективность. Поэтому я бы переопределил эффективность как “соотношение между достигнутым результатом и затраченными ресурсами”. Тогда все корректно: знания при работе не тратятся, но уменьшают затраты единственного принципиально невозобновляемого ресурса тестировщика — его времени.
Решение
Итак, ищем глобальные проблемы тестировщиков, ухудшающие эффективность их работы.
Наиболее значимым ресурсом, который тратится на работу тестировщика является его время (остальные так или иначе можно к нему привести), а для того, чтобы мы могли говорить о корректном расчете эффективности, надо и результат привести ко времени.
Для этого рассмотрим систему, жизнеспособность которой тестировщик обеспечивает своей работой. Такой системой является проект, в команду которого входит тестировщик. Жизненный цикл проекта можно грубо представить следующим алгоритмом:
- Работа с требованиями
- Формирование технического задания
- Разработка
- Тестирование
- Выпуск в производство
- Поддержка (goto п.1)
При этом весь проект можно рекурсивно разбить на подпроекты (фичи), с тем же жизненным циклом.
С точки зрения проекта, эффективность его реализации тем больше, чем меньше времени на него потрачено.
Таким образом, мы приходим к определению максимально возможной эффективности тестировщика с точки зрения проекта — это такое состояние проекта, когда время на тестирование равно нулю. А общей проблемой для всех тестировщиков является невозможность этого времени достичь.
Как с этим быть?
Выводы вполне очевидны и многими давно используются:
- Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
- Чем больше в проекте фич (чем он сложней) тем больше времени придется тратить на проверку того, что новая функциональность не поломала старой. Отсюда чем сложней проект — тем больше требуется автоматизации регрессионного тестирования.
- Каждый раз, когда мы пропускаем баг в продакшн, и пользователь его находит, — нам приходится тратить дополнительное время на прохождение по жизненному циклу проекта начиная с п.1 (Работа с требованиями, в данном случае, пользователей). Так как причины пропуска бага в общем случае неизвестны, нам остается только один путь оптимизации — каждый, найденный пользователями баг должен быть включен в регрессионное тестирование, чтобы быть уверенным, что больше он не появится.
Комментарии (36)
vladshulkevich
09.10.2019 16:57«Составить тест-план с полным чек-листом и примерами тест-кейсов для проверки лифта»
lingvo
10.10.2019 13:25И какой ответ на него? Просто не догоняю про Торвальдса — там же он только только elevator называется, а с лифтом не имеет ничего общего вроде.
vladshulkevich
10.10.2019 14:02Есть описание лифтового алгоритма Торвальдса. Попробуйте написать чек-лист для проверки того, что он работает верно, как требует описание. Попробуйте адаптировать этот чек-лист для проверки функционала пассажирского лифта.
lingvo
10.10.2019 15:44Сорри, но в упор не пойму вот это ваше "чек-лист для проверки функционала пассажирского лифта" и тем более какая-то адаптация. Лифты надо проверять, к примеру, на безопасность. При этом делают это сертифицированные организации, а не простой тестер. А компоненты тех же лифтов испытываются тоже. А по функциональности оно все раскидано по разным стандартам, и то — это только базовые вещи, влияющие на безопасность. А то, что не влияет — это только сам разработчик знает.
hitromudr Автор
11.10.2019 10:39Именно поэтому лучшим решением вопроса является отсылка к стандартам, где это все прописано
lingvo
11.10.2019 12:00Вы не проверите лифт на функциональность, руководствуясь только стандартами. Я это хочу сказать.
hitromudr Автор
11.10.2019 12:31docs.cntd.ru/document/1200135770
docs.cntd.ru/document/gost-22011-95
docs.cntd.ru/document/1200144600
а вы почитайте повнимательней стандарты и поймете, что очень сильно заблуждалисьlingvo
11.10.2019 13:58Я как-бы в этой сфере кручусь немного. И то, что вы пишете — это стандарты, направленные на:
а) безопасность
б) стандартизацию, чтобы потребитель мог запланировать лифт в своем здании, не привязываясь к конкретному производителю.
А вот функциональность — самое интересное, в этих стандартах не описана. Например стандарт требует:
При установке группы из двух и более пассажирских лифтов, имеющих одинаковые номинальную скорость и, как правило, число остановок, должна быть применена система группового управления с общим вызывным аппаратом управления на каждой посадочной площадке.
Ок. Что такое система группового управления? Как ее проверять, какими тестами? Какой реакции вы ожидаете в каждом из тестов? Какие критерии оценки вы будете использовать?
selotec
10.10.2019 04:18Статья закончилась гораздо раньше, чем я мог ожидать, а чего-то нового/срыва покровов так и не дождался. Даже проблема оценки тестирования не затронута. Решений тоже очевидные и общие (а иных в такой постановке вопроса не дашь).
В итоге о чем, для кого и для чего статья не понятно.
a1ex322
10.10.2019 10:53это такое состояние проекта, когда время на тестирование равно нулю
Подождите, а разве не любой проект требует тестирования? Проверки, что при А на входе получится Б на выходе как того требует ТЗ?
hitromudr Автор
10.10.2019 10:54Это и есть фундаментальная проблема — любой проект требует тестирования, но время, на него потраченное, должно стремиться к нулю.
vladshulkevich
10.10.2019 12:02zakonbase.ru/content/part/438050?print=1
требования к лифтам. Кто будет решать задачу про тестирование лифта.
Не забудьте добавить туда функциональные требования.
SergeyTitkov
10.10.2019 19:57Выводы вполне очевидны и многими давно используются:
- Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
Не совсем, тестирование должно начинаться раньше. Хорошо когда тестирование начинается тогда же когда ведется разработка требований(SRS).
Идеально если в момент разработки архитектуры
- Чем больше в проекте фич (чем он сложней) тем больше времени придется тратить на проверку того, что новая функциональность не поломала старой. Отсюда чем сложней проект — тем больше требуется автоматизации регрессионного тестирования.
И да и нет. Очень зависит от многих факторов.
Матрицы влияния сильно упрощают жизнь.
И опять же насколько у вас хорошо поставлен процесс QA, не тестирования, а именно QA
- Каждый раз, когда мы пропускаем баг в продакшн, и пользователь его находит, — нам приходится тратить дополнительное время на прохождение по жизненному циклу проекта начиная с п.1 (Работа с требованиями, в данном случае, пользователей). Так как причины пропуска бага в общем случае неизвестны, нам остается только один путь оптимизации — каждый, найденный пользователями баг должен быть включен в регрессионное тестирование, чтобы быть уверенным, что больше он не появится.
В зависимости от многих факторов… И не должен и не каждый… Поскольку это дорого!lingvo
10.10.2019 21:20Разработка и тестирование должны начинаться и заканчиваться практически одновременно (этим обычно занимается отдел QA). Идеальный вариант, когда вся разрабатываемая функциональность к моменту готовности уже покрыта автотестами, организованными в регрессионное (а по возможности и пред-коммитное) тестирование с помощью какого-нибудь CI.
Не совсем, тестирование должно начинаться раньше. Хорошо когда тестирование начинается тогда же когда ведется разработка требований(SRS).
Идеально если в момент разработки архитектурыВопрос и к вам и к автору — и как вы собираетесь это применить применительно к чайнику?
hitromudr Автор
11.10.2019 10:30Например, построением тестового стенда для проверки во время самой разработки
lingvo
11.10.2019 12:02Ну есть у вас стенд, а чайник где? Платы еще не разведены, над корпусом маркетологи с CADовцами колдуют.
hitromudr Автор
11.10.2019 12:41У нас есть MVP, его и тестируем… либо вы слишком рано начали стенд собирать
lingvo
11.10.2019 15:40У нас есть MVP, его и тестируем…
Ага, значит собрали прототип чайника на макетках и понесли в лабораторию испытывать на IEC 60335, так?
И даже при успешном прохождении испытаний, шанс чего катастрофически мал, идем в лабораторию еще раз после того, как сделали финальный корпус и платы, так как результаты предыдущих испытаний становятся недействительными.
Надеюсь, вы в курсе сколько стоит всего лишь один цикл испытаний такой техники.
hitromudr Автор
11.10.2019 10:36Нюансы можно уточнять бесконечно. Я постарался решить задачу теоретическими методами. Задача была в определении проблемы общей для всех тестировщиков, остальное — частности
VolCh
11.10.2019 06:55Я думал, что фундаментальна проблема тестирования — это практическая невозможность протестировать все состояния системы под тестами. Даже с применением всяких областей эквивалентности комбинаторный взрыв приведёт к тому, что все состояния всё равно не протестировать. Собственно проблема в том, чтобы выбрать, что тестировать, а что нет.
hitromudr Автор
11.10.2019 10:26Эта проблема касается только white-box тестирования, для black-box, такой задачи вообще не стоит
Ndochp
11.10.2019 10:43Разве? даже в блекбоксе у вас набор параметров приводит к взрыву. Причем, так как ящик черный вы не можете эффективно вычислить граничные значения параметров. То есть и областей эквивалентности не собрать.
hitromudr Автор
11.10.2019 10:59Граничные параметры для черного ящика определяются спекой, а не кодом, вот и вся разница. За 15 лет функционального тестирования ни разу не сталкивался с проблемой сложности определения классов эквивалентности.
Ndochp
11.10.2019 16:54В спеке написано: и результат поиска должен выдаваться в течение 5 секунд.
В реализации в зависимости от неких констант/данных/числа строк в ключевой таблице используется тот или иной алгоритм.
Из классов эквивалентностей спеки вы не выйдете на тестирование всех алгоритмов поиска.
24twelve
11.10.2019 10:47Почему? Возьмем, например, пользовательские сценарии. Их модель часто используют для black-box тестирования. И даже эти сценарии очень сложно хотя бы зафиксирировать на бумаге полностью.
hitromudr Автор
11.10.2019 11:09Насколько я вижу глядя на тестовую документацию в компании (биржевой функционал плюс крипто кошелек) нет проблемы описать пользовательские сценарии. Более того без них даже разработка не начинается.
24twelve
11.10.2019 20:02Описать сценарии можно. Описать ВСЕ сценарии со всеми параметрами — я бы на это с интересом посмотрел :))
vladshulkevich
Прикольно. Мне тоже это задание прилетало. Там еще было «лифта или чайника на ваш выбор». Думаю, распишу им лифт по лифтовому алгоритму Торвальдса, но потом забил. Ибо: для джуна своя воронка подбора, для мидла — своя, а для синьора никакой воронки нет, его надо хантить. Итак, есть ли какая-то проблема, общая для всех эйчаров?
lingvo
А что было про лифт?
urtow
Хантите меня! Я еще автоматизировать умею!
vladshulkevich
Вот, когда умеешь автоматизировать, тут наступает самый сенокос. На одном собеседовании тебе дают тестировать чайник, на другом — предлагают что-нить замысловатое извратить за один проход двумя курсорами с двух концов.
urtow
Проблема в том, что я еще админ, саппорт, бармен, фермер, повар, кондитер и черт в ступе (чем в этой жизни не приходилось зарабатывать).
Так что обычно на долбанутые вопросы я прошу объяснить мне, действительно ли такой херней придется заниматься на работе?
snayp
Уверенность, что у них самый, самый проект, с идеальными условиями, именно для Вас!