НПО «Компьютер»
Компания
25,88
рейтинг
18 октября 2014 в 00:29

Разработка → Классификация видов тестирования из песочницы

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.
Виды тестирования


Карту можно скачать тут.

Карта с видами тестирования на каждое занятие


Повторение — мать учения.

Пословица разных народов мира.

Виды тестирования сгруппированы на mind-карте по:
  • целям;
  • хронологии выполнения;
  • формальности;
  • позитивности;
  • ...


Каждое занятие выбирали:
  • Тестируемое приложение или сервис: почтовый клиент, видео-хостинг, ...
  • Опорный вид тестирования, например, основное функциональное ручное позитивное … тестирование
  • Несколько видов тестирования для сравнения с опорным: повторное, автоматическое, негативное

Начинали выполнять тестовые работы в рамках выбранного опорного вида тестирования.

Состав тестовых работ выбирался из опорного списка:
  1. Планирование.
  2. Подготовка сценариев.
  3. Подготовка тестового окружения.
  4. Выполнение тестов.
  5. Анализ результатов тестирования.
  6. Отчёты.
  7. Отслеживание дефектов.


Каждый раз для выбора вида тестирования использовалась карта. Каждый раз использовался опорный список видов работ.

Попарное сравнение


Всё познаётся только в правильно выполненном сравнении.

Автор мне неизвестен, возможно, Фридрих Ницше или Рене Декарт.

На конкретных примерах рассматривали, какая техника тест-дизайна при подготовке сценариев более применима к функциональному тестированию, а какая к конфигурационному. Разбирали в чём отличия выполнения тестов для основного функционального исследовательского тестирования, от основного функционального тестирования по тестам. Чем будут отличаться планы тестирования. Как при этом, выглядят проекты тестов (чеклист или mind-карта, против инструкций с порядком действий и ожидаемым результатом). Что является общим — процесс отслеживания дефектов.

Рассматривали, чем отличаются отчёты по конфигурационному тестированию и тестрованию масшабируемости, или отчёты по нагрузочному и объёмному.

Приносил примеры отчётов, несекретных и старых, сокращал их до 3-х страниц, удалив конфиденциальную информацию. Разбирали, что в отчётах общего (структура: цели, основа, краткие результаты, детали). В чём отличия. Как их читать. Как составлять. Как формировать автоматически.


Так, перебирая попарно виды тестирования формировал представление о выборе инструментов, подходов, целей и задач изучаемой деятельности.

Список работ по тестированию взял из SWEBOK (v3), глава 4 «Software Testing», раздел «Test Process», подраздел «Test Activities».
image

Эти виды работ выполняют инженеры по тестированию постоянно. Каждый вид работ важен. Для каждого есть хорошие и плохие рекомендации, инструменты, техники. Целью лекционных занятий было донесение до студентов видов тестирования и видов работ по тестированию. Относительно небольшой перечень знаний, и этих знаний достаточно, чтобы начать улучшать качество программного обеспечения.

Зачем карта


Нам не дано предугадать, как слово наше отзовется ...

Фёдор Иванович Тютчев, 27 февраля 1869.

Карта является опорным конспектом для преподавателя. Напоминает о чём, надо успеть сказать. Помогает не сказать лишнего. Ведь времени так мало, а рассказать надо так много.

Ранее преподавал в учебном классе, где были только парты доска и мел. На занятия приходил точно к началу, доску не готовил. Стоять спиной и рисовать изучаемую предметную область во время занятий не хотел. Объяснить взаимосвязи на схемах удобно. Поэтому для каждой темы делал mind-карту. Распечатывал в нескольких экземплярах, раздавал студентам на занятии. Доску и мел использовал для изображения примеров. Рисовали как байтики движутся по схеме системы и приводят к SQL-инъекции, или как работает горизонтальное масшабирование. Так сформировалась привычка готовить mind-карты.

Карта позволяет:
  • запоминать материал быстрее;
  • экономить время при начале занятия;
  • использовать официально разрешенную шпаргалку как для преподавателя так и для студента.

