Старые книги

Автор: | 16.03.2019

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

Старые книги

Все «старые» книги про тестирование написаны программистами, которые объясняют тестирование программистам. Майерс, Бейзер, Вайнберг, Йоргенсен — не так уж много их, но что дошло до наших дней, то если не блестит, то поблёскивает.

В таких книгах подразумевается, что сперва ВСЁ надо продумать, и ВСЁ учесть, и ВСЁ заранее протестировать «карандашом на бумаге», а уже после этого натыкать дырок на перфолентах (или, чтобы посовременнее, на перфокартах) и скормить их компьютеру.

Если сможете сделать на старом компьютере всё это иначе, быстрее и безошибочнее — обязательно расскажите, бо это чудо.

Тестирование в таких условиях чуть менее, чем полностью сопровождает процесс продумывания программ, и представляет собой аналитический процесс. Всё подчинено идее «Нормально делай — нормально будет».

Пример такого подхода:

— Чтобы это сделать, надо написать вот такую команду и в ней передать такие-то параметры. Затем будет выполнен вот этот код.

— А если я после команды не буду выполнять этот код? (мечтательно) Я же пользователь, я могу ВНЕЗАПНО передумать или решить перейти к другой задаче

— Надо делать именно так, как было предусмотрено.

Незабываемый звук затвора Colt 1911.

Расширенные зрачки того, кто всё понял про реальные способы обеспечения качества.

Directed by Robert B. Weide (титры).

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

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

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

Медленно окрепло мнение о том, что можно разобраться в тестировании, не разбираясь в программировании. И таки да, можно. Можно же водить автомобиль, не умея его чинить. Можно звонить по телефону, не понимая, как работает связь.

К началу XXI-го века этот подход развит до невероятного: массив знаний, необходимых для умения программировать, оказался очень большим, местами «огромным до ненужного». Важнее уметь пользоваться средой программирования, нежели понимать, как и почему она работает. Программист уже может самостоятельно продумывать и набирать код на клавиатуре, даже ещё до продумывания архитектуры приложения — быстро написал, быстро переписал.

Умение программировать не означает «уметь педалить код». Это отдельный навык мышления, это умение рассуждать на уровне высоких абстракций, а какой конкретно язык программирования будет использован для написания кода — дело второстепенное. Это как управление войсками. Военное искусство изучают на костях Сунь Цзы — это очень древнее занятие, для которого нужны «старые книги».

Знания о программировании можно условно разделить на академические и прикладные, и таки это было сделано. Новичкам приходится [спрашивать на DOU, какой именно язык надо учить] принимать странное решение: или учить абстрактные теории о том, как работают машины, или учиться просто управлять этими машинами. Разве это не следует делать одновременно? Которые башковитые, те умудряются переключаться между этими сторонами, как в старину, а остальным и так всё норм.

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

Современным тестировщикам нет нужды учиться сперва технарному мышлению, затем программированию и потом уже тестированию — это ли не ебалайтунг? Можно не знать Computer science — это и у современных программистов бывает, и, казалось бы, чо? А ничо. Можно не понимать, что такое файл или «временная/пространственная сложность алгоритма». Тестировщику можно вообще не уметь читать/писать код. Тест-дизайн упростился до двух пунктов (разбиение на классы эквивалентности и выявление граничных значений), и это самое сложное из того, что объясняют новичкам, а всё остальное ушло в раздел «просто знайте, что оно существует». Можно просто запоминать термины, не понимая их суть. Можно писать тест-кейсы, не понимая, почему они имеют такую форму. Можно верить в то, что найти все дефекты невозможно, что всё протестировать невозможно, что абыр, извините, валг.

Все «старые» книги про тестирование в этих условиях стали непонятными, а значит, «устарели», и читать их незачем. Надо подождать, когда кто-то напишет новые книги про тестирование программного обеспечения.

Ммм…

Если ждать, то сколько и чего конкретно?

Принципы, по которым работают современные компьютеры — те же, по которым они работали в середине ХХ века. Просто сейчас они делают вычисления невероятно быстро, а нам хочется чтобы ещё быстрее. Чтобы правильно работать с вычислительными машинами (компьютерами), нужно понимать, как и почему они работают — всё то же, что и в древности. Вам точно нужны новые книги для того, чтобы узнать про базовые принципы?

