Ожидаемые результаты и способы определения их результативности.
Предметные результаты должны быть соотнесены с обучающими задачами и сформулированы в соответствии с требованиями к знаниям и умениям, приобретенными учащимся в процессе каждого года обучения по программе.
Личностные результаты следует соотнести с воспитательными задачами и перечислить качества личности, которые могут развиваться у учащихся в ходе занятий.
Метапредметные результаты соотносятся с развивающими задачами.
Личностные результатыотражаются в индивидуальных качественных свойствах учащихся, которые они должны приобрести в процессе освоения учебного предмета.
У обучающихся будут сформированы:
— потребность сотрудничества со сверстниками, доброжелательное отношение к сверстникам, бесконфликтное поведение, стремление прислушиваться к мнению других;
— нравственная позиция (внутренняя мотивация поведения обучающегося, способного к самоконтролю и имеющего чувство личного достоинства, а также ответственно относящегося к организации театральной деятельности)
— толерантность (разновозрастное сотрудничество на основе общего коллективного творчества).
Метапредметные результатыхарактеризуют уровень сформированности универсальных способностей учащихся, проявляющихся в познавательной и практической творческой деятельности.
У обучающихся сформированы действия:
— понимать и принимать учебную задачу, сформулированную педагогом;
— планировать свои действия на отдельных этапах музееведческой работы;
— осуществлять контроль, коррекцию и оценку результатов своей деятельности;
— анализировать причины успеха/неуспеха;
— пользоваться приѐмами анализа и синтеза при чтении и просмотре видеозаписей;
— понимать и применять полученную информацию при выполнении заданий;
— проявлять индивидуальные творческие способности при составлении текста экскурсии.
У обучающихся сформированы действия:
— включаться в диалог, в коллективное обсуждение, проявлять инициативу и активность;
— работать в группе, управлять поведением партнера;
— обращаться за помощью;
— формулировать свои затруднения;
— предлагать помощь и сотрудничество;
— договариваться о распределении функций в совместной деятельности, приходить к общему решению;
— формулировать собственное мнение и позицию;
— умению выражать разнообразные эмоциональные состояния (грусть, радость, злость, удивление, восхищение).
Предметные результатыхарактеризуют опыт учащихся в художественно-творческой деятельности, который приобретается и закрепляется в процессе освоения учебного предмета.
Обучающиеся будут знать:
— основные термины, применяемые в музейном деле;
— историю музейного дела;
— основы музееведческой деятельности. Обучающие научатся:
— методике проведения поисково-собирательской работы;
— методике проведения научно-исследовательской работы;
— методике подготовки и проведения экскурсий.
Способы определения результативности
В данном подразделе следует указать методы отслеживания (диагностики) успешности овладения учащимися содержанием программы.
Возможно использование следующих методов отслеживания результативности:
1. Педагогическое наблюдение.
2. Педагогический анализ результатов анкетирования, тестирования, зачѐтов, взаимозачѐтов, опросов, выполнения учащимися диагностических заданий, участия обучающихся в мероприятиях (концертах, викторинах, соревнованиях, спектаклях), защиты проектов, решения задач поискового характера, активности обучающихся на занятиях и т.п.
3. Мониторинг. Для отслеживания результативности можно использовать
| Педагогический мониторинг | Мониторинг образовательной деятельности детей |
| контрольные задания и тесты | самооценка обучающегося |
| диагностика личностного роста и продвижения | ведение зачетных книжек |
| анкетирование | ведение творческого дневника обучающегося |
| педагогические отзывы | оформление листов индивидуального образовательного маршрута |
| ведение журнала учета или педагогического дневника | ведение летописи |
| введение оценочной системы | оформление фотоотчѐтов |
Виды контроля
| Время проведения | Цель проведения | Формы контроля |
| Начальный или входной контроль | ||
| В начале учебного года | Определение уровня развития детей, их творческих способностей | Беседа, опрос, тестирование, анкетирование |
| Текущий контроль | ||
| В течение всего | Определение степени усвоения | Педагогическое наблюдение, опрос, |
| учебного года | обучающимися учебного материала. | контрольное занятие, самостоятельная работа |
| Определение готовности детей к | ||
| восприятию нового материала. Повышение | ||
| ответственности и заинтересованности | ||
| воспитанников в обучении. Выявление | ||
| детей, отстающих и опережающих | ||
| обучение. Подбор наиболее эффективных | ||
| методов и средств обучения. | ||
| Промежуточный или рубежный контроль | ||
| По окончании изучения | Определение степени усвоения | Выставка, конкурс, концерт, фестиваль, |
| темы или раздела. В | обучающимися учебного материала. | праздник, соревнование, творческая работа, |
| конце месяца, | Определение результатов обучения. | опрос, контрольное занятие, зачѐт, открытое |
| полугодия. | занятие, олимпиада, самостоятельная работа, | |
| защита рефератов, презентация творческих | ||
| работ, демонстрация моделей, тестирование, | ||
| анкетирование | ||
| В конце учебного года или курса обучения | ||
| В конце учебного года | Определение изменения уровня развития | Выставка, конкурс, фестиваль, праздник, |
| или курса обучения | детей, их творческих способностей. | концерт, соревнование, творческая работа, |
| Определение результатов обучения. | презентация творческих работ, демонстрация | |
| Ориентирование обучающихся на | моделей, опрос, контрольное занятие, зачет, | |
| дальнейшее (в том числе самостоятельное) | открытое занятие, экзамен, защита рефератов, | |
| обучение. Получение сведений для | взаимозачет, игра-испытание, переводные и | |
| совершенствования образовательной | итоговые занятия, эссе, коллективная | |
| программы и методов обучения. | рефлексия, отзыв, коллективный анализ работ, | |
| самоанализ, тестирование, анкетирование и | ||
| др. |
Формы подведения итогов реализациидополнительной общеобразовательной общеразвивающей программы.
Некоторые формы подведения итогов – например:опрос, зачет, экзамен, олимпиада, игра-испытание, взаимозачет, эссе контрольное занятие, концерт, самостоятельная работа, выставка, защита рефератов, конкурс, открытое занятие для родителей, соревнование, презентация творческих работ, самоанализ, коллективный анализ работ, отзыв, коллективная рефлексия и др.
Например:
Форма подведения итогов реализации дополнительной общеобразовательной общеразвивающей программы –итоговая выставка детских работ. Это мероприятие является контрольным и служит показателем освоения детьми программы, а также сплачивают детский коллектив.
Учебный план
| № п/п | Наименование темы | Количество часов | Форма аттестации/ контроля | |
| Всего | Теория | Практика | ||
| 1. | Вводное занятие | 0,5 | 0,5 | Опрос |
| 2. | Общая физическая подготовка | 0,5 | 2,5 | Игра, соревнование |
| Специальная физическая подготовка | 0,5 | 1,5 | Соревнование, игра | |
| Итого: | 1,5 | 4,5 |
Содержание учебного плана
Тема 3. Специальная физическая подготовка.
Теория: Направленность специальной физической подготовки. Специальная физическая подготовка как основа развития специальных физических качеств, способностей, двигательных функций спортсмена и повышения спортивной работоспособности.
1. Упражнения для развития быстроты.
2. Упражнения для развития ловкости.
3. Упражнения для развития силы.
4. Упражнения для развития специальной выносливости.
5. Упражнения для развития гибкости.
6. Базовые элементы: боевая стойка, передвижения, дистанция, прямые одиночные удары и защиты от них.
Источник
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Продолжу хвастаться статусом книги.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова
Клара Янова – ответственная тестировщица, которая изучает, практикует и пропагандирует Rapid Software Testing. Недавно она написала на LinkedIn:
«Я могу ОЖИДАТЬ, что что-то произойдет. Но это необязательно значит, что Я ХОЧУ, чтобы это произошло. Я даже могу хотеть, чтобы это произошло, но то, что оно не происходит, вовсе не означает автоматом, что тут есть какая-то проблема.
Смысл заметки: пожалуйста, давайте покончим с «ожидаемыми результатами» в баг-репортах!»
В ответ Дерек Чарльз спросил:
«Но как еще ты сообщишь разработчику или команде, что ДОЛЖНО происходить? Думаю, что ожидаемые результаты необходимы, особенно если в ходе тестирования обнаружен регресс».
«Я предлагаю описывать поведение, которое кажется тестировщику проблематичным, и объяснять, ПОЧЕМУ это может быть проблемой для кого-то. Причины, почему поведение воспринимается как баг – вот что самое важное».
Именно так. Клара говорит в терминах проблем и оракулов – способов, благодаря которым мы распознаем проблемы, когда сталкиваемся с ними в ходе тестирования.
Есть закавыка с «тем, что должно произойти»: в разработке ПО не всегда ясно, что должно произойти. Более того (и важнее) – тестировщики не руководят проектом или бизнесом, и не диктуют, что должно происходить.
К примеру, в ходе тестирования я могу наткнуться на что-то смущающее меня в продукте – или удивляющее, или неверное. Спецификация говорит о желаемом поведении одно; разработчик утверждает, что спека устарела, и противоречит ей; продакт-оунер подтверждает, что спека устарела. Но также сообщает, что интерпретация желаемого поведения в исполнении разработчика – это не то, чего хочет она. А затем я сверяюсь с RFC, и оказывается, что интерпретация продакт-оунера противоречит тому, что RFC называет подходящим поведением.
К счастью, мне не нужно решать, и я не обязан говорить, что должно произойти. Моя задача как тестировщика – сообщить о явном несоответствии между продуктом и предположительно желаемыми вещами, или между продуктом и чьим-то явно выраженным желанием или требованием. В вышеописанном случае я дал продакт-оунеру знать о расхождении между ее интерпретацией и стандартом, и дальнейшее решение, чего она и бизнес хотят от продукта, за ней.
Даже если у меня есть какие-то ожидания, они могут быть ошибочными, а я могу заблуждаться в своем понимании того, как должно работать. К примеру, она может решить, что наш продукт не будет поддерживать этот стандарт. Она может указать мне на то, что стандарт, к которому я апеллирую, заменен более поздним. В любом случае то, как должно работать, решается не мной, а теми, кто всем рулит. Им за это деньги платят. И это хорошо, а не плохо.
Но я бы все равно хотел ответить на вопрос Дерека: как нам, тестировщикам, сообщать о проблеме, не ссылаясь на «ожидаемые результаты»?
- Вместо того, чтобы говорить «ожидаемый результат» и бросать все вот так, мы можем сказать «несоответствие спецификации».
Несоответствие спецификации – это особый случай более общего способа распознавания и описания проблемы: несоответствие заявлениям. «Несоответствие заявлениям» – это оракул-эвристика (эвристика – это ненадежный способ решения проблемы; оракул – это отдельный вид эвристики, который ненадежно помогает вам решить вопрос идентификации и описания бага). Когда продукт не соответствует заявлению, сделанному кем-то значимым, то это, скорее всего, проблема – или с продуктом, или с заявлением. Но не я, не тестировщик, решаю, в чем именно проблема.
Спецификация – это особая форма заявления о том, как работает продукт, или как он должен работать. Заявления могут делаться на дизайн-сессиях, планировочных митингах, при парном программировании, переговорах в коридоре, на тренингах… Заявления можно встретить в файлах справки, маркетинговых материалах, процессных диаграммах, справочных таблицах, руководствах пользователя, набросках на доске, UML-диаграммах. Заявления могут также содержаться в коде автоматизированной проверки, когда автор создает код, сравнивающий результат работы продукта с ожидаемым и предположительно желаемым результатом. Способность распознавать множество источников заявлений и несоответствий им делает нас лучше как тестировщиков.
Когда вы ссылаетесь на релевантное заявление, сообщая «не соответствует заявлению» (и природа заявления и его автор идентифицированы), вам не нужно говорить об «ожидаемом результате».
- Вместо «ожидаемого результата» вы можете сказать «не соответствует тому, как раньше работало».
Несоответствие истории – это оракул-эвристика. После внесения изменений продукт может получить новый баг. С другой стороны, продукт мог раньше работать криво, а теперь с ним все хорошо (это пример того, как оракул может увести нас не в ту степь или конфликтовать с другим оракулом, поэтому важно идентифицировать оракулы, которыми мы пользуемся в баг-репортах). Если вы (или окружающие) не знаете, почему было внесено желательное изменение – это другая проблема, но тем не менее проблема.
В любом случае, если вы говорите «не соответствует тому, как раньше работало» (и описываете это в терминах проблемы), вам не нужно говорить об «ожидаемом результате».
- Вместо «ожидаемого результата» вы можете сказать «не соответствует самому продукту».
Несоответствие самому себе – это оракул-эвристика. Это может принимать различные формы: продукт возвращает разные результаты при разных запусках; продукт в одной части демонстрирует чистый, бесшовный интерфейс, а в другой – раздражающий и запутывающий. В одной части продукта выводится точный результат, а в другой – неточный; один компонент логирует результаты в формате, отличающемся от логов другого компонента, и это затрудняет анализ…
Это несоответствие может быть нежелательным (из-за проблемы надежности), или совершенно нормальным (веб-страница новостного сайта должна меняться ежедневно), или оно может быть желательным и нежелательным по причинам, о которых вы не знаете (так как, как и я, вы не можете знать все).
В целом люди предпочитают вещи, ведущие себя согласованно. Тривиальный пример из Microsoft Office (Office 365): для поиска текста в Word команда клавиатуры – Ctrl+F. В Outlook, части того же самого пакета, Ctrl+F стартует функцию пересылки сообщения, а поиск запускается через F4. Если бы Outlook и Word одновременно разрабатывались одной и той же командой, это было бы, скорее всего, определено как баг и исправлено. В результате программный менеджер пакета Office решил, что соответствие истории продукта важнее, чем несоответствие продукта самому себе, и нам приходится с этим жить. Ну что ж.
В любом случае, когда вы говорите «не соответствует какому-то аспекту того же самого продукта» (и идентифицируете специфику несоответствия), вам не нужно говорить об «ожидаемых результатах»).
- Вместо «ожидаемого результата» вы можете сказать «не соответствует похожему продукту» (и указать продукт и причину несоответствия).
Несоответствие похожему продукту – это оракул-эвристика. Любой продукт (то, что кто-то произвел), дающий релевантные точки сравнения – это по определению похожий продукт. Это, конечно же, включает в себя продукты-конкуренты: Microsoft Word и Google Docs в этом смысле похожие продукты. Microsoft Word и WordPad – тоже похожие продукты, у них много общих функций. Если Word не может открыть RFT-файл, сделанный в WordPad, есть причины подозревать проблему в одном или другом из них. Если WordPad правильно печатает RFT, а Word – нет, есть повод подозревать проблему в Word/
Сравнима ли Unix-программа wc (подсчет слов) с Microsoft Word? Все, что делает wc – это считает слова в текстовых файлах, поэтому нет, хотя… У Word есть функция подсчета слов. Если подсчет слов Word в текстовом файле необъяснимо отличается от числа в wc, есть причина подозревать проблему в том или другом продукте.
Тест-инструменты и наборы автоматизированных проверок – это тоже сравнимые продукты. Если результат работы продукта не соответствует определенным желаемым результатам, выданным вашим тест-инструментом, или обрабатываемым для достижения этих результатов данным – есть причина подозревать проблему.
В любом случае, если вы говорите «не соответствует похожему продукту» и идентифицировали продукт и основания для сравнения, вам не нужно говорить об «ожидаемом результате».
Это всего лишь несколько примеров. Преподавая Rapid Software Testing, мы даем набор оракулов-эвристик, которые идентифицируют принципы желаемого (и нежелательного) соответствия (и несоответствия) для идентификации багов – подробнее можно узнать здесь.
Джеймс Бах недавно вывел еще один принцип, который можно применить к багам, но который, с моей точки зрения, больше применим к запросам на улучшение: мы хотим, чтобы продукт соответствовал приемлемому качеству – то есть был не просто хорош, а настолько хорош, насколько это возможно.
Почему это важно? По ряду причин, как думается мне.
Во-первых, «ожидаемый результат» прямо-таки вымогает вопрос, откуда взялись ожидания. Это просто посредник для чего-то более конкретного. Почему бы не перейти сразу к делу и не сказать об этом, оставаясь профессионалом? Потому что…
Во-вторых, четкое объяснение, откуда пришли ожидания, бережет время и фокусирует разговор на (не)желательных (не)соответствиях, которые имеют значение, когда разработчики и продакт-оунеры решают, баг ли это и надо ли это исправлять. Это также помогает фокусировать починку на нужном заявлении (к примеру, если продукт в порядке, а спека – нет, это намек на исправление спеки).
В-третьих, это помогает помнить, что наша задача как тестировщиков – не подтверждать, что продукт работает «как ожидается», а спрашивать «есть ли в этом проблема?» Продукт может соответствовать ожиданиям и вне зависимости от этого кишеть жуткими проблемами. Наша работа – искать, находить и описывать несоответствия и проблемы, которые имеют значение, прежде чем не стало слишком поздно.
В-четвертых, разговор в терминах оракулов вместо «ожидаемых результатов» помогает избежать патронизирования, снисходительности, потерь времени, и прочих элементов баг-репорта, которые заставляют разработчиков оскорбляться или закатывать глаза.
Источник