Ведя занятие, читаешь по бумаге, но чтение между строк допустимо.

Студенты, имея перед глазами карту, имеют больший выбор:
  • просто слушать;
  • коспектировать;
  • рисовать.

Больше думают, легче находят аналогии, увереннее отвечают на вопросы. Готовишь карту к каждому занятию, студенты начинают ждать очередной материал. И если, вдруг, не подготовить схему, то занятие начнётся с вопроса: «А что, принтер сломался?», — смеются, уже хорошо.

Особенность этой карты с видами тестирования — наличие определений для каждого узла. Если сохранить карту в формате html, получится объёмное чтиво.
image

Есть ограничения использования mind-карт в подготовке темы занятия. При большом количестве узлов, карта плохо читается на формате альбомного листа. И тогда лучше использовать доску и мел — дублировать части схемы на доске.

О доске и меле


Нужно тренировать красивый почерк и стараться рисовать схемы как произведения искусства. Первое время рисовал быстро, писал неровно. Думаю, выглядел, как сумашедший учёный с взъерошенными волосами.

Потом стал стараться писать и рисовать, как в начальных классах. Ровно, красиво, чётко («как слоги в пионерской речёвке»). Студенты стали задавать больше вопросов. Стало понятнее, что занятия стали понятнее.

О преподавании


Готовился основательно. Случались технические сбои и заминки, не всё удавалось показать и объяснить. О каждом случае можно отдельную историю рассказать. Так подготовка лабораторных работ по тестированию — дорога на Эверест, уложенная граблями. Отладить работу автоматического теста в идеальном окружении, бывает, непросто. А если окружение неидеальное, на каждом учебном компьютере оно своё, и тест написан студентом на скорую руку, то лишь телепатия и «эффект разработчика», в которого ты перевоплощаешься, могут помочь.

Преподавание позволяет научиться лучше рассказывать, писать, видеть. Выбирать основное и простое. И будет, что вспомнить, с улыбкой.
Стоит попробовать.

Титры


Классификацию видов тестирования составила Юлия Григорьева, на сколько мне известно (если авторов было несколько, сообщите пожалуйста). Получился набор статей на wiki-узле отдела тестирования.
При составлении статей использовались различные источники:
  • Стандартный глоссарий терминов, используемых в тестировании программного обеспечения
  • Книга «Гибкое тестирование...» (Криспин и др.)
  • Книга «Тестирование программного обеспечения» (Канер и др.)
  • Книга «Верификация программного обеспечения» (Синицын и др.)
  • Книга «Usability Engineering» (Nielsen)
  • Глоссарий NIAG
  • Сайт «Про Тестинг»
  • Глоссарий НПО Компьютер


Полувшийся набор статей оформил в виде карты. Термины могут быть уточнены, поэтому разместил файл на github, для поддержки версионности. Картинки пока размещены в Яндекс.Фото, надо бы положить их вместе с картой и зафиксировать в разделе releases. TypesOfTesting
Для составления карты использовал FreeMind 0.9.0. Также можно использовать xMind и другие инструменты, поддерживающие формат с расширением «mm». FreeMind — free mind mapping software
SWEBOK 3 изначально был каркасом курса обучения. В описании специальности было написано, что студенты обучаются программной инженерии. Когда спросил опытного преподавателя, что взять за основу курса, он сказал, что программная инженерия — это SWEBOK. Software Engineering Body of Knowledge (SWEBOK) Home
Учебный курс «Тестировние и отладка программного обеспечения» тестировался в 2014 году на студентах кафедры «Програмное обеспечение»: Надежда, Олег, Рамиль, Дмитрий, Анатолий, Артур, Юрий.
Аудиторию и оборудование предоставил Ижевский государственный технический университет имени М. Т. Калашникова. www.istu.ru
В статье использован кадр из фильма Назад в будующее 2, где Док объясняет, как Биф создал версию будующего, в котором сейчас находятся герои. Photos with Christopher Lloyd
В статье использованы пословицы, стихи и фразы, которые стараниями разных людей засели в голове. И иконки из темы Faenza. Faenza
Автор: @polarnik
НПО «Компьютер»
рейтинг 25,88
Компания прекратила активность на сайте