Можно компилировать новые книги из старых. Так делают преподаватели (Майерс, Коупленд, Куликов). Можно наматывать поверх компиляции собственный контент (Савин, Виттакер, Блэк, Криспин). Но компиляция основывается на «старых книгах», поэтому опять ничего нового.

Можно создавать книги-учебники, которые сопровождают лекции, и которые сложно читать в отрыве от их авторов, даже если очень полезно (Бейзер, Йоргенсен). Но если начать со «старых книг», а потом дойти до Бейзера с Йоргенсеном, то всё будет понятно.

Тестирование — цельная система, в которой нет ничего лишнего, и всё со всем взаимосвязано. Тестирование полностью зависит от программирования.

Тестирование ПО следует воспринимать и объяснять слитно с программированием, а не отдельно.

Старые книги: 7 комментариев

  1. LiDea

    Полностью с вами согласна!

  2. Саша

    В точечку.

  3. Александр Александров

    Было время (многих тогда еще на свете не было), когда тестирование По не осознавалась как отдельная инженерная дисциплина, а часто интерпретировалась как синоним отладки. Поэтому тестирование и рассматривалось в контексте программирования – никого в программировании, кроме программистов, просто еще не было.
    Качественный сдвиг произошел при осознании того, что производство ПО – это вполне себе материальное производство (спасибо Ф. Бруксу!) и поэтому здесь применимы подходы в области управления качеством именно материального производства (спасибо Э. Деммингу и др.!) .
    Далее, называть Майерса преподавателем по меньшей мере странно – у него много собственные достижений, например, осознание тестирования как экономической деятельности (на эту тему см. также https://testitquickly.com/2019/02/02/testing-economy-ver-2/ ). Перечислять в одной строке Савина и Блэка то же самое, что говорить о вкладе в физику Ньютона и Перышкина (автора школьного учебника по физике в мое время).
    Фраза насчет упрощения тест-дизайна – это большая мировая боль (я говорил об этом – https://sqadays.com/ru/talk/43837). Все все знают (и не только классы эквивалентности и граничные значения), а результаты тест-дизайна, мягко говоря, ниже плинтуса. И программирование здесь не при чем – сложная это штука, тест дизайн-то, просто так с наскока не сделаешь хорошо.
    Наконец, тезис “Тестирование ПО следует воспринимать и объяснять слитно с программированием, а не отдельно.” мне кажется весьма сомнительным. Есть гениальные механики, умеющие чинить машину, и гениальные гонщики, умеющие ее водить. А много ли вы знаете гениальных механиков-гонщиков?
    На эту тему можно дискутировать долго, но жизнь – она всех рассудит.
    Но в целом мысли симпатичные:)
    Спасибо!

  4. Алексей Лупан

    Спасибо вам!
    Майерс, безусловно, голова. Но у него в активе “a lecturer in computer science at the Polytechnic Institute of New York University, where he taught graduate-level courses in computer science”, и поэтому он попадает в фильтр “преподаватели”.
    Гениальных механиков-гонщиков по-отдельности не знаю, но в прошлом году я познал нечто, чему сам себе стану примером.
    Итак, в прошлом году я наматывал круги по тренировочному треку в Феофании — одно из мест, где украинские спортсмены-автогонщики (заодно там новичков раскатывают) тренируются грамотно проходить повороты на большой скорости. Мне это было нужно потому, что я всё думал о том, как сделать безопасной езду на моей Волге 1965-го года рождения. Там нет ремней безопасности, она неповоротливая, она не умеет “прыгать с места”, динамика никакая, торможение долгое и неоднозначное, там задний привод, там леший бродит. Я хотел понять, как происходит спортивное руление (обычно это преподносят как контраварийное вождение) потому, что это знание может помочь вырулить из сложной ситуации, всё такое.
    На современной быстрой и резвой переднеприводной машине я научился проходить повороты на высокой скорости, заходить в занос и выбираться из него, а после всего этого понял, как думать об управлении автомобилем. Машина в движении — как тарелка с водой на вытянутых руках, надо не только учитывать инерцию, но и прогнозировать её, инициировать её и управлять ею.
    Но я еще не мог состыковать новое знание с управлением моей старой машиной, ведь у неё отсутствует целая группа технических возможностей, которые для этого дела нужны. Нет возможности ручным тормозом блокировать задние колеса, нет возможности ускоряться передними колёсами (бо задний привод в гонках имеет одно преимущество и сотню недостатков), переключение скоростей физиологически неподходящее… Вообще, на 21-х Волгах неоднократно гоняли на международных соревнованиях, но чем дальше, тем хуже, ибо заднеприводная тяжелая машина с низкооборотистым мотором для прохождения поворотов неподходящая.
    После этого я приехал в Феофанию на Волге. Тренер взял её за руль, разогнал до 80-ти км/ч и показал мне, что на ней можно войти в поворот на невероятной для поворотов скорости 60 км/ч, успешно его пройти и безошибочно из него выйти с ускорением. Я ещё никогда так сильно не наклонял кузов в поворотах, когда до опрокидывания, как в кино, остаётся буквально чуть-чуть, а он её и наклонил, и направил куда надо, и управлял в повороте не рулём, а педалью газа.
    После этого я врубился. Всё то, что раньше мне мешало или казалось невозможным, стало иным. Мой сегодняшний стиль езды полностью поменялся, я уже не рыскаю “мордой” в поворотах, мои проезды поворотов стабильны и точны, как в старых рекламах для Внешторга, и недостатки автомобиля используются как возможности и стали достоинствами. Я понял, что вырулить из сложной ситуации можно только в том случае, когда ты к ней готов, когда есть рефлексы, когда водитель может её предусмотреть и сможет в неё не попадать. А в этом плане разница между передним и задним приводом исчезает.
    Кроме этого, я как следует залез в механизмы моей машины, и уже иначе понимаю, как работают практически все узлы по-отдельности. Машина — не цельный агрегат, под капотом которого происходит какая-то магия — это собрание отдельных механизмов, которые я могу задействовать в разных ситуациях с разными последствиями, и…
    …и тут мне стало понятным то, что раньше было смутно. Мне всегда было намного проще и интереснее объяснять тест-дизайн программистам, чем тестировщикам, но я не понимал, почему так. А это потому, что даже те программисты, которые работают «по-современному» и не заглядывали в Computer science, всё равно знают много концепций, до которых наши тестировщики [сознательно] не доходят.
    Типы данных, циклы, условия, аргументы командной строки, фильтрация и сортировка данных, рекурсия, сложность вычисления алгоритмов, и алгоритмы вообще — всё это абстрактные концепции, которые в нашем быту не встречаются и в школе тестировщиков с ними никто никого насильно не знакомит. Термины запоминать заставляют, а вот вся эта база понимания того, как компьютеры работают — этого нет. А оно должно быть.
    Я произвел тридцать наблюдений у себя в клинике. И что же вы думаете? Пациенты, не знающие Computer science, и занимающиеся тест-дизайном на привычном примитивном уровне, чувствовали себя превосходно. Те же, которых я специально заставлял смотреть https://habr.com/ru/company/vertdider/blog/403823/ — теряли в весе. Мало этого. Пониженные коленные рефлексы, скверный аппетит, угнетенное состояние духа. Оказывается, не всё так просто, аналитическое мышление нам недоступно, профессор, нам лучше просто заниматься тестированием и не заморачиваться о том, что там происходит под капотом. Им кажется, что они всё интуитивно поймут.
    А те, кто начали заморачиваться и не только посмотрели хотя бы несколько видео из CS50, но заинтересовались и начали их обсуждать, снова чувствуют себя превосходно и даже сметают всё из тарелок тех, которые угнетённые. Они совсем по-другому смотрят на происходящее, они начинают грамотно заходить в повороты и успешно из них выходить, они не гоняют почём зря на галерах Киева, они понимают, как работают программисты и почему регрессионное тестирование называется регрессионным.
    То есть, мой вывод о том, что тестирование ПО следует воспринимать слитно с программированием, и что тест-дизайн — не магия, а технология, понимать которую могут все те, кто могут думать в определённом контексте — прямой результат вождения ГАЗ-21.
    И в этом моменте разница между механиками и гонщиками по-отдельности стирается, ведь есть общий контекст. Водитель есть водитель, ему надо понимать про «тарелку с водой» и действовать осознанно, а не реактивно.

  5. Александр Александров

    Леша, и Вам спасибо! Личный опыт у каждого свой, и поэтому мнения у нас с Вами разнятся, что хорошо. Готов обсудить при личной встрече:)!

  6. Уведомление: Про спички, удовлетворение и переосмысление | Normal testing

  7. Akkybelek

    Спасибо

Добавить комментарий для Про спички, удовлетворение и переосмысление | Normal testingОтменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.