Привет!
Меня зовут Ольга Назина. Я в тестировании с 2006 года. Тестировщик, тренер, практик, энтузиаст — вот тут можно почитать обо мне подробнее.
Я очень люблю серию книг по разработке ПО от Head First O`Reilly:
Изучаем Java. Кэти Сьерра и Берт Бейтс
Изучаем SQL. Линн Бейли
Изучаем HTML, XHTML и CSS. Эрик и Элизабет Фримен
и другие
И вот я решила написать книгу для начинающих тестировщиков. В таком же стиле. С картиночками, примерами, домашними заданиями и все такое. Вот пример картинки из книги:
За основу книги взяла программу своего курса «Школа для начинающих тестировщиков». Она уже обкатана на 100+ проведенных тренингов. Это больше тысячи выпускников (и ещё больше просто студентов) и десятки историй их успеха.
Я решила так: даже если просто переложить свои лекции на бумагу, уже будет полезно. А там затянуло, в итоге переписала чуть ли не с нуля по принципу:
Беру за основу слайды презентации с курса
Вспоминаю, где студенты чаще всего косячат в ДЗ
Просматриваю тренерскую гуглодоку типичных ошибок студентов, чтобы посмотреть, что упустила в пункте 2
Смотрю, какие вопросы студенты задают после лекции / после того, как начали делать ДЗ
Расписываю тему подробно
Получилась книга-тренинг. По каждой главе:
подробный конспект лекции
вопросы для самопроверки
задание по составлению портфолио.
Если вы читали Романа Савина, то у вас есть представление о том, «что вообще такое тестирование». А я в книге рассказала подробнее о каждой нужной новичку теме. Но осталась в том же легком для чтения стиле.
Часть материала не вошла в книгу и я вынесла её отдельно — «Сложные ИТ-термины на простом языке».
Фрагменты книги
Фрагменты из книги можно почитать в её онлайн-варианте — http://testbase.ru/book-beginner
А сюда я дам несколько ссылок для понимая «как книга вообще выглядит»
Что такое ПО (программное обеспечение)
Почему тестирование так важно?
Где граница «позитив-негатив»?
Тест-кейс проверяет, а не доверяет!
Метод бисекционного деления в тестировании
Как она выглядит
Можно полистать ч/б вариант вот тут — http://online.anyflip.com/ulhe/recv/mobile/index.html
В цвете:
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
Комментарии (32)
MAXH0
25.12.2021 16:01+1Книга классная. Не просто классная. А я готов купить её за ДЕНЬГИ. А это для старого пирата лучшее выражение качества продукта. Она просто идеально подходит для обучения и хорошо ложится в систему Кванториумов с его продуктовым программированием и всем таким разным. Просто я не знаю что сказать еще... Круто!Класно! и Прекрасно!
MAXH0
25.12.2021 19:45+2По прошествии времении (которое ушло на ознокомление с фрагментами и все такое прочее) решил разбавить свой эмоциональный позитивный спам более оформленными мыслями по поводу:
Подобной книги я буквально"джва года ждал" и как бы еще не дольше. Просмотренный материал дает возможность надеяться что возраст 12+ вполне подходит для освоения этой книги. Конечно у большинства 8 классников нет задач требующих освоения тестирования, НО вот в кружке программирования книга должна быть. Особенно если акцент сделан на итеративную разработку и прочий скрам, аджайл и израИль, как в Кванториумах.
Для меня книга прикрывает еще один слабый фланг - что делать творческого с учащимися, которые еще не умеют программировать. Писать ТЗ и иследовать программы могут люди и не владеющие программированием.
Иллюстрации великолепны. Так же как и великолепны и аватарки художниц-оформительниц! Это тоже будет мотивирующей частью. Многие девочки ходящие на кружок имеют свои скетч-буки и увлекаются рисованием.
Как мне кажется, умение тестировать и документировать в разработке ПО это более важный, но более недооцененный навык, чем собственно программирование. Я надеюсь подобные книги восполнят этот пробел.
В общем, на первый взгляд книга легко станет моим рабочим инструментом и поэтому я готовлюсь её купить, сразу как выйдет электронная версия. Вопрос о том, стоит ли изучать эту книгу, чтобы стать "вайтишником через тестирование" я оставил за кадром.
Iscander_Che
25.12.2021 20:08В электронной версии книга будет?
MAXH0
25.12.2021 20:14Там написано что
Электронная цветная: появится в продаже на сайте издательства в 3-4 квартале 2022 года
Iscander_Che
25.12.2021 20:21Ага, увидел. Спасибо! Буду ждать все же электронки.
MAXH0
25.12.2021 20:25Мне тоже электронка удобнее. НО если автору в качестве гонорара надо распродать цветные, то я куплю. Реально мне очень понравился и стиль и дух книги. И в тему она на моих курсах.
Molechka Автор
25.12.2021 21:58Автор себе хотел цветную в коллекцию, но внезапно первый тираж в 100 экземпляров раскупили и даже не хватило на всякие "подарить школьным учителям", поэтому будет ещё )))
А так любая книга, которую печатает издательство, выходит сначала в бумаге, и через 9-10 месяцев в электронном виде. Но про путь "от идеи до реализации" я попозже напишу ))
Emelian
25.12.2021 22:07Прямого определения, что такое тестирование, я не увидел, только косвенное: «Чем занимается тестировщик?», «Почему тестирование это важно?» и т.п. По логике вещей, следовало бы сказать, что тестирование – это аналог нормоконтроля / ОТК / госприемки и т.п., на производстве, в промышленности, оборонке… Или, допустим, тестирование это сертификация программы (ПО) на соответствие заявленному качеству. Или, еще проще, тестирование это обеспечение минимально приемлемого работоспособного функционала для пользователя.
Другими словами, текстирование обязательно для коммерческих продуктов. В опенсорсе никто ничего гарантировать не собирается, всегда пишут, берите «as is».
А так, теме: «Один участник: автор = разработчик» посвящен один абзац и то примеры из веба: сайт – одностраничник и интернет-магазин по шаблону…, т.е., чисто формально.
Если принять, что тестирование – это сертификация качества продукта, тогда, естественно, привлекать тестировщика к этапу проектирования. Иначе, «поздно пить боржоми…». Продукт сдавать надо, поэтому убираем только самые очевидные и бросающиеся в глаза ляпы, а все остальное вполне можно «подремонтировать» в следующих версиях. Разве не так?
Куда интересней было бы акцентировать внимание на оптимальное проектирование ПО. Скажем, в рамках теории моделей. Например, для десктопных программ моделью можно считать:
1. Список взаимодействующих объектов.
2. Список свойств, для каждого объекта.
3. Список управляющих команд и их обработчиков.
4. Аксиомы поведения для каждого объекта.
И т.п.
Т.е., даже на этом уровне видно, что программная модель имеет комбинаторную сложность. Тестировщик мог бы отслеживать все комбинации и их корректную обработку (принцип полноты).
Но этого мало, в модели нужно выявить минимальное, независимое множество элементов, чтобы не было их дублирования в реализации, а было наследование и полиморфизм для зависимых объектов.
Но это, как бы, внешняя модель. А есть еще внутренняя. Это модель компьютерной реализации на уровне операционной системы либо платформы разработки. Скажем, для WinAPI, подобной моделью является оконо-событийная система.
В итоге, мы должны оптимально спроецировать внешнюю модель на внутреннюю. Вот примерно на таком уровне я хотел бы видеть разработку ПО и его глубокое тестирование…Molechka Автор
25.12.2021 22:11Не совсем поняла, сколько места нужно рассказывать про "сколько человек должно быть в команде".
А про модели — интересно, конечно, но не понимаю, что из этого новичок поймет и сможет применить
souls_arch
26.12.2021 09:49Тестирование - понятие растяжимое. Оно бывает разных уровней и видов. Тема очень обширна, чтобы ответить вам на все вопросы в рамках поста. Тут книги одной не хватит.
lxsmkv
26.12.2021 13:12+2Тестирование на основе модели, и разработка управляемая моделями - весьма трудозатратны, чтобы применять их в средне- и малобюджетных проектах. Риски соответственно тоже не достаточно велики, чтобы оправдывать вложения в такой уровень качества. Ну и кроме этого, наверняка нет достаточного количества квалифицированых кадров. Одно дело шаблонное приложение на фреймворке состряпать по подсказкам из Stackoverflow, а другое спроектровать архитектуру для разработки и тестирования на основе модели. Скорее всего придется решать всю задачу самому, потому что типовых решений там уже не будет, в лучшем случае общие советы.
Поэтому, в основном, вместо систематического подхода, обходятся тестированием "методом картечи" - потестируем в разных местах понемногу и будет нормально. Мы точно пропустим какие-то ошибки, но какие-то найдем, зато это будет сравнительно быстро.
Из 12 ошибок мы найдем только 5, но зато быстрее чем если бы мы проверяли построчно. А теперь представим себе, что вот у нас есть ограничение по времени тестирования, мы можем проложить линии любым путем, но только 5. Есть способ проложить линии так, чтобы при любом расположении красных квадратов линии касались максимально возможного их количества? Нет. "Методом картечи" мы с большой вероятностью будем находить ошибки, но никогда не найдем их все.
Что еще можно увидеть на этой упрощенной модели? Что 3 из 5 линий не нашли ничего. Т.е 60% времени тестирования было потрачено "зря". Но мы никогда не знаем какие 60% это будут. Поэтому избавиться от этого при таком подходе невозможно.
Предположим мы бы запускали линии систематично. Чтобы покрыть все поле нужно 30 линий. Это как минимум шестикратное увеличение бюджета на тестирование. Это не целесообразно для среднестатистического заказчика. Также при полном покрытии, не все поле содержит ошибки, а только 7% его площади значит 93% тестирования не найдет ничего. При шестикратном увеличении бюджета 93% времени тестирования уходит впустую (да, к сожалению, у заказчиков часто именно такая математика) - нецелесообразно.
Вот и получается, что систематический подход нужен только там где жизненно важно найти именно 100% ошибок.
Emelian
26.12.2021 22:09С вами трудно не согласится. Все так и есть. Я бы даже сказал так, программирование ведется на основе здравого смысла и тестирование ведется на основе здравого смысла. Иногда, целесообразно игнорировать стандарты, паттерны, шаблоны и фреймворки. А здравый смысл это производная опыта и знаний, больше практических, чем теоретических.
Мне вот интересно другое. Если есть «средне- и малобюджетные проекты», то должен быть клиент, который за все это платит, пусть даже мало. А, какие это задачи, вообще? Т.е., это фриланс или небольшая программистская фирма, которые получают конкретные заказы? За какие разработки с нуля, платят деньги? Не обязательно отвечать конкретно, достаточно в принципе.
Я вот специализируюсь на учетных задачах для своего предприятия. Фирме главное – результат. Все остальное руководство волнует мало.
Удивляет одно. Крутых программистов много, навороченных программ – тоже, однако, хороших учетных систем нет. Все, что есть это как бы полусъедобное, к тому же дорогое. Вот и приходится ваять собственные велосипеды, чтобы просто решить поставленную задачу. Тестирование? Какое тестирование? Сами пользователи в реальной работе и тестируют. Если находят глюк, орут благим матом. Исправил – можно спать спокойно. За годы работы, все более-менее устаканилось, и юзеры довольны и мне хорошо.
Когда все работает хорошо, хочется, чтобы работало еще лучше. Думаю, что повысить качество можно за счет радикальных идей, а не тестирования. Например, за счет модульного программирования и, как следствие, модульного учета. Однако простых и понятных реализаций и примеров, естественно, нет. Те же плагины, как в моей последней статье здесь, приходится переизобретать, поскольку доступны только консольные решения.
Я посмотрел ваши ссылки, как и ожидал, они оказались слишком абстрактными, чтобы извлечь из них реальную пользу.
Те модели, о которых я говорил, означают два уровня: концептуальное и уровень реализации. Главное, рассмотреть все комбинаторные связи между взаимодействующими объектами и привести их к каноническому виду. Например, редактирование символа в собственном однострочном редакторе ячеек, можно свести к более простому событию перемещения текстовой каретки вправо / влево (или даже без оного, для клавиши «Delete») и стандартной перерисовке ячейки. Другими словами, вставку, удаление (справа / слева от каретки), замену, добавление и т.п., можно свести к обычной навигации каретки по тексту. Иначе говоря, все сводится к сдвигам каретки и / или текста.
Упрощать можно и стандартные решения. Возьмем, скажем, диалоговые формы. Работать с ними тяжело, особенно если хочется нестандартного поведения. Но, если использовать упомянутый выше редактор ячеек, то все упрощается. Просто мы отказываемся от концепции контролов, как дочерних окон, и воспринимаем их как редактируемые ячейки или классы, с функцией рисования для заданной структуры данных.
Тут нет возможности описывать все подробно. Однако эксперименты показывают, что направление перспективное, так как на базе одного редактора ячеек можно реализовывать как динамические формы, так и табличные редакторы и даже макеты отчетов. Причем разные ячейки могут иметь разные шрифты, цвет, полупрозрачный фон, «правильное» изменение размеров, быть редактируемыми либо закрытыми для редактирования и много чего еще. Именно как раз то, чего не хватает в обычных учетных системах (там это есть, но не слишком удобно для использования).
Но это тема отдельного разговора.lxsmkv
27.12.2021 00:39Мне вот интересно другое. Если есть «средне- и малобюджетные проекты», то должен быть клиент, который за все это платит, пусть даже мало. А, какие это задачи, вообще? Т.е., это фриланс или небольшая программистская фирма, которые получают конкретные заказы? За какие разработки с нуля, платят деньги? Не обязательно отвечать конкретно, достаточно в принципе.
Веб-приложения, мобильные приложения, одностраничники, какие-то интерфейсы между двумя разрозненными системами, всякие бывают профили. SAP-пользуется стабильным спросом, продукты Майрософт. Все это надо интегрировать в инфраструктуру, написать какие-то сервисы для привязки к остальным системам. Или фирма обслуживает заказы крупного концерна, у которого сотни отделов и каждому нужна своя аппликуха для учета и контроля. И еще сервис для обмена данными между отделами. Казалось бы че их одна большая система не устраивает? Но с другой стороны если ляжет одно большое приложение то в трубу полетят сотни тысяч евро в день. Короче в корпоративной среде там все сурово. Например, остановка конвейера на заводе Фольксваген лишает его около ста миллионов евро прибыли в неделю, ведь ежедневно около 3,5 тысяч автомобилей покидают сборчные цеха концерна.
Что касается 1С, я о нем имею весьма отдаленное представление, но по сути это конструктор для бизнес приложений. Конечно мелкодисперсная модуляризация как вы предлагаете поможет проводить юнит-тестирование. Как мне удалось выяснить 1С обладает инструментами как для автоматизированного юнит-тестирования так и для сценарного тестирования.
К сожалению, ошибки как правило случаются на стыке компонентов, т.е. грубо говоря контролы будут работать каждый как надо, но предположим, может вылезти ошибка что при закрытии и переоткрытии диалога введенные до этого данные не сбрасываются. Тут нужно сценарное интеграционное тестирование.Можно на уровне архитектуры компонентов, зашить каждому контролу, который может сбрасывать свое состояние, обязательное для реализации действие, и при закрытии диалога, вызывался бы сброс всех его полей и контролов. Но тут опять же либо разработчик должен помнить об этом добавлять обработчик каждый раз для нового контрола в диалоге в список, либо, писать какой-то программный механизм который будет это делать автоматически, с помощью например рефлексии (не знаю есть ли такое в 1С вообще)
Emelian
28.12.2021 06:52Более-менее понятно. Если есть спрос, то будет и предложение. Просто я думал, что это самостоятельные продукты, с которыми фирмы выходят на рынок. Ранее известные, как shareware. А так это, по сути, обслуживающие отделы, только на хозрасчете.
По «1С» это отдельная большая песня. «Семерка» (1С77) была (и остается!) рабочей лошадкой, а «восьмерку» (1С8х) могут освоить «не только лишь все». В последней, много чего есть. Как говорится: «В этом мире есть много вещей, которые… мне не нужны!». Но и много чего нет. В общем, «кактус», который «ежики, плакали, кололись, но еле», еще тот.
isicju
вопрос техническим специалистам - а вам по нраву книга в виде комиксов или вы предпочтете скорее сухой сжатый материал но "по делу"?
Medeyko
Люди - разные. И технические специалисты - тоже. Есть те, кому по нраву чистые комиксы, есть те, кому лучше чистый текст. Есть те, кому нужны лирические отступления, есть те, кто их ненавидит. Аналогично, есть те, кому лучше разжёвывать детали, а есть те, кому нужна только сухая общая схема.
Распредение предпочтение, скорее всего, примерно подчиняется нормальному закону. И самое большое количество - условно по середине. Т.е. людям для лучшего восприятия лучше, чтобы было некоторое количество иллюстраций, лирических отступлений и умеренное разжёвывание деталей. Это важно и с точки зрения концентрации внимания, и с точки зрения работы ассоциативной памяти.
Лектор, который не соблюдает баланса, обречён на то, что его слушатели будут спать. Если вы читали лекции студентам, то наверняка корректировали этот баланс в своих лекциях в результате наблюдений. Автор книги, не соблюдающий баланс, обречён на то, что его книгу не дочитают до конца.
В обсуждаемой книге, на первый взгляд, балан соблюдён. С учётом того, что она написана по мотивам курса и тренингов, у автора было достаточно обратной связи, чтобы не накосячить с этим балансом уж слишком сильно.
MAXH0
Зачем ОБУЧАЮЩАЯ книга начального уровня в виде сухаря... ИМХО очень даже зайдет детям.
rat1
Вам не по нраву серия Head First? Тоже своего рода комиксы. И явно не тянет на серию для Dummies.
isicju
Это дело вкуса. Ну и вообще для мозга тяжеловато читать сухой текст. Мне книга в общем не нравится (как и большинство по джаве) тк почти все они - неполные но для новичков (а они основная аудитория) создается впечатление что они теперь знают джаву.
rat1
Мне тоже по C# не понравилась) Но паттерны зашли и по архитектуре достаточно интересная книга. Видимо от автора зависит. Но я тут про сам концепт писал. Картинки в тексте и прочее.
isicju
я сам не разбираюсь в издательствах но мне кажется что это из разряда написание книги ради публикации. в подобных книгах будет довольно известная информация, с овощной и безликой подачей. автор не будет придумывать свой оригинальный стиль или делиться каким то своим опытом. он просто агрегирует уже существующую информацию из публичных статей и немного отредактирует. часто такие авторы пишут "джава для начинающих" а через пол года "питон для начинающих". те подобные авторы не имеют большого опыта но имеют опыт в написании таких "книг для новичков". я сам в своё время пользовался такими книгами, но с текущим опытом я бы рекомендовал такие книги выбрасывать.
yarric
Предпочитаю видеогайды
Molechka Автор
Каждому своё )