Похожие публикации

Комментарии (35)

  • +2
    У меня тоже была задача сделать с нуля семестровый курс, причём за очень сжатый срок. И строил его тоже на основе классификаций.

    За карту спасибище, буду давать ссылку студентам для подготовки по крайней мере (а со следующего семестра можно и на парах использовать).

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

    Сколько раз нужно было вести свой курс, чтобы перестать вносить в него правки? :)
    • +1
      Пожалуйста.
      Да, приёмочное тестирование скатилось вниз, поправлю, можно сделать так:
      1. Комплексное
      2. Приёмочное, с ним же входное тестирование (на дым)
      3. Основное
      4. Повторное
      5. Регрессионное

      Тут надо объяснить студентам, что хотя регрессионное и в одной группе с повторным, и группа называется «По хронологии выполнения». Нельзя сказать, что регрессионное всегда до, после или во время повторного. Можно рассказать как было когда-то в реальной жизни, отметив, что приёмочное было до основного и почему. А в практике студентов приёмочного может и не быть.

      Курс по тестированию вёл один раз (студентам). И рассказываю коллегам частями.
  • –2
    Какой практический смысл в этой схеме? Все эти разбиения банальны, параметры по которым можно и нужно оценивать приложение можно и без схемы вывести — просто подумав.
    Вместо просто научить человека думать, его голову забивают схемами, табличками и т.п., вопрос — что останется в его голове после сдачи экзамена?
    Я на сто процентов уверен что если просто дать реальную задачу студенту, а именно написать программу, попросить покрыть ее тестами, обсудить по итогам какие тесты вообще имели смысл для конкретно его задачи, достаточно ли, или перебор с выдаваемыми им результатами, это дало бы в разы больший эффект.
    • +2
      Аллегория. Зачем учить математику.
      «Математику уже затем учить надо,
      что она ум в порядок приводит» М.В. Ломоносов
    • +3
      Вы не правы, схема автора весьма полезная, особенно, если будет подкреплена хотя бы краткими описаниями. Задача тестирования ПО не такая простая, как кажется, а с ростом сложности ПО, сложность его (полноценного) тестирования растет совсем нелинейно. Такая схема хорошо поможет при подготовке плана тестирования. Правда, без боевой практики понять все отличия скорее-всего смогут единицы.
      • 0
        Автор разбил все пространство видов тестирования на кучу переменных, объединение значений каждой из них и есть все виды тестирования. Практически все значения переменных имеют между собой не пустые пересечения, (ручное тестирование может быть отнесено к чему угодно — хоть к ящикам, хоть к анализу кода)

        Поэтому каждый реальный тест в классификации автора должен записываться как запись значений всех или почти всех переменных:
        что то вроде проведем ка «комплексное» «модульное» «исследовательское» «нефункциональное конфигурационное» «полуавтоматическое» тестирование этой программы.

        Вам это действительно поможет при планировании?
    • +1
      Спасибо за замечание. Есть объективные ограничения — количество часов лекционных и практических занятий. Несогласованность — код, написанный на дисциплине, связанной с разработкой не тестируется на дисциплине связанной с тестированием и отладкой. И субъективные ограничения — да, надо сеять доброе вечное, регулярно давать домашние задания, обсуждать со студентами результаты. Преподавание — это дополнительная работа, которую попросили сделать на основной работе. Преподаванию уделял не столь много времени и сил, сколько было бы нужно для большего эффекта.
      • +1
        А меня всегда восхищало как на западе — преподают курс по началам компьютерной графики например вот
        graphics.stanford.edu/courses/cs248-videogame-competition/
        Что по итогам должен сделать студент — написать любую видеоигру в которой он сможет продемонстрировать знания которые он получил.
        К сожалению там почему то почти все странички не работают, точно помню, что часть из этих написанных в виде курсовой работы игрушек стали популярны (за давностью уже не помню какие).
        Теория тесно переплетена с практикой, а у нас все как вы пишете — преподаватели не заинтересованы, да и студентам по большей части все равно.
        Как итог у нас большая часть предметов в вузах для галочки.
  • +2
    Есть понятие модели, у автора она явно перегружена. В этом и состоит искусство выбрать такие критерии, чтобы и не упростить сильно модель, но и не усложнить незначащими деталями.

    Критерий, связанный с работой человеческого мозга. Все что больше 7 плохо, лучше 3.
    • +1
      Подобная классификация нужна, ибо часто люди не понимают что смешивают в кучу несвязанные термины. Имхо, проблема данной структуры в названиях. Не все из них отражают суть. Нагрузочное так вообще лучше убрать, чем вбивать HPшную терминологию (потом не отскребешь из мозгов). «Надежность и восстановление после сбоев» называется отказоустойчивостью и имеет место быть как в функциональной части так и в нагрузочной. Нет юнит-тестов, не видно всяких санити и смоуков.

      Ну и зубрить это тоже имхо не имеет резона. С опытом само запомнится. Как подсказка отлично.
      • 0
        Конечно, могу отбиваться. Что смоуки и санити они во входном тесте где-то. И так как, часто люди специализируются. То для автоматизаторов смоуку соотвествует входной тест (на дым) для автоматических тестов. А специалист по ручному функциональному тестированию под входным тестом будет понимать, то что вы понимаете под санити. И оба этих специалиста найдут общий язык, великий и могучий.

        Замечу, что зубрить не надо. Цель в том, чтобы обяснить отличия и общности, расставить приоритеты. Например, легко объяснить отличие негативного теста от позитивного. Но важно заметить, что тот же санити будет, почти всегда, позитивным. И если у вас 1000 тестов, и надо оставить только 200 из них, то скорее всего, сокращение вы начнёте с негативных. Потому-то потому-то…

        На конкретном месте работы пусть, вообще, не будет применяться понятие негативного теста. Но объяснить, чем такой тест будет отличаться от позитивного, стоит.

        Отбиваться можно долго. И в конечном итоге, мы поймём друг друга. Как говорит мой друг: хороший биолог объяснит физику-ядерщику атомное устройство вселенной на тычинках и пестиках. Так и мы увяжем санити с входным тестом.
        • +1
          например, основное функциональное ручное позитивное … тестирование
          Простите великодушно, может я чего не понял… Но Вы действительно учите студентов нашего ИжГТУ, что делать негативное тестирование не нужно, когда выполняется тестирование позитивное?
          • 0
            И вы меня простите, если натолкнул на подобную мысль. Нет, такому не учил.
          • 0
            Вероятно, у вас есть некие сомнения по озвученному вопросу. Подкреплю их собственными наблюдениями и наблюдениями коллег.

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

            Программа не выполняющая основные позитивные сценарии, чаще всего, не нужна пользователю.

            Тут уместно задать почти философский вопрос: «А какая же программа нужна пользователю?»

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

            Могу привести рассуждение отталкиваясь от тестирования защищённости, стрессового тестирования и их важности.

            По роду деятельности отвечаю преимущественно за негативные сценарии, а мои коллеги за позитивные. Если вы занимаетесь промышленной разработкой, то знаете как ищутся более оптимальные способы планирования, организации и выполнения работ по тестированию, чтобы убедиться в выполнении основных сценариев. Основными сценариями занимается большая часть команды, большую часть времени. На негативные сценарии и специализированные виды тестирования выделяют отдельных людей.

            Спасибо за хорошую идею. В следующий раз выскажу именно ту мысль, что вы изначально поняли. И посмотрю, поставит ли кто-нибудь её под сомнение.
            • +1
              Вы практически пересказали недавнее выступление Алексея Баранцева.

              Мне всё же показалось, что Баранцев рассматривал позитивность тестов сценариев в разрезе приоритезации. То есть тот случай, когда у нас нет времени на прогон всех тестов, и поэтому мы должны выбирать. В качестве критерия выбора была предложена позитивность сценариев. Однако, очень легко найти пример, когда этот критерий выбора будет работать плохо.

              Например, любая программа с функциональностью сохранения пользовательских данных в файл. Позитивный сценарий — вызываем функцию сохранения, вводим параметры (например, имя файла), нажимаем ОК, и всё хорошо. Если следовать предложенному критерию выбора, остальные (негативные) сценарии не являются приоритетными. Однако, пользователь не будет рад, если вместо сохранения данных программа аварийно завершается с потерей этих самых данных.

              Что в данном примере было сделано неправильно? Неправильно выбран критерий приоритезации. Нужно руководствоваться не только позитивностью сценария, но и критичностью конкретного кусочка функциональности. Я бы даже перефразировал Алексея следующим образом: «Как правило, негативные сценарии являются менее критичными для пользователя». Как правило, но не всегда.

              Что касается классификации…

              Негативные тесты конечно же являются отдельным типом тестирования. Если у вас в компании есть ресурсы, и отдельные люди для их проектирования и выполнения, это очень даже хорошо! Потому что негативные тесты действительно сложно проектировать: нужно сесть и придумать с десяток ситуаций, когда система может или будет сбоить.

              Но: а) в большинстве компаний позитивные и негативные тесты составляются одними и теми же людьми; б) рассмотрение негативных тестов в отрыве от позитивных (на учебных практических занятиях) может привести к негативному эффекту — студенты запомнят, что во время проектирования позитивных тесты не обязательно думать о негативных.
              • 0
                Интересная беседа получается. Давайте напишем статью на тему позитивных и негативных сценариев тестирования.

                Введение в том, что жизнь — череда выборов, как правило, выбор падает на позитивный сценарий тестирования, а негативные включаются в работу, если начать копать ошибку в позитивном, или по остаточному принципу. Как правило, но не всегда.
                Содержательная часть из примеров, ситуаций, позитивных и негативных сценариев, видов тестирования, размеров аудитории продукта.
                Вывод, что негативные сценарии сложно проектировать. Тут считаю, что ещё более сложно выполнять негативные сценарии, технически сложные негативные сценарии (имя файла на 2000 символов, картинка на 500 МБайт, особый набор входных параметров для проверки экранирования вывода, ...). И они важны.

                Касаемо неоригинальности мысли. Алексей Баранцев, проводя выступление про тестирование по вариантам использования, предложил обсудить эту тему с аналитиками. Так и поступил. Обсудил тему с коллегой аналитиком (Стасом), который не был на выступлении. Выше изложены мысли из нашей с ним беседы, скорее, мысли Стаса, чем мои. И при изложении, видимо, изложил мысли словами Алексея Баранцева. Алексей произвёл впечатление, хорошее было выступление, рад, что вы там были.

                Касаемо студентов. На практике не закрепил с ними проектирование тестов. Тесты проектировали, были обсуждения, рассказы, примеры. Не было вовлечения в процесс, когда студент осознанно проектирует, и лишь консультируешь и направляешь. Вовлечение есть, когда студент приходит на производственную практику. От того, думаю, студенты не запомнили тему проектирования. В частности, не осознали роль негативных сценариев при проектировании, которую мы сейчас обсуждаем. Когда студенты придут в вашу компанию, придётся их обучать проектированию тестов. Вклад преподавания в том, что студент сможет сделать осознанный выбор в пользу тестирования и будет ориентироваться в предметной области.
  • +1
    Возможно вы владеете тайным знанием как вселить в умы подрастающего поколения тестировщиков ответственность и проявление изобретательности при написании тестов и последующем прогоне? Было бы интересно узнать :)

    Как показывает мой опыт от того, что вы рассказали людям кусочек теории заметного повышения скилов или рвения не наблюдается. Должно что-то случиться прежде чем в человеке проснется настоящий пытливый тестировщик, но я пока не могу уловить, что именно на это влияет.
    • +1
      Должно что-то случиться прежде чем в человеке проснется настоящий пытливый тестировщик, но я пока не могу уловить, что именно на это влияет.

      Есть очень хорошая фраза, или даже модель, которая в свое время помогла мне тестировать свои исходники с удовольствием. Эту модель я почерпнул из этой книги и выглядит она примерно так: при написании программы у программиста постепенно нарастает страх того, что рано или поздно программа перестанет работать и найти причину проблемы будет очень сложно. Более того, возможна ситуация, когда проблема настолько сложна, что придется задумываться об изменении всей архитектуры программы, так как текущая архитектура не позволяет решить задачу и упирается в ошибку. Этот страх нарастает тем больше, чем больше кода написано, потому необходимо всегда тестировать программу. Тестирование уменьшает страх и делает программиста более уверенным в своем выборе. На деле программирование без страха должно выглядеть так: Программирование -> Повышение страха -> Тестирование -> Понижение страха -> Программирование (согласно книге первым идет написание теста, но я не стал усложнять).

      Другими словами человек станет настоящим тестировщиком когда поймет, что страх перед ошибками можно побороть через тестирование.
      • 0
        Вы немного не с того края зашли, интересует тестирование для тестировщика, а не программиста.
        • +1
          Если тестировщик не является программистом, то он просто должен полюбить ту программу, которую тестирует. Хороший тестировщик — это хороший, любящий программу пользователь с долей недоверия.
      • 0
        Тестирование, как программирование проверки качества программирования эффективно, только если программисты софта и теста разные люди.
        Иначе мозг, особенно изобретательный и с хорошей памятью, старательно обходит узкие места при написании тестов.

        А вообще практик море. Мне больше для работы подходит способ «от API». Пока до мелочей не распишешь все спецификации вызовов, разрисуешь UMLки, базы данных и т.д. к программированию можно не прикасаться даже. Детализация нужна примерно до уровня «одна страничка кода на модуль». Потом конечно получается быстро, надежно, эффективно, понятно, но… безумно скучно.

        Поэтому это способ больше для работы, а не для души. Для души — безумно кривые, но интересные программки — самое оно. Там вообще можно не то что тестами, а даже спецификациями не заморачиваться ))).

    • 0
      Зверя в студентах не будил. Сам учился на примерах.
      Наиболее сильные примеры — публикации хакеров. Замечание описано в три предложения. Поначалу каждое слово незнакомо. И надо понять ход мысли человека, который нашел этот дефект. Если научиться так мыслить, то на тестируемую систему уже смотришь иначе.

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

      Также пересмотр замечаний на работе. Использую «тематический» пересмотр. Просматриваю замечания и пожелания, в поисках замечаний по защищённости, например, или по удобству использования. Просмотр, указание тегов или категорий, поиск дублей. Вроде бы, это рутина, но это помогает. Пересмотр можно делать и без тематики. Посмотреть замечания за последние несколько месяцев, расширить представление о качестве продукта и почерпнуть изобретательные способы. Наиболее простые и красивые из изобретательных способов поиска замечаний (хаки), видно сразу.
      • 0
        Также просмотр замечаний и исправлений по ним помогает найти людей, у которых стоит поучиться.
  • +1
    Fuzzy testing вы отнесли в «исследовательское»?
    • 0
      Да. Тестирование защищённости почти всегда исследовательское или специализированное (на моей практике). Это будет тестирование защищённости, автоматизированное, негативное. А дальше по ситуации.

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

      Для тестирования защищённости по тестам только-только приспособил ASVS и Testing Guide, рекомендую.
  • +1
    Карта несомненно заслуживает внимания. Но ни в статье ни на гитхабе нет ни слова про лицензию. Еще не определились?
  • +4
    В таких курсах обычно всегда есть только техника и нет психологии. Выше уже спросили про это.
    Технике научиться не так уж трудно, к тому же, редкому тестировщику реально понадобится вся эта прорва умений от белоящичного анализа кода до тестирования безопасности.
    А вот психология — это то самое, что и будет отличать хорошего тестировщика от манкикликера.
    Хороший должен обладать:
    — Мотивация
    — Честность
    Ну и массой других качеств (настойчивость, изобретательность и т.д.), но без вышеперечисленных они бесполезны. Без оныъ быть тестировщиком — безнадежное занятие. Такой человек будет способен только проходить тесты написанные кем-то другим (максимум писать какие-то очевидные тесты) и не более.

    И курс был бы куда полезнее, если бы такие качества каким-то образом там прививались. Правда, увы, но я не знаю, как этого можно достичь.
    • 0
      От лица тестировщиков, считающих себя хорошими — спасибо.
      Есть мнение, что одно из главных качеств тестировщика — это чувство юмора. Подробнее можно прочитать в интервью с моей коллегой Асиёй: День тестировщика 2014: поздравления от Ижайти.

      И чтобы быть энергичным, ищущим неизведанное, надо наравне с психологией подтягивать и физику. Зайдите в такой отдел тестирования, который считаете хорошим. Наверняка, увидите крепких ребят и очаровательных девушек. Круг их спортивных интересов различный. Нужные качества прививаются естественным образом.
      • +1
        Однажды я услышал, как одна девушка-тестировщица с восторгом рассказывала двум другим девушкам, как она прочитала «Вы наверное шутите, мистер Фейнман». Так что конечно, вы правы, на счет чувства юмора :)
        • 0
          Чтобы избежать разночтения отмечу, под физикой имел в виду физическую подготовку. Занятия спортом делают человека спокойным, уверенным и упрямым.

          Также знаю девушку, которая «прямо растекается по стулу», когда читает байки из «Физики шутят», «Математики тоже шутят»,…
          — Как измерить силушку богатырскую?
          — Нужно умножить массушку на ускореньице!


          Чувство юмора можно привнести в преподавание, начиная рассказ с хорошей байки. Байки в преподавании очень важны. К счастью, их не всегда надо выдумывать. Ведь уже случилось столько курьёзных историй из-за багов. Некоторые байки считаю выдуманными, особенно по части защищённости и информационной войны; когда ищешь первоисточник, выясняется, что история записана со слов отставного генерала, которую он услышал от своего приятеля. И, вроде, можно рассказать об упавшей ракете или лопнувшем нефтепроводе, но с тем же успехом можно начать рассказ так: «Итак. Представьте ...», — и дальше понеслась фантазия.
          • +1
            Айтишники (не только тестировщики, а вообще в целом) в этом смысле имеют преимущество. Во-первых, в большинстве своем они зарабатывают больше, чем окружающие их люди. Во-вторых, они в целом более интеллектуально развитые, нежели окружающие (не умнее, подчеркиваю. А интеллектуальнее). И наконец, в-третьих, работа сидячая.
            Все три причины вместе складываются в то, что достаточно большая часть айтишников понимают, что какой-никакой спорт обязан быть.

            Я сам социальный танцор (аргентинское танго), танцую для удовольствия, а не как спорт, но при этом, какие-то нагрузки, разумеется, все равно присутствуют. Так вот, я как-то подсчитал на очередном выездном фестивале, что треть присутствующих так или иначе айтишники.
  • +1
    Вы изучали уже существующие курсы по тестированию или создавали курс полностью самостоятельно?

    Несколько замечаний.
    По целям — нефункциональное тестирование может проводиться в контексте каждого атрибута качества. Навскидку, вы забыли проверить продукт с целью выявления следующих его свойств:
    — доступность, соответствие стандартам, поддерживаемость, тестируемость

    По степени автоматизации правильно было бы сказать: ручное, автоматизированное, автоматическое. Слово «полуавтоматизированное» не несет никакого смысла.

    Упомянутый вами Канер в его классификации «по исполнителям» выделяет больше 2 пунктов (альфа и бета). Пользовательское, экспертное как минимум.

    В схеме совсем отсутствует популярная классификация по способу оценки результатов теста. Также некуда воткнуть тестирование на основе рисков, тестирование требований и спецификаций.

    Тем не менее, вы проделали большой объем работы и сам подход мне понравился. Ставлю плюс.
    • 0
      Благодарю. Постараюсь учесть выявленные недостатки. Абсолютно согласен с неинформативностью «полуавтоматизированного» тестирования. Все тестирование в IT как минимум такое, и приставка «полу» постоянно смущала. Спасибо, что нашли нужные слова.
  • 0
    ...del

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

Самое читаемое Разработка