Comments 35
У меня тоже была задача сделать с нуля семестровый курс, причём за очень сжатый срок. И строил его тоже на основе классификаций.
За карту спасибище, буду давать ссылку студентам для подготовки по крайней мере (а со следующего семестра можно и на парах использовать).
В целом классификация кажется такой же, большая часть отличий сбилась в группе «по хронологии выполнения». А ещё заметил, что конфигурационное заношу в тестирование производительности.
Сколько раз нужно было вести свой курс, чтобы перестать вносить в него правки? :)
За карту спасибище, буду давать ссылку студентам для подготовки по крайней мере (а со следующего семестра можно и на парах использовать).
В целом классификация кажется такой же, большая часть отличий сбилась в группе «по хронологии выполнения». А ещё заметил, что конфигурационное заношу в тестирование производительности.
Сколько раз нужно было вести свой курс, чтобы перестать вносить в него правки? :)
Пожалуйста.
Да, приёмочное тестирование скатилось вниз, поправлю, можно сделать так:
Тут надо объяснить студентам, что хотя регрессионное и в одной группе с повторным, и группа называется «По хронологии выполнения». Нельзя сказать, что регрессионное всегда до, после или во время повторного. Можно рассказать как было когда-то в реальной жизни, отметив, что приёмочное было до основного и почему. А в практике студентов приёмочного может и не быть.
Курс по тестированию вёл один раз (студентам). И рассказываю коллегам частями.
Да, приёмочное тестирование скатилось вниз, поправлю, можно сделать так:
- Комплексное
- Приёмочное, с ним же входное тестирование (на дым)
- Основное
- Повторное
- Регрессионное
Тут надо объяснить студентам, что хотя регрессионное и в одной группе с повторным, и группа называется «По хронологии выполнения». Нельзя сказать, что регрессионное всегда до, после или во время повторного. Можно рассказать как было когда-то в реальной жизни, отметив, что приёмочное было до основного и почему. А в практике студентов приёмочного может и не быть.
Курс по тестированию вёл один раз (студентам). И рассказываю коллегам частями.
Какой практический смысл в этой схеме? Все эти разбиения банальны, параметры по которым можно и нужно оценивать приложение можно и без схемы вывести — просто подумав.
Вместо просто научить человека думать, его голову забивают схемами, табличками и т.п., вопрос — что останется в его голове после сдачи экзамена?
Я на сто процентов уверен что если просто дать реальную задачу студенту, а именно написать программу, попросить покрыть ее тестами, обсудить по итогам какие тесты вообще имели смысл для конкретно его задачи, достаточно ли, или перебор с выдаваемыми им результатами, это дало бы в разы больший эффект.
Вместо просто научить человека думать, его голову забивают схемами, табличками и т.п., вопрос — что останется в его голове после сдачи экзамена?
Я на сто процентов уверен что если просто дать реальную задачу студенту, а именно написать программу, попросить покрыть ее тестами, обсудить по итогам какие тесты вообще имели смысл для конкретно его задачи, достаточно ли, или перебор с выдаваемыми им результатами, это дало бы в разы больший эффект.
Аллегория. Зачем учить математику.
«Математику уже затем учить надо,
что она ум в порядок приводит» М.В. Ломоносов
«Математику уже затем учить надо,
что она ум в порядок приводит» М.В. Ломоносов
Вы не правы, схема автора весьма полезная, особенно, если будет подкреплена хотя бы краткими описаниями. Задача тестирования ПО не такая простая, как кажется, а с ростом сложности ПО, сложность его (полноценного) тестирования растет совсем нелинейно. Такая схема хорошо поможет при подготовке плана тестирования. Правда, без боевой практики понять все отличия скорее-всего смогут единицы.
Автор разбил все пространство видов тестирования на кучу переменных, объединение значений каждой из них и есть все виды тестирования. Практически все значения переменных имеют между собой не пустые пересечения, (ручное тестирование может быть отнесено к чему угодно — хоть к ящикам, хоть к анализу кода)
Поэтому каждый реальный тест в классификации автора должен записываться как запись значений всех или почти всех переменных:
что то вроде проведем ка «комплексное» «модульное» «исследовательское» «нефункциональное конфигурационное» «полуавтоматическое» тестирование этой программы.
Вам это действительно поможет при планировании?
Поэтому каждый реальный тест в классификации автора должен записываться как запись значений всех или почти всех переменных:
что то вроде проведем ка «комплексное» «модульное» «исследовательское» «нефункциональное конфигурационное» «полуавтоматическое» тестирование этой программы.
Вам это действительно поможет при планировании?
Спасибо за замечание. Есть объективные ограничения — количество часов лекционных и практических занятий. Несогласованность — код, написанный на дисциплине, связанной с разработкой не тестируется на дисциплине связанной с тестированием и отладкой. И субъективные ограничения — да, надо сеять доброе вечное, регулярно давать домашние задания, обсуждать со студентами результаты. Преподавание — это дополнительная работа, которую попросили сделать на основной работе. Преподаванию уделял не столь много времени и сил, сколько было бы нужно для большего эффекта.
А меня всегда восхищало как на западе — преподают курс по началам компьютерной графики например вот
graphics.stanford.edu/courses/cs248-videogame-competition/
Что по итогам должен сделать студент — написать любую видеоигру в которой он сможет продемонстрировать знания которые он получил.
К сожалению там почему то почти все странички не работают, точно помню, что часть из этих написанных в виде курсовой работы игрушек стали популярны (за давностью уже не помню какие).
Теория тесно переплетена с практикой, а у нас все как вы пишете — преподаватели не заинтересованы, да и студентам по большей части все равно.
Как итог у нас большая часть предметов в вузах для галочки.
graphics.stanford.edu/courses/cs248-videogame-competition/
Что по итогам должен сделать студент — написать любую видеоигру в которой он сможет продемонстрировать знания которые он получил.
К сожалению там почему то почти все странички не работают, точно помню, что часть из этих написанных в виде курсовой работы игрушек стали популярны (за давностью уже не помню какие).
Теория тесно переплетена с практикой, а у нас все как вы пишете — преподаватели не заинтересованы, да и студентам по большей части все равно.
Как итог у нас большая часть предметов в вузах для галочки.
Есть понятие модели, у автора она явно перегружена. В этом и состоит искусство выбрать такие критерии, чтобы и не упростить сильно модель, но и не усложнить незначащими деталями.
Критерий, связанный с работой человеческого мозга. Все что больше 7 плохо, лучше 3.
Критерий, связанный с работой человеческого мозга. Все что больше 7 плохо, лучше 3.
Подобная классификация нужна, ибо часто люди не понимают что смешивают в кучу несвязанные термины. Имхо, проблема данной структуры в названиях. Не все из них отражают суть. Нагрузочное так вообще лучше убрать, чем вбивать HPшную терминологию (потом не отскребешь из мозгов). «Надежность и восстановление после сбоев» называется отказоустойчивостью и имеет место быть как в функциональной части так и в нагрузочной. Нет юнит-тестов, не видно всяких санити и смоуков.
Ну и зубрить это тоже имхо не имеет резона. С опытом само запомнится. Как подсказка отлично.
Ну и зубрить это тоже имхо не имеет резона. С опытом само запомнится. Как подсказка отлично.
Конечно, могу отбиваться. Что смоуки и санити они во входном тесте где-то. И так как, часто люди специализируются. То для автоматизаторов смоуку соотвествует входной тест (на дым) для автоматических тестов. А специалист по ручному функциональному тестированию под входным тестом будет понимать, то что вы понимаете под санити. И оба этих специалиста найдут общий язык, великий и могучий.
Замечу, что зубрить не надо. Цель в том, чтобы обяснить отличия и общности, расставить приоритеты. Например, легко объяснить отличие негативного теста от позитивного. Но важно заметить, что тот же санити будет, почти всегда, позитивным. И если у вас 1000 тестов, и надо оставить только 200 из них, то скорее всего, сокращение вы начнёте с негативных. Потому-то потому-то…
На конкретном месте работы пусть, вообще, не будет применяться понятие негативного теста. Но объяснить, чем такой тест будет отличаться от позитивного, стоит.
Отбиваться можно долго. И в конечном итоге, мы поймём друг друга. Как говорит мой друг: хороший биолог объяснит физику-ядерщику атомное устройство вселенной на тычинках и пестиках. Так и мы увяжем санити с входным тестом.
Замечу, что зубрить не надо. Цель в том, чтобы обяснить отличия и общности, расставить приоритеты. Например, легко объяснить отличие негативного теста от позитивного. Но важно заметить, что тот же санити будет, почти всегда, позитивным. И если у вас 1000 тестов, и надо оставить только 200 из них, то скорее всего, сокращение вы начнёте с негативных. Потому-то потому-то…
На конкретном месте работы пусть, вообще, не будет применяться понятие негативного теста. Но объяснить, чем такой тест будет отличаться от позитивного, стоит.
Отбиваться можно долго. И в конечном итоге, мы поймём друг друга. Как говорит мой друг: хороший биолог объяснит физику-ядерщику атомное устройство вселенной на тычинках и пестиках. Так и мы увяжем санити с входным тестом.
например, основное функциональное ручное позитивное … тестированиеПростите великодушно, может я чего не понял… Но Вы действительно учите студентов нашего ИжГТУ, что делать негативное тестирование не нужно, когда выполняется тестирование позитивное?
И вы меня простите, если натолкнул на подобную мысль. Нет, такому не учил.
Вероятно, у вас есть некие сомнения по озвученному вопросу. Подкреплю их собственными наблюдениями и наблюдениями коллег.
Пользователь не замечает ошибок программы, пока программа выполняет основной сценарий работы (почти всегда — позитивный) в соответствии с ожиданиями пользователя.
Как только основной сценарий расходится с ожиданиями, внимательность и осторожность пользователя повышаются многократно. И уже становится очень важным, чтобы на негативных сценариях программа вела себя достойно.
Программа не выполняющая основные позитивные сценарии, чаще всего, не нужна пользователю.
Тут уместно задать почти философский вопрос: «А какая же программа нужна пользователю?»
Отвечая на него можно придти к мысли, что если у программы лишь десяток пользователей, основной сценарий работы которых хорошо известен и их ожидания выполняются. То приоритет негативных сценариев снижается. Пользователи даже сами могут сказать разработчику не усложнять и не мудрить, так как их всё устраивает.
Если же у программы сотни и тысячи пользователей, и программа недостаточно проста, чтобы соответствовать ожиданием всех. То просто необходимо уделять внимание негативным сценариям.
Могу привести рассуждение отталкиваясь от тестирования защищённости, стрессового тестирования и их важности.
По роду деятельности отвечаю преимущественно за негативные сценарии, а мои коллеги за позитивные. Если вы занимаетесь промышленной разработкой, то знаете как ищутся более оптимальные способы планирования, организации и выполнения работ по тестированию, чтобы убедиться в выполнении основных сценариев. Основными сценариями занимается большая часть команды, большую часть времени. На негативные сценарии и специализированные виды тестирования выделяют отдельных людей.
Спасибо за хорошую идею. В следующий раз выскажу именно ту мысль, что вы изначально поняли. И посмотрю, поставит ли кто-нибудь её под сомнение.
Пользователь не замечает ошибок программы, пока программа выполняет основной сценарий работы (почти всегда — позитивный) в соответствии с ожиданиями пользователя.
Как только основной сценарий расходится с ожиданиями, внимательность и осторожность пользователя повышаются многократно. И уже становится очень важным, чтобы на негативных сценариях программа вела себя достойно.
Программа не выполняющая основные позитивные сценарии, чаще всего, не нужна пользователю.
Тут уместно задать почти философский вопрос: «А какая же программа нужна пользователю?»
Отвечая на него можно придти к мысли, что если у программы лишь десяток пользователей, основной сценарий работы которых хорошо известен и их ожидания выполняются. То приоритет негативных сценариев снижается. Пользователи даже сами могут сказать разработчику не усложнять и не мудрить, так как их всё устраивает.
Если же у программы сотни и тысячи пользователей, и программа недостаточно проста, чтобы соответствовать ожиданием всех. То просто необходимо уделять внимание негативным сценариям.
Могу привести рассуждение отталкиваясь от тестирования защищённости, стрессового тестирования и их важности.
По роду деятельности отвечаю преимущественно за негативные сценарии, а мои коллеги за позитивные. Если вы занимаетесь промышленной разработкой, то знаете как ищутся более оптимальные способы планирования, организации и выполнения работ по тестированию, чтобы убедиться в выполнении основных сценариев. Основными сценариями занимается большая часть команды, большую часть времени. На негативные сценарии и специализированные виды тестирования выделяют отдельных людей.
Спасибо за хорошую идею. В следующий раз выскажу именно ту мысль, что вы изначально поняли. И посмотрю, поставит ли кто-нибудь её под сомнение.
Вы практически пересказали недавнее выступление Алексея Баранцева.
Мне всё же показалось, что Баранцев рассматривал позитивность тестов сценариев в разрезе приоритезации. То есть тот случай, когда у нас нет времени на прогон всех тестов, и поэтому мы должны выбирать. В качестве критерия выбора была предложена позитивность сценариев. Однако, очень легко найти пример, когда этот критерий выбора будет работать плохо.
Например, любая программа с функциональностью сохранения пользовательских данных в файл. Позитивный сценарий — вызываем функцию сохранения, вводим параметры (например, имя файла), нажимаем ОК, и всё хорошо. Если следовать предложенному критерию выбора, остальные (негативные) сценарии не являются приоритетными. Однако, пользователь не будет рад, если вместо сохранения данных программа аварийно завершается с потерей этих самых данных.
Что в данном примере было сделано неправильно? Неправильно выбран критерий приоритезации. Нужно руководствоваться не только позитивностью сценария, но и критичностью конкретного кусочка функциональности. Я бы даже перефразировал Алексея следующим образом: «Как правило, негативные сценарии являются менее критичными для пользователя». Как правило, но не всегда.
Что касается классификации…
Негативные тесты конечно же являются отдельным типом тестирования. Если у вас в компании есть ресурсы, и отдельные люди для их проектирования и выполнения, это очень даже хорошо! Потому что негативные тесты действительно сложно проектировать: нужно сесть и придумать с десяток ситуаций, когда система может или будет сбоить.
Но: а) в большинстве компаний позитивные и негативные тесты составляются одними и теми же людьми; б) рассмотрение негативных тестов в отрыве от позитивных (на учебных практических занятиях) может привести к негативному эффекту — студенты запомнят, что во время проектирования позитивных тесты не обязательно думать о негативных.
Мне всё же показалось, что Баранцев рассматривал позитивность тестов сценариев в разрезе приоритезации. То есть тот случай, когда у нас нет времени на прогон всех тестов, и поэтому мы должны выбирать. В качестве критерия выбора была предложена позитивность сценариев. Однако, очень легко найти пример, когда этот критерий выбора будет работать плохо.
Например, любая программа с функциональностью сохранения пользовательских данных в файл. Позитивный сценарий — вызываем функцию сохранения, вводим параметры (например, имя файла), нажимаем ОК, и всё хорошо. Если следовать предложенному критерию выбора, остальные (негативные) сценарии не являются приоритетными. Однако, пользователь не будет рад, если вместо сохранения данных программа аварийно завершается с потерей этих самых данных.
Что в данном примере было сделано неправильно? Неправильно выбран критерий приоритезации. Нужно руководствоваться не только позитивностью сценария, но и критичностью конкретного кусочка функциональности. Я бы даже перефразировал Алексея следующим образом: «Как правило, негативные сценарии являются менее критичными для пользователя». Как правило, но не всегда.
Что касается классификации…
Негативные тесты конечно же являются отдельным типом тестирования. Если у вас в компании есть ресурсы, и отдельные люди для их проектирования и выполнения, это очень даже хорошо! Потому что негативные тесты действительно сложно проектировать: нужно сесть и придумать с десяток ситуаций, когда система может или будет сбоить.
Но: а) в большинстве компаний позитивные и негативные тесты составляются одними и теми же людьми; б) рассмотрение негативных тестов в отрыве от позитивных (на учебных практических занятиях) может привести к негативному эффекту — студенты запомнят, что во время проектирования позитивных тесты не обязательно думать о негативных.
Интересная беседа получается. Давайте напишем статью на тему позитивных и негативных сценариев тестирования.
Введение в том, что жизнь — череда выборов, как правило, выбор падает на позитивный сценарий тестирования, а негативные включаются в работу, если начать копать ошибку в позитивном, или по остаточному принципу. Как правило, но не всегда.
Содержательная часть из примеров, ситуаций, позитивных и негативных сценариев, видов тестирования, размеров аудитории продукта.
Вывод, что негативные сценарии сложно проектировать. Тут считаю, что ещё более сложно выполнять негативные сценарии, технически сложные негативные сценарии (имя файла на 2000 символов, картинка на 500 МБайт, особый набор входных параметров для проверки экранирования вывода, ...). И они важны.
Касаемо неоригинальности мысли. Алексей Баранцев, проводя выступление про тестирование по вариантам использования, предложил обсудить эту тему с аналитиками. Так и поступил. Обсудил тему с коллегой аналитиком (Стасом), который не был на выступлении. Выше изложены мысли из нашей с ним беседы, скорее, мысли Стаса, чем мои. И при изложении, видимо, изложил мысли словами Алексея Баранцева. Алексей произвёл впечатление, хорошее было выступление, рад, что вы там были.
Касаемо студентов. На практике не закрепил с ними проектирование тестов. Тесты проектировали, были обсуждения, рассказы, примеры. Не было вовлечения в процесс, когда студент осознанно проектирует, и лишь консультируешь и направляешь. Вовлечение есть, когда студент приходит на производственную практику. От того, думаю, студенты не запомнили тему проектирования. В частности, не осознали роль негативных сценариев при проектировании, которую мы сейчас обсуждаем. Когда студенты придут в вашу компанию, придётся их обучать проектированию тестов. Вклад преподавания в том, что студент сможет сделать осознанный выбор в пользу тестирования и будет ориентироваться в предметной области.
Введение в том, что жизнь — череда выборов, как правило, выбор падает на позитивный сценарий тестирования, а негативные включаются в работу, если начать копать ошибку в позитивном, или по остаточному принципу. Как правило, но не всегда.
Содержательная часть из примеров, ситуаций, позитивных и негативных сценариев, видов тестирования, размеров аудитории продукта.
Вывод, что негативные сценарии сложно проектировать. Тут считаю, что ещё более сложно выполнять негативные сценарии, технически сложные негативные сценарии (имя файла на 2000 символов, картинка на 500 МБайт, особый набор входных параметров для проверки экранирования вывода, ...). И они важны.
Касаемо неоригинальности мысли. Алексей Баранцев, проводя выступление про тестирование по вариантам использования, предложил обсудить эту тему с аналитиками. Так и поступил. Обсудил тему с коллегой аналитиком (Стасом), который не был на выступлении. Выше изложены мысли из нашей с ним беседы, скорее, мысли Стаса, чем мои. И при изложении, видимо, изложил мысли словами Алексея Баранцева. Алексей произвёл впечатление, хорошее было выступление, рад, что вы там были.
Касаемо студентов. На практике не закрепил с ними проектирование тестов. Тесты проектировали, были обсуждения, рассказы, примеры. Не было вовлечения в процесс, когда студент осознанно проектирует, и лишь консультируешь и направляешь. Вовлечение есть, когда студент приходит на производственную практику. От того, думаю, студенты не запомнили тему проектирования. В частности, не осознали роль негативных сценариев при проектировании, которую мы сейчас обсуждаем. Когда студенты придут в вашу компанию, придётся их обучать проектированию тестов. Вклад преподавания в том, что студент сможет сделать осознанный выбор в пользу тестирования и будет ориентироваться в предметной области.
Возможно вы владеете тайным знанием как вселить в умы подрастающего поколения тестировщиков ответственность и проявление изобретательности при написании тестов и последующем прогоне? Было бы интересно узнать :)
Как показывает мой опыт от того, что вы рассказали людям кусочек теории заметного повышения скилов или рвения не наблюдается. Должно что-то случиться прежде чем в человеке проснется настоящий пытливый тестировщик, но я пока не могу уловить, что именно на это влияет.
Как показывает мой опыт от того, что вы рассказали людям кусочек теории заметного повышения скилов или рвения не наблюдается. Должно что-то случиться прежде чем в человеке проснется настоящий пытливый тестировщик, но я пока не могу уловить, что именно на это влияет.
Должно что-то случиться прежде чем в человеке проснется настоящий пытливый тестировщик, но я пока не могу уловить, что именно на это влияет.
Есть очень хорошая фраза, или даже модель, которая в свое время помогла мне тестировать свои исходники с удовольствием. Эту модель я почерпнул из этой книги и выглядит она примерно так: при написании программы у программиста постепенно нарастает страх того, что рано или поздно программа перестанет работать и найти причину проблемы будет очень сложно. Более того, возможна ситуация, когда проблема настолько сложна, что придется задумываться об изменении всей архитектуры программы, так как текущая архитектура не позволяет решить задачу и упирается в ошибку. Этот страх нарастает тем больше, чем больше кода написано, потому необходимо всегда тестировать программу. Тестирование уменьшает страх и делает программиста более уверенным в своем выборе. На деле программирование без страха должно выглядеть так: Программирование -> Повышение страха -> Тестирование -> Понижение страха -> Программирование (согласно книге первым идет написание теста, но я не стал усложнять).
Другими словами человек станет настоящим тестировщиком когда поймет, что страх перед ошибками можно побороть через тестирование.
Вы немного не с того края зашли, интересует тестирование для тестировщика, а не программиста.
Тестирование, как программирование проверки качества программирования эффективно, только если программисты софта и теста разные люди.
Иначе мозг, особенно изобретательный и с хорошей памятью, старательно обходит узкие места при написании тестов.
А вообще практик море. Мне больше для работы подходит способ «от API». Пока до мелочей не распишешь все спецификации вызовов, разрисуешь UMLки, базы данных и т.д. к программированию можно не прикасаться даже. Детализация нужна примерно до уровня «одна страничка кода на модуль». Потом конечно получается быстро, надежно, эффективно, понятно, но… безумно скучно.
Поэтому это способ больше для работы, а не для души. Для души — безумно кривые, но интересные программки — самое оно. Там вообще можно не то что тестами, а даже спецификациями не заморачиваться ))).
Иначе мозг, особенно изобретательный и с хорошей памятью, старательно обходит узкие места при написании тестов.
А вообще практик море. Мне больше для работы подходит способ «от API». Пока до мелочей не распишешь все спецификации вызовов, разрисуешь UMLки, базы данных и т.д. к программированию можно не прикасаться даже. Детализация нужна примерно до уровня «одна страничка кода на модуль». Потом конечно получается быстро, надежно, эффективно, понятно, но… безумно скучно.
Поэтому это способ больше для работы, а не для души. Для души — безумно кривые, но интересные программки — самое оно. Там вообще можно не то что тестами, а даже спецификациями не заморачиваться ))).
Зверя в студентах не будил. Сам учился на примерах.
Наиболее сильные примеры — публикации хакеров. Замечание описано в три предложения. Поначалу каждое слово незнакомо. И надо понять ход мысли человека, который нашел этот дефект. Если научиться так мыслить, то на тестируемую систему уже смотришь иначе.
Красивая визуализация процесса есть в сериале про Да Винчи. Тут ведь также получается. Смотришь на сайт, уже телепатишь какие технологии в нём используются, что на стороне сервера, на стыках каких модулей есть ошибки.
Также пересмотр замечаний на работе. Использую «тематический» пересмотр. Просматриваю замечания и пожелания, в поисках замечаний по защищённости, например, или по удобству использования. Просмотр, указание тегов или категорий, поиск дублей. Вроде бы, это рутина, но это помогает. Пересмотр можно делать и без тематики. Посмотреть замечания за последние несколько месяцев, расширить представление о качестве продукта и почерпнуть изобретательные способы. Наиболее простые и красивые из изобретательных способов поиска замечаний (хаки), видно сразу.
Наиболее сильные примеры — публикации хакеров. Замечание описано в три предложения. Поначалу каждое слово незнакомо. И надо понять ход мысли человека, который нашел этот дефект. Если научиться так мыслить, то на тестируемую систему уже смотришь иначе.
Красивая визуализация процесса есть в сериале про Да Винчи. Тут ведь также получается. Смотришь на сайт, уже телепатишь какие технологии в нём используются, что на стороне сервера, на стыках каких модулей есть ошибки.
Также пересмотр замечаний на работе. Использую «тематический» пересмотр. Просматриваю замечания и пожелания, в поисках замечаний по защищённости, например, или по удобству использования. Просмотр, указание тегов или категорий, поиск дублей. Вроде бы, это рутина, но это помогает. Пересмотр можно делать и без тематики. Посмотреть замечания за последние несколько месяцев, расширить представление о качестве продукта и почерпнуть изобретательные способы. Наиболее простые и красивые из изобретательных способов поиска замечаний (хаки), видно сразу.
Fuzzy testing вы отнесли в «исследовательское»?
Да. Тестирование защищённости почти всегда исследовательское или специализированное (на моей практике). Это будет тестирование защищённости, автоматизированное, негативное. А дальше по ситуации.
Если ваш уровень знаний превышает возможности фаззера, и это инструмент который удобно лежит в руке, а не чёрный ящик, то тестирование будет исследовательским. Особенно, если вы дописываете фаззер под конкретную задачу, тут все признаки исследования. Если же тестирование выполнять, как запуск фаззера на определённом наборе правил, то оно скорее будет специализированным, ведь момент исследования уже пропадает.
Для тестирования защищённости по тестам только-только приспособил ASVS и Testing Guide, рекомендую.
Если ваш уровень знаний превышает возможности фаззера, и это инструмент который удобно лежит в руке, а не чёрный ящик, то тестирование будет исследовательским. Особенно, если вы дописываете фаззер под конкретную задачу, тут все признаки исследования. Если же тестирование выполнять, как запуск фаззера на определённом наборе правил, то оно скорее будет специализированным, ведь момент исследования уже пропадает.
Для тестирования защищённости по тестам только-только приспособил ASVS и Testing Guide, рекомендую.
Карта несомненно заслуживает внимания. Но ни в статье ни на гитхабе нет ни слова про лицензию. Еще не определились?
Указал лицензию Attribution CC BY Version 4.0 в описании проекта.
Примерное описание на русском языке можно прочитать в статье http://licenseit.ru/wiki/index.php/Creative_Commons_Licenses.
Примерное описание на русском языке можно прочитать в статье http://licenseit.ru/wiki/index.php/Creative_Commons_Licenses.
В таких курсах обычно всегда есть только техника и нет психологии. Выше уже спросили про это.
Технике научиться не так уж трудно, к тому же, редкому тестировщику реально понадобится вся эта прорва умений от белоящичного анализа кода до тестирования безопасности.
А вот психология — это то самое, что и будет отличать хорошего тестировщика от манкикликера.
Хороший должен обладать:
— Мотивация
— Честность
Ну и массой других качеств (настойчивость, изобретательность и т.д.), но без вышеперечисленных они бесполезны. Без оныъ быть тестировщиком — безнадежное занятие. Такой человек будет способен только проходить тесты написанные кем-то другим (максимум писать какие-то очевидные тесты) и не более.
И курс был бы куда полезнее, если бы такие качества каким-то образом там прививались. Правда, увы, но я не знаю, как этого можно достичь.
Технике научиться не так уж трудно, к тому же, редкому тестировщику реально понадобится вся эта прорва умений от белоящичного анализа кода до тестирования безопасности.
А вот психология — это то самое, что и будет отличать хорошего тестировщика от манкикликера.
Хороший должен обладать:
— Мотивация
— Честность
Ну и массой других качеств (настойчивость, изобретательность и т.д.), но без вышеперечисленных они бесполезны. Без оныъ быть тестировщиком — безнадежное занятие. Такой человек будет способен только проходить тесты написанные кем-то другим (максимум писать какие-то очевидные тесты) и не более.
И курс был бы куда полезнее, если бы такие качества каким-то образом там прививались. Правда, увы, но я не знаю, как этого можно достичь.
От лица тестировщиков, считающих себя хорошими — спасибо.
Есть мнение, что одно из главных качеств тестировщика — это чувство юмора. Подробнее можно прочитать в интервью с моей коллегой Асиёй: День тестировщика 2014: поздравления от Ижайти.
И чтобы быть энергичным, ищущим неизведанное, надо наравне с психологией подтягивать и физику. Зайдите в такой отдел тестирования, который считаете хорошим. Наверняка, увидите крепких ребят и очаровательных девушек. Круг их спортивных интересов различный. Нужные качества прививаются естественным образом.
Есть мнение, что одно из главных качеств тестировщика — это чувство юмора. Подробнее можно прочитать в интервью с моей коллегой Асиёй: День тестировщика 2014: поздравления от Ижайти.
И чтобы быть энергичным, ищущим неизведанное, надо наравне с психологией подтягивать и физику. Зайдите в такой отдел тестирования, который считаете хорошим. Наверняка, увидите крепких ребят и очаровательных девушек. Круг их спортивных интересов различный. Нужные качества прививаются естественным образом.
Однажды я услышал, как одна девушка-тестировщица с восторгом рассказывала двум другим девушкам, как она прочитала «Вы наверное шутите, мистер Фейнман». Так что конечно, вы правы, на счет чувства юмора :)
Чтобы избежать разночтения отмечу, под физикой имел в виду физическую подготовку. Занятия спортом делают человека спокойным, уверенным и упрямым.
Также знаю девушку, которая «прямо растекается по стулу», когда читает байки из «Физики шутят», «Математики тоже шутят»,…
Чувство юмора можно привнести в преподавание, начиная рассказ с хорошей байки. Байки в преподавании очень важны. К счастью, их не всегда надо выдумывать. Ведь уже случилось столько курьёзных историй из-за багов. Некоторые байки считаю выдуманными, особенно по части защищённости и информационной войны; когда ищешь первоисточник, выясняется, что история записана со слов отставного генерала, которую он услышал от своего приятеля. И, вроде, можно рассказать об упавшей ракете или лопнувшем нефтепроводе, но с тем же успехом можно начать рассказ так: «Итак. Представьте ...», — и дальше понеслась фантазия.
Также знаю девушку, которая «прямо растекается по стулу», когда читает байки из «Физики шутят», «Математики тоже шутят»,…
— Как измерить силушку богатырскую?
— Нужно умножить массушку на ускореньице!
Чувство юмора можно привнести в преподавание, начиная рассказ с хорошей байки. Байки в преподавании очень важны. К счастью, их не всегда надо выдумывать. Ведь уже случилось столько курьёзных историй из-за багов. Некоторые байки считаю выдуманными, особенно по части защищённости и информационной войны; когда ищешь первоисточник, выясняется, что история записана со слов отставного генерала, которую он услышал от своего приятеля. И, вроде, можно рассказать об упавшей ракете или лопнувшем нефтепроводе, но с тем же успехом можно начать рассказ так: «Итак. Представьте ...», — и дальше понеслась фантазия.
Айтишники (не только тестировщики, а вообще в целом) в этом смысле имеют преимущество. Во-первых, в большинстве своем они зарабатывают больше, чем окружающие их люди. Во-вторых, они в целом более интеллектуально развитые, нежели окружающие (не умнее, подчеркиваю. А интеллектуальнее). И наконец, в-третьих, работа сидячая.
Все три причины вместе складываются в то, что достаточно большая часть айтишников понимают, что какой-никакой спорт обязан быть.
Я сам социальный танцор (аргентинское танго), танцую для удовольствия, а не как спорт, но при этом, какие-то нагрузки, разумеется, все равно присутствуют. Так вот, я как-то подсчитал на очередном выездном фестивале, что треть присутствующих так или иначе айтишники.
Все три причины вместе складываются в то, что достаточно большая часть айтишников понимают, что какой-никакой спорт обязан быть.
Я сам социальный танцор (аргентинское танго), танцую для удовольствия, а не как спорт, но при этом, какие-то нагрузки, разумеется, все равно присутствуют. Так вот, я как-то подсчитал на очередном выездном фестивале, что треть присутствующих так или иначе айтишники.
Вы изучали уже существующие курсы по тестированию или создавали курс полностью самостоятельно?
Несколько замечаний.
По целям — нефункциональное тестирование может проводиться в контексте каждого атрибута качества. Навскидку, вы забыли проверить продукт с целью выявления следующих его свойств:
— доступность, соответствие стандартам, поддерживаемость, тестируемость
По степени автоматизации правильно было бы сказать: ручное, автоматизированное, автоматическое. Слово «полуавтоматизированное» не несет никакого смысла.
Упомянутый вами Канер в его классификации «по исполнителям» выделяет больше 2 пунктов (альфа и бета). Пользовательское, экспертное как минимум.
В схеме совсем отсутствует популярная классификация по способу оценки результатов теста. Также некуда воткнуть тестирование на основе рисков, тестирование требований и спецификаций.
Тем не менее, вы проделали большой объем работы и сам подход мне понравился. Ставлю плюс.
Несколько замечаний.
По целям — нефункциональное тестирование может проводиться в контексте каждого атрибута качества. Навскидку, вы забыли проверить продукт с целью выявления следующих его свойств:
— доступность, соответствие стандартам, поддерживаемость, тестируемость
По степени автоматизации правильно было бы сказать: ручное, автоматизированное, автоматическое. Слово «полуавтоматизированное» не несет никакого смысла.
Упомянутый вами Канер в его классификации «по исполнителям» выделяет больше 2 пунктов (альфа и бета). Пользовательское, экспертное как минимум.
В схеме совсем отсутствует популярная классификация по способу оценки результатов теста. Также некуда воткнуть тестирование на основе рисков, тестирование требований и спецификаций.
Тем не менее, вы проделали большой объем работы и сам подход мне понравился. Ставлю плюс.
...del
Sign up to leave a comment.
Классификация видов тестирования