Когда я был молодым (все бывают молодыми) стажером — старшие сослуживцы мнс подрабатывали в РЖ Химия (речь о химическом НИИ РАН СССР). Они говорили, что проще одобрить реферат, чем отклонить, т.к. в случае отклонения нужно написать пару фраз обоснования. Еще тогда я задумался об эффективности рецензирования и критики. Позже, когда работал с западными издательствами, увидел, что там с этим не лучше.
В конце лета на Хабре была публикация “Тестирование тестировщиков”, но там про трудоустройство. А здесь про случаи, когда в фирму или издательство трудоустраиваться не хотите, а хотите, как заказчик, получить хороший софт или, как автор, быть опубликованным в журнале. Как узнать, что тестер, рецензент, редактор добросовестно выполнили свою работу?
Критика
Реакция на критику у авторов противоречива. С одной стороны не приятно, когда критикуют, с другой – надежда, что на явные ошибки укажут, и статья не будет содержать таких явных опечаток, как
e=2.718281928459045…
Бородинская битва была в 1912 г.
Метод
Где-то, когда-то прочитал об интересном методе тестирования софта: в исходный код вносится 10 ошибок, если тестер отловил из них 9 + еще 2 других, то можно надеется, что в неиспорченном коде осталось 10% от изначальных ошибок. Этот метод сработает и для публикации: сотрите закрывающую скобку в выражении в листинге или программную скобку: на С/С++ это “}”, на Паскале это “end”. Компилятор скорее всего возмутится, но если возмутится тестер, то это будет значить, что он потрудился пропустить ваш листинг через компилятор. Иначе гарантий нет от формального просмотра по диагонали.
(Предлагал добавить в ЯП ключевое слово endAll, чтобы компилятор сам закрыл все скобки, вместо того, чтобы 5 раз писать “end” в конце процедуры).
Оставь поле редактору
Этому методу созвучен метод, которому меня учили мои наставники: оставь поле редактору. Т.е. если у вас вылизанная статья, то стоит туда добавить несколько явных ошибок. Редактор тоже человек (кушать хочет) и ему нужно доказывать свою полезность. А вы легко согласитесь, что слово “кАгда” написано неверно и что 2+2 не 5.
В заключение
Возвращаясь к тестированию софта. Попробуйте написать что-то типа:
x:=y // присвоить y значение x
Кто из тестеров заметит несообразность?
Возможен и провокационный метод. Тимлид говорит: я внес в код 10 ошибок, а на самом деле только 2. Но вся команда роет землю, чтобы найти 10.
Текст этой статьи прогнал на чекерах и добавил ошибки. Интересно, кто сколько найдет. — Всем заранее благодарен. И м.б. Вы уже использовали эту методику – пишите в комментариях.
Спасибо за внимание!
Комментарии (21)
fedorro
18.01.2022 13:39Тимлид говорит: я внес в код 10 ошибок, а на самом деле только 2. Но вся команда роет землю, чтобы найти 10.
В итоге команда находит 20 ошибок и тимлида понижают до джуна ????
third112 Автор
18.01.2022 13:48За что его понижать? Премировать надо, что 18 ошибок в коде сумели найти! :)
Korobei
18.01.2022 17:35Как то прочитал про интересную методику bug bash.
По идее должна решить похожую проблему, если в течении bug bash-а нашли много проблем которые тестеры не нашли, то это повод задать вопросы.
Намеренные ошибки конечно интересный подход, но только для авто-тестов. Особенно какие-нибудь граничные случаи.
Но использовать время работников на подобное, не очень эффективно. Может быть только для супер важных или супер распространнённых проектов. Типа тестеры знают что они постоянно под колпаком и будут лучше работать.third112 Автор
18.01.2022 17:45К сожалению, статья ИМХО очень поверхностная об интересной методике:
The topic of this article may not meet Wikipedia's general notability guideline. Please help to demonstrate the notability of the topic by citing reliable secondary sources that are independent of the topic and provide significant coverage of it beyond a mere trivial mention. If notability cannot be shown, the article is likely to be merged, redirected, or deleted.
Вы написали:
Но использовать время работников на подобное, не очень эффективно.
О каком времени речь? Работник тестирует код. Если нашел ошибку, то затратит минуту, чтобы отметить. 10 ошибок = 10 минут — копейки!
Korobei
18.01.2022 18:18Тестеры всё таки не тестируют код. Они тестируют продукт.
После того как вы эти ошибки уберёте, они будут обязанны перетестировать всё ещё раз.
Потому что, если внесены ошибки которые не затрагивают более-менее важный кусок функциональности, то они не очень полезны. Типа как опечатка в тексте.
А если затрагивают — то это уже сложные сценарии, могут появиться наведённые ошибки. Вы сделели десять намеренных ошибок в коде, а в продукте появилось 50 новых ошибок в функциональности.
Для проверки того что весь код был вызван при тестировании, есть специальные инструменты которые показывают какие части кода были вызваны, а какие нет. Например для .net в MS Visual Studio Test Manager и у JetBrains dotCover.
Но нeкоторый код фактически не реально выполнить без сложных манипуляций, типа вытаскивания сетевых кабелей и т.п.
Насколько я понял вы пытаетесь таким образом решить проблему мотивации тестировщиков работать лучше.
Я думаю что альтернативные методики помогут лучше, хотя конечно иногда можно и подобный подход попробовать. Типа раз в год, перед подъёмом зарплаты, это позволит менеджеру обосновать почему тестер не достоин (это сарказм — пояснение для слишком прямолинейных).third112 Автор
18.01.2022 18:28Как иллюстрация моя обсуждаемая здесь заметка. Вот некоторые отмеченные ошибки:
e=2.718281928459045…
Бородинская битва была в 1912 г.
кАгда
2+2= 5
x:=y // присвоить y значение xЕсть еще. Если я выложу версию без указанных ошибок — у Вас сильно меньше времени уйдет на поиск других и на редактуру?
libroten
Мне кажется, подход не очень применим в коммерческой разработке крупных сложных систем
Может, я чего-то не понимаю, но тестировщики вроде не читают код. И если честно, не уверен, что должны.
Опять же - какая команда? Разработчиков (на ревью, например) или тестировщиков? А вы уверены, что хотите потратить время сотрудников на такое? В конце-концов есть пополняющиеся наборы кейсов, которые должны проверить тестеры, есть автотесты, да мало ли что еще.
К тому же, предложенный подход нужно как-то встроить в рабочие процессы. Потому что для примера ситуация, когда, какие-то из специально сделанных ошибок не были найдены, разработчику, который их внес, нужно вернуться к своему пулл реквесту и исправить их (еще и не забыть, что там было внесено, а забыть в потоке рабочих задач - не так сложно).
То же самое ревью кода, как мне кажется, предназначено для каких-то более серьезных вещей - стилистика/читаемость кода, оценка архитектурных решений, оценка решений с точки зрения перспективы поддержки и развития этого кода и так далее. Вы точно хотите, чтобы вместо этого разработчики тратили силы и время на поиск нелепых присваиваний и незакрытых скобок? Особенно в реальности не существующих.
У меня у самого опыта коммерческой разработки пока еще не очень много, так что допускаю, что чего-то не понимаю и могу быть не прав. Если что, поправьте.
third112 Автор
ИМХО в любой работе, не только в IT, очень важно заставить людей не халтирить. Гляжу на новые сайты многих крупных компаний и организаций — и наступает уныние. В упомянутой статье автор предложил сложную схему отбора, время экзаменующие сотрудники потратят много, а гарантии, что хороший спец будет честно работать нет. ИМХО полезно иногда напрягать коллектив. Будут выявлены отдельные работники, которые получили работу по недоразумению. Что делать — с ними придется проститься. Не все люди внимательны и прилежны. А как дворник такой человек может будет лучше, чем тестер или редактор.
sshikov
>А вы уверены, что хотите потратить время сотрудников на такое?
Не, идея-то неплоха (хотя и не нова на самом деле). Иногда надо проверять качество своих процессов, в том числе и тестирования. Поэтому внесение ошибок и их поиск как способ проверки — это известный, и в общем-то работающий метод. Другое дело, что это делается обычно слегка не так.
>тестировщики вроде не читают код. И если честно, не уверен, что должны.
Я тоже не уверен. По крайней мере, чтобы это осмысленно делать, их квалификация должна быть слегка выше (а с ней и зарплата, так или иначе). Далеко не факт, что заказчик захочет платить больше.
third112 Автор
Думаю, что качество работ окупят затраты времени.
А как нужно делать?
А как иначе? Код должен быть документирован. Самые простые способы это содержательные имена и комменты.
BTW Когда в середине 1980х пришел в отдел кадров МВТУ (сейчас МГТУ) им. Баумана оформляться и сказал, что я электронщик — пожилая начальница ОК поправила меня: у нас в штатном расписании нет такой должности, но у меня приказ зачислить Вас на должность старшего инженера-электроника. Я давно не менял работу, и м.б. сейчас есть должности электронщик и тестировщик?
libroten
Увы, часто комментариев и содержательных имен может оказаться недостаточно. Система может быть очень сложной, с кучей связей и так далее. Даже просто, чтобы понять схему работы какого-то модуля часто нужно приложить недюжие умственные усилия. Тем более, если ты не работаешь с этим кодом постоянно, а тестировщики, собственно, и не работают.
sshikov
Есть еще такое соображение, что лучше тестировать код как черный ящик. Не факт, что это всегда правильно, но непосредственный автор кода зачастую пишет тесты плохо — в том числе потому, что знает устройство.
third112 Автор
Да, согласен, что иногда задокументировать код может сложнее, чем этот код написать. Бывают эвристики, а ценят строгие алгоритмы. Но бывает сомнение, что код в точности воспроизводит алгоритм ;)
sshikov
>Думаю, что качество работ окупят затраты времени.
А вы в данном случае кто? Если вы член команды разработки, то мне отчего-то кажется, что и то, и другое — не ваша забота. Потребный уровень качества должен определять заказчик, и он же должен решать, что там со временем. Потому что лишние затраты времени могут означать, что вы выйдете с продуктом на рынок, когда уже будет поздно, и ваше отличное качество никому не будет нужно.
>А как нужно делать?
Ну, я не утверждал, что знаю как нужно. Я имел в виду, что давно есть т.н. мутационное тестирование, когда баги в код вносятся сознательно и случайно — и проверяется, что хоть какие-то тесты при этом реально падают. Если нет — то либо этот код тестами не покрыт, либо тесты не реагируют на такое изменение. По-моему, вы изобрели этот велосипед?
>А как иначе?
Ну обычно код все же проходит ревью. И его конечно смотрят — только не тестировщики, а программисты. Называть это тестированием как-то не особо принято. Ну т.е. это не то чтобы возражение по сути, а скорее по терминам.
third112 Автор
Жаль, но факт, что многие заказчики не имеют знаний по разработке, но хотят максимальное качество.
Я не изобретал, а сказал что где-то когда-то читал.
Мутационное тестирование имеет ограничения:
Ok. Терминология разная. Я только хочу сказать, что автор кода не может быть достаточным тестером.
sshikov
>Жаль, но факт, что многие заказчики не имеют знаний по разработке, но хотят максимальное качество.
Ну, они могут хотеть чего угодно, но им желательно объяснить, что максимальное качество стоит максимальных же денег. Обычно до всех сразу доходит, что всего и сразу требовать неразумно.
>Мутационное тестирование имеет ограничения:
Конечно. Тестирование вообще имеет кучу ограничений, упирающихся иногда в теоретически неразрешимые проблемы. Я просто уточняю, что само по себе такой подход — не новый.
Вообще я не вижу в этом тексте таких уж прям недостатков, которые бы оправдывали текущие -6. Сама идея, что качество тестирования нужно оценивать — она вполне здравая, хотя возможно и была слегка сумбурно сформулирована. Тестирование — это инструмент повышения качества софта. Инструмент не единственный. Выбор правильного инструмента (набора инструментов) — вопрос далеко не очевидный.
И не только код, но и документация (начиная с архитектуры), и все создаваемые артефакты должны проверяться — причем чем раньше создаются, тем тщательнее. И эта деятельность сама по себе стоит денег, поэтому ее эффективность стоит периодически оценивать, и по возможности повышать.
third112 Автор
Совершенно верно. Эти очевидные вещи многократно нужно объяснять не только заказчику, но и своему большому начальнику, который когда-то что-то на Бейсике написал.
Пожалуйста, укажите места, где сумбур — я исправлю.
sshikov
>Пожалуйста, укажите места, где сумбур — я исправлю.
Ну тут пожалуй нет такого одного места. Просто перечитайте еще раз, тут нет ни четкой постановки задачи (но зачем-то есть ссылка на другую статью по похожей теме), ни подробного описания решения. По мне — так оно просто не дописано до конца.
third112 Автор
Спасибо за ответ. Но возникли вопросы.
Как нет? Вот:
Далее:
Каких подробностей не хватает?:
--
А какого конца Вы ждали? Что я напишу:
"фирма Х уже 10 лет использует этот метод и лидирует на рынке софта"
Сожалею, но нет такой инфы. Одна идея, которую с интересом с Вами обсуждаю. Спасибо.
sshikov
Ну, на самом деле по всем пунктам (почти) можно расписать в разы подробнее, просто не экономя слова. Эта тема вообще неисчерпаемая, мне кажется. Что именно писать, я не знаю — если бы у меня были конкретные мысли, я бы наверное писал такую статью сам.
third112 Автор
краткость сестра таланта (с)