Comments 34
Люди - разные. И технические специалисты - тоже. Есть те, кому по нраву чистые комиксы, есть те, кому лучше чистый текст. Есть те, кому нужны лирические отступления, есть те, кто их ненавидит. Аналогично, есть те, кому лучше разжёвывать детали, а есть те, кому нужна только сухая общая схема.
Распредение предпочтение, скорее всего, примерно подчиняется нормальному закону. И самое большое количество - условно по середине. Т.е. людям для лучшего восприятия лучше, чтобы было некоторое количество иллюстраций, лирических отступлений и умеренное разжёвывание деталей. Это важно и с точки зрения концентрации внимания, и с точки зрения работы ассоциативной памяти.
Лектор, который не соблюдает баланса, обречён на то, что его слушатели будут спать. Если вы читали лекции студентам, то наверняка корректировали этот баланс в своих лекциях в результате наблюдений. Автор книги, не соблюдающий баланс, обречён на то, что его книгу не дочитают до конца.
В обсуждаемой книге, на первый взгляд, балан соблюдён. С учётом того, что она написана по мотивам курса и тренингов, у автора было достаточно обратной связи, чтобы не накосячить с этим балансом уж слишком сильно.
Зачем ОБУЧАЮЩАЯ книга начального уровня в виде сухаря... ИМХО очень даже зайдет детям.
Вам не по нраву серия Head First? Тоже своего рода комиксы. И явно не тянет на серию для Dummies.
Предпочитаю видеогайды
Книга классная. Не просто классная. А я готов купить её за ДЕНЬГИ. А это для старого пирата лучшее выражение качества продукта. Она просто идеально подходит для обучения и хорошо ложится в систему Кванториумов с его продуктовым программированием и всем таким разным. Просто я не знаю что сказать еще... Круто!Класно! и Прекрасно!
По прошествии времении (которое ушло на ознокомление с фрагментами и все такое прочее) решил разбавить свой эмоциональный позитивный спам более оформленными мыслями по поводу:
Подобной книги я буквально"джва года ждал" и как бы еще не дольше. Просмотренный материал дает возможность надеяться что возраст 12+ вполне подходит для освоения этой книги. Конечно у большинства 8 классников нет задач требующих освоения тестирования, НО вот в кружке программирования книга должна быть. Особенно если акцент сделан на итеративную разработку и прочий скрам, аджайл и израИль, как в Кванториумах.
Для меня книга прикрывает еще один слабый фланг - что делать творческого с учащимися, которые еще не умеют программировать. Писать ТЗ и иследовать программы могут люди и не владеющие программированием.
Иллюстрации великолепны. Так же как и великолепны и аватарки художниц-оформительниц! Это тоже будет мотивирующей частью. Многие девочки ходящие на кружок имеют свои скетч-буки и увлекаются рисованием.
Как мне кажется, умение тестировать и документировать в разработке ПО это более важный, но более недооцененный навык, чем собственно программирование. Я надеюсь подобные книги восполнят этот пробел.
В общем, на первый взгляд книга легко станет моим рабочим инструментом и поэтому я готовлюсь её купить, сразу как выйдет электронная версия. Вопрос о том, стоит ли изучать эту книгу, чтобы стать "вайтишником через тестирование" я оставил за кадром.
Дети 90-х выросли и стали тестировщиками...
В электронной версии книга будет?
Там написано что
Электронная цветная: появится в продаже на сайте издательства в 3-4 квартале 2022 года
Ага, увидел. Спасибо! Буду ждать все же электронки.
Мне тоже электронка удобнее. НО если автору в качестве гонорара надо распродать цветные, то я куплю. Реально мне очень понравился и стиль и дух книги. И в тему она на моих курсах.
Автор себе хотел цветную в коллекцию, но внезапно первый тираж в 100 экземпляров раскупили и даже не хватило на всякие "подарить школьным учителям", поэтому будет ещё )))
А так любая книга, которую печатает издательство, выходит сначала в бумаге, и через 9-10 месяцев в электронном виде. Но про путь "от идеи до реализации" я попозже напишу ))
у автора поста есть канал на ютьюбе - "okiseleva"
Другими словами, текстирование обязательно для коммерческих продуктов. В опенсорсе никто ничего гарантировать не собирается, всегда пишут, берите «as is».
А так, теме: «Один участник: автор = разработчик» посвящен один абзац и то примеры из веба: сайт – одностраничник и интернет-магазин по шаблону…, т.е., чисто формально.
Если принять, что тестирование – это сертификация качества продукта, тогда, естественно, привлекать тестировщика к этапу проектирования. Иначе, «поздно пить боржоми…». Продукт сдавать надо, поэтому убираем только самые очевидные и бросающиеся в глаза ляпы, а все остальное вполне можно «подремонтировать» в следующих версиях. Разве не так?
Куда интересней было бы акцентировать внимание на оптимальное проектирование ПО. Скажем, в рамках теории моделей. Например, для десктопных программ моделью можно считать:
1. Список взаимодействующих объектов.
2. Список свойств, для каждого объекта.
3. Список управляющих команд и их обработчиков.
4. Аксиомы поведения для каждого объекта.
И т.п.
Т.е., даже на этом уровне видно, что программная модель имеет комбинаторную сложность. Тестировщик мог бы отслеживать все комбинации и их корректную обработку (принцип полноты).
Но этого мало, в модели нужно выявить минимальное, независимое множество элементов, чтобы не было их дублирования в реализации, а было наследование и полиморфизм для зависимых объектов.
Но это, как бы, внешняя модель. А есть еще внутренняя. Это модель компьютерной реализации на уровне операционной системы либо платформы разработки. Скажем, для WinAPI, подобной моделью является оконо-событийная система.
В итоге, мы должны оптимально спроецировать внешнюю модель на внутреннюю. Вот примерно на таком уровне я хотел бы видеть разработку ПО и его глубокое тестирование…
Не совсем поняла, сколько места нужно рассказывать про "сколько человек должно быть в команде".
А про модели — интересно, конечно, но не понимаю, что из этого новичок поймет и сможет применить
Тестирование - понятие растяжимое. Оно бывает разных уровней и видов. Тема очень обширна, чтобы ответить вам на все вопросы в рамках поста. Тут книги одной не хватит.
Тестирование на основе модели, и разработка управляемая моделями - весьма трудозатратны, чтобы применять их в средне- и малобюджетных проектах. Риски соответственно тоже не достаточно велики, чтобы оправдывать вложения в такой уровень качества. Ну и кроме этого, наверняка нет достаточного количества квалифицированых кадров. Одно дело шаблонное приложение на фреймворке состряпать по подсказкам из Stackoverflow, а другое спроектровать архитектуру для разработки и тестирования на основе модели. Скорее всего придется решать всю задачу самому, потому что типовых решений там уже не будет, в лучшем случае общие советы.
Поэтому, в основном, вместо систематического подхода, обходятся тестированием "методом картечи" - потестируем в разных местах понемногу и будет нормально. Мы точно пропустим какие-то ошибки, но какие-то найдем, зато это будет сравнительно быстро.
А теперь представим себе, что вот у нас есть ограничение по времени тестирования, мы можем проложить линии любым путем, но только 5. Есть способ проложить линии так, чтобы при любом расположении красных квадратов линии касались максимально возможного их количества? Нет. "Методом картечи" мы с большой вероятностью будем находить ошибки, но никогда не найдем их все.
Что еще можно увидеть на этой упрощенной модели? Что 3 из 5 линий не нашли ничего. Т.е 60% времени тестирования было потрачено "зря". Но мы никогда не знаем какие 60% это будут. Поэтому избавиться от этого при таком подходе невозможно.
Предположим мы бы запускали линии систематично. Чтобы покрыть все поле нужно 30 линий. Это как минимум шестикратное увеличение бюджета на тестирование. Это не целесообразно для среднестатистического заказчика. Также при полном покрытии, не все поле содержит ошибки, а только 7% его площади значит 93% тестирования не найдет ничего. При шестикратном увеличении бюджета 93% времени тестирования уходит впустую (да, к сожалению, у заказчиков часто именно такая математика) - нецелесообразно.
Вот и получается, что систематический подход нужен только там где жизненно важно найти именно 100% ошибок.
Мне вот интересно другое. Если есть «средне- и малобюджетные проекты», то должен быть клиент, который за все это платит, пусть даже мало. А, какие это задачи, вообще? Т.е., это фриланс или небольшая программистская фирма, которые получают конкретные заказы? За какие разработки с нуля, платят деньги? Не обязательно отвечать конкретно, достаточно в принципе.
Я вот специализируюсь на учетных задачах для своего предприятия. Фирме главное – результат. Все остальное руководство волнует мало.
Удивляет одно. Крутых программистов много, навороченных программ – тоже, однако, хороших учетных систем нет. Все, что есть это как бы полусъедобное, к тому же дорогое. Вот и приходится ваять собственные велосипеды, чтобы просто решить поставленную задачу. Тестирование? Какое тестирование? Сами пользователи в реальной работе и тестируют. Если находят глюк, орут благим матом. Исправил – можно спать спокойно. За годы работы, все более-менее устаканилось, и юзеры довольны и мне хорошо.
Когда все работает хорошо, хочется, чтобы работало еще лучше. Думаю, что повысить качество можно за счет радикальных идей, а не тестирования. Например, за счет модульного программирования и, как следствие, модульного учета. Однако простых и понятных реализаций и примеров, естественно, нет. Те же плагины, как в моей последней статье здесь, приходится переизобретать, поскольку доступны только консольные решения.
Я посмотрел ваши ссылки, как и ожидал, они оказались слишком абстрактными, чтобы извлечь из них реальную пользу.
Те модели, о которых я говорил, означают два уровня: концептуальное и уровень реализации. Главное, рассмотреть все комбинаторные связи между взаимодействующими объектами и привести их к каноническому виду. Например, редактирование символа в собственном однострочном редакторе ячеек, можно свести к более простому событию перемещения текстовой каретки вправо / влево (или даже без оного, для клавиши «Delete») и стандартной перерисовке ячейки. Другими словами, вставку, удаление (справа / слева от каретки), замену, добавление и т.п., можно свести к обычной навигации каретки по тексту. Иначе говоря, все сводится к сдвигам каретки и / или текста.
Упрощать можно и стандартные решения. Возьмем, скажем, диалоговые формы. Работать с ними тяжело, особенно если хочется нестандартного поведения. Но, если использовать упомянутый выше редактор ячеек, то все упрощается. Просто мы отказываемся от концепции контролов, как дочерних окон, и воспринимаем их как редактируемые ячейки или классы, с функцией рисования для заданной структуры данных.
Тут нет возможности описывать все подробно. Однако эксперименты показывают, что направление перспективное, так как на базе одного редактора ячеек можно реализовывать как динамические формы, так и табличные редакторы и даже макеты отчетов. Причем разные ячейки могут иметь разные шрифты, цвет, полупрозрачный фон, «правильное» изменение размеров, быть редактируемыми либо закрытыми для редактирования и много чего еще. Именно как раз то, чего не хватает в обычных учетных системах (там это есть, но не слишком удобно для использования).
Но это тема отдельного разговора.
Мне вот интересно другое. Если есть «средне- и малобюджетные проекты», то должен быть клиент, который за все это платит, пусть даже мало. А, какие это задачи, вообще? Т.е., это фриланс или небольшая программистская фирма, которые получают конкретные заказы? За какие разработки с нуля, платят деньги? Не обязательно отвечать конкретно, достаточно в принципе.
Веб-приложения, мобильные приложения, одностраничники, какие-то интерфейсы между двумя разрозненными системами, всякие бывают профили. SAP-пользуется стабильным спросом, продукты Майрософт. Все это надо интегрировать в инфраструктуру, написать какие-то сервисы для привязки к остальным системам. Или фирма обслуживает заказы крупного концерна, у которого сотни отделов и каждому нужна своя аппликуха для учета и контроля. И еще сервис для обмена данными между отделами. Казалось бы че их одна большая система не устраивает? Но с другой стороны если ляжет одно большое приложение то в трубу полетят сотни тысяч евро в день. Короче в корпоративной среде там все сурово. Например, остановка конвейера на заводе Фольксваген лишает его около ста миллионов евро прибыли в неделю, ведь ежедневно около 3,5 тысяч автомобилей покидают сборчные цеха концерна.
Что касается 1С, я о нем имею весьма отдаленное представление, но по сути это конструктор для бизнес приложений. Конечно мелкодисперсная модуляризация как вы предлагаете поможет проводить юнит-тестирование. Как мне удалось выяснить 1С обладает инструментами как для автоматизированного юнит-тестирования так и для сценарного тестирования.
К сожалению, ошибки как правило случаются на стыке компонентов, т.е. грубо говоря контролы будут работать каждый как надо, но предположим, может вылезти ошибка что при закрытии и переоткрытии диалога введенные до этого данные не сбрасываются. Тут нужно сценарное интеграционное тестирование.
Можно на уровне архитектуры компонентов, зашить каждому контролу, который может сбрасывать свое состояние, обязательное для реализации действие, и при закрытии диалога, вызывался бы сброс всех его полей и контролов. Но тут опять же либо разработчик должен помнить об этом добавлять обработчик каждый раз для нового контрола в диалоге в список, либо, писать какой-то программный механизм который будет это делать автоматически, с помощью например рефлексии (не знаю есть ли такое в 1С вообще)
По «1С» это отдельная большая песня. «Семерка» (1С77) была (и остается!) рабочей лошадкой, а «восьмерку» (1С8х) могут освоить «не только лишь все». В последней, много чего есть. Как говорится: «В этом мире есть много вещей, которые… мне не нужны!». Но и много чего нет. В общем, «кактус», который «ежики, плакали, кололись, но еле», еще тот.
Наглядно, картинки красивые. А в fb2 книжки нет?
http://testbase.ru/book-beginner тут вся инфа по тому, что есть
Ольга, добрый день!
Не муго оставить комментарий к старой публикации, поэтому попробую здесь спросить. Читаю сейчас вот эту статью (Тестируем поля логин/пароль) https://testitquickly.com/2009/09/09/vvodeste-loginu-la-adnaklassni6i/, на которую вы ссылались в своей статье "Где брать идеи для тестов (подборка полезных ссылок)".
В тексте написано: "использование только ASCII символов в логине – Expected: alert ". Почему в этом случае должна выскакивать ошибка? Ведь если я введу любые печатные символы - это же тоже будет "использование только ASCII символов".
Что такое тестирование. Курс молодого бойца. Книга для новичков