Короткий ответ — дать возможность студентам учиться самостоятельно и сделать это неизбежным.
Более подробно рассмотрим педагогический эксперимент, проведенный в Новосибирском государственном университете. В НГУ я 6 лет вел спецкурс по тестированию программного обеспечения на принципах смешанного и дуального обучения. Мы начали с группы в 8 человек, а в последний год на курс записались 52 человека из 100 студентов потока, включая тех, кто уже работал в тестировщиками ПО.
В статье раскрыта организация образовательного процесса, и вытекающие из него педагогические и управленческие вопросы.
От форсайтов к кадровому вопросу
В 2010 году мы, как проектная группа “Метавер”, провели первый форсайт “Образование”, из которого потом целое форсайт-движение возникло https://asi.ru/news/2475/. Примерно через год мне стало интересно перейти от форсайта как инструмента генерации гипотез к практике трансформации образования, благо традиции Академгородка Новосибирска этому способствовали, поэтому я переехал из Москвы в Сибирь и запустил совместно с Академпарком цепочку экспериментов. Одним из них был проект по подготовке тестировщиков программного обеспечения под корпоративного заказчика. Позже на основе такой подготовки мы собрали спецкурс для Новосибирского государственного университета. Для нас было важно не просто какой-то курс провести, а сделать его так, чтобы он помогал студентам использовать полученные знания и умения в реальной работе в ИТ-отрасли.
Запуск спецкурса
Спецкурс мы запустили на двух факультетах: физическом (ФФ) и информационных технологий (ФИТ). Так начался эксперимент длиною в 6 лет.
Мы тогда точно понимали, что хотим сделать, но не очень понимали как. Поэтому за основу взяли перевернутый класс в смешанном обучении. Коротко говоря, домашнее задание не после, а перед уроком. Преподаватель дает студентам материалы для ознакомления заранее, а на очных встречах разбирает вопросы, барьеры и озарения возникшие в результате изучения материалов. Такой подход приближает образовательный процесс к спринтам из agile-подхода, когда мы встречаемся зачем чтобы подытожить сделанное за неделю и спланировать следующие шаги. Теории об этом написано много, но тогда известных нам внедрений в России не было.
Дуальное образование предполагает тесное взаимодействие с работодателем, поэтому мы курс собирали вместе с руководителем отдела тестирования крупной аутсорсинговой компании Екатериной Синько, она задавала отраслевую планку, на которую мы ориентировались. Сейчас мы в IThub называем таких приглашенных отраслевых экспертов архитекторами специальности. Без них любой курс, особенно в IT, будет стремительно устаревать. Исходя из заданной планки подбирали учебный материал, в том числе онлайновый. Мы взяли курс на интуит.ру, в котором описано введение в тестирование ПО для теоритической части, и релиз Mantis как bugtracker для практики. В дальнейшем студенты сильно нарастили методическую базу, но об этом ниже.
Первый год — первые грабли
Прямой перенос из мира дефицита кадров в вузовские реалии не получился.
Я предложил студентам самостоятельно поработать с онлайн-курсом, разобраться, нарисовать mindmap. Это вызывало у них недоумение, с одной стороны, и вопросы к моей профессиональной квалификации — с другой. Потому что я старательно избегал трансляции знаний, наоборот, действовал по принципу: «Вот вам пространство и материалы — разбирайтесь, а я помогу в ответ на прямой запрос». И то, что отлично сработало на соискателях, сломалось на студентах — привыкшие к тому, что все рассказывает преподаватель, студенты-физики с большой неохотой работали с внешними источниками. “Мотивация не та, ваша честь!”
Пять лет — полет нормальный
Мы сделали выводы и на следующий семестр в 2013 году, уже со студентами ФИТа, пересобрали дизайн курса, добавив согласование мотивов и метрик образовательных результатов. Такой дизайн в дальнейшем и шлифовался год от года, и, начиная с 2015 года, на спецкурс начали записываться студенты, которые уже работали тестировщиками: для них это была хорошая возможность повысить квалификацию. Тем самым нам удалось выдержать первоначальный ориентир, заданный потребностями рынка.
За счет чего этого удалось добиться?
Согласование целей
Во-первых, в начале каждого семестра мы согласовывали, зачем студенты вообще записываются на этот курс.
И в первый год, когда их записалось 8, и в последующие, мы с каждым проговорили и зафиксировали, что он хочет получить в конце курса. Ведь это курс по выбору, значит для чего-то студенты выбрали именно его.
Для этого студентам нужно было ответить на 7 нехитрых вопросов:
А затем на первом занятии мы проводили очень простой формат:
- кто угодно озвучивает свою цель, записывает её на доске и подписывается.
- Повторяться нельзя, но можно помогать другому сформулировать точнее.
- Высказаться должны все.
Мы так знакомились и друг с другом и с целями.
Обычно первые 5-7 высказываний это “баяны”, когда группа выдает социально ожидаемые ответы. Но в дальнейшем ответы становятся глубже, начиная с того, чтобы быть востребованным специалистом, заканчивая тем, что придется работать с тестировщиками, хочется понимать, на каком языке с ними разговаривать. Мы со студентами могли сделать срез по этим ответам и выдвинуть общие критерии, к которым потом можно было относиться. Такой-то человек сказал, что вот это ему нужно, и это зафиксировано. Такой подход в том числе позволял синхронизировать ожидания. В случае, если студенты не могли сформулировать цель: всё в порядке, говорил я им, значит, вам просто не сюда. Курсов по выбору много, запишитесь на другой — это помогало.
Зачастую, особенно на больших группах 20-30 человек, прояснение целей занимало целую пару, чтобы договориться до того, зачем они реально сюда пришли и, соответственно, во что собираются вложить свое время.
Во-вторых, мы должны были договориться до метрик, в соответствии с которыми студенты поймут, как будет достигнут мотивационный ориентир, который из этих ответов на "зачем” вытекает.
Метрики достижения успеха
Метрики ЗУН
Какие метрики мы определяли? Знания, умения, навыки, компетенция, квалификация. В последние три года студенты меня убедили и мы ввели ещё одну метрику: “командная работа”.
Что скрывается за этими словами? Чтобы не уходить в трактовку, кто что под этим подразумевает и завязнуть в софизмах, мы договорились только о том, как это измерить.
Знание
Подтверждением знаний является либо результат теста, либо, в конечном счете, сертификат онлайн-курса. Тот самый курс, который я использовал еще при первой попытке, мы переиспользовали и сказали, что это слагаемое, которое является ликбезом по тестированию. С него мы начинаем. И важным условием является то, что по этому курсу студенты получат сертификат и предъявят его как основание для зачёта знаний.
Конечно, одним курсом всё не ограничилось. Студенты становились содизайнерами этого курса, предлагали дополнительную литературу, онлайн-источники. Мы обсуждали это с Екатериной и расширяли пул методических материалов. В дальнейшем это еще сыграет свою роль, но об этом позже. По всем новым источникам я просил составить mindmap. У такого формата сразу три преимущества:
- сразу видно насколько глубоко студент проработал материал;
- в mindmap видно, что он упустил или раскрыл недостаточно;
- каждый mindmap уникальный, а значит, его нельзя списать.
Умение
Как зафиксировать умение? Это мы должны убедиться, что кто-то что-то сумел сделать. И для этого в IT есть понятная культура логирования и анализа логов. То есть, если соответствующий пользователь в соответствующей системе совершил какие-то действия, мы эти действия можем зафиксировать в лог и потом поднять, проанализировать и тем самым подтвердить, что такой-то пользователь такие действия сделать сумел. Для этого уже на второй год мы перебрались на trello.
Навык
Навык фиксируется подтверждением того, что студент не просто сумел что-то сделать, а делал это многократно, хорошо и быстро. То есть многократное повторение успешного действия служит для нас метрикой формирования навыка. Очевидным образом выводится из того же лога: количество текст-кейсов, баг-репортов и т.п.
Это три метрики, которые мы довольно легко из дискуссии выводили студентами каждый раз заново.
Метрики 3К
Компетенция
Компетенция — это успешное применение знаний-умений-навыков в заданном контексте. Тем самым измерение компетенции подразумевает перебор разнообразного контекста и достижение в нём того же самого результата. В совершено разных условиях продемонстрировать умение проявлять нужное сочетание качеств. Для этого мы договорились использовать элемент деловой игры, где студентам нужно было “в шкуре тестировщика” разрешить те или иные ситуации.
Примеры ситуаций
| Название | Содержание |
|---|---|
| Но есть нюанс! | Спецификация ушла девелоперу на разработку и тестеру на написание тесткейсов. Тестер понимает, что тесткейсы сильно зависят от реализации и после реализации девелопером возможно придется их полностью переписать. |
| Мистическое программирование | Тестер видит странное поведение системы, и не понять то ли это баг, то ли нет. Со стороны аналитика встречаешь полное равнодушие по этому вопросу. Будет ли что-то меняться далее, зависит только от тестера. |
| Press any key… Reset? | Саппорт завершил установку приложения. Тестер принимается за тестирование и видит, что: — приложение недоступно; — поставили не туда; — поставили не то. |
| Это у вас на входе барахлит | Проект состоит из 2 взаимодействующих частей. Тестер находит ошибку взаимодействия, но с какой стороны ошибка неясно. Ставит задачу на девелопера части2. Девелопер части2 говорит, что с их стороны поведение адекватное. Тестер передает задачу на девелопера части1. Девелопер части1, говорит, что у них все соответствует спецификации, и закрывает задачу как invalid. |
| Каждый ежик — агроном | В спецификации написано одно, девелопер сделал по-другому, так как: — понял её именно так; — сделать в точности по спеке невозможно; — иначе требуется слишком много времени; — по устной договоренности с проект-менеджером. |
| Кто здесь? | В описании бага ничего непонятно(в чем была проблема, как проверять...), спецификации нет, а девелопер, который делал задачу недоступен (заболел, в отпуске...). |
| Спека с дырой | Спецификация не описывает поведение системы в некоторой реально возможной ситуации. По мнению тестера, то, как работает сейчас, недопустимо. |
| Код лучше знает | В спецификации написано одно, работает по-другому, но по мнению тестера было бы здорово, если б так и надо было. Другой тестер ставит задачу на исправление. |
| Что это, Бэрримор? | Реализован некий функционал, о котором в спецификации ни слова, задача на реализацию тоже не существует. |
Откуда взялись эти разные условия, эти ситуации? Как я уже упоминал, этот курс изначально проектировался под патронажем специалистов в тестировании. Я задал им очень простой вопрос: вы, профи, поделитесь, пожалуйста, болью, вот какие ситуации за последние 5 лет в вашей профессиональной деятельности были наиболее эмоционально окрашенными, болезненными, где прям приходилось глубоко разбираться?
И такой вот набор случаев из жизни тестировщика создал колоду разнообразных ситуаций, которые нужно было проработать учащимся. Каждая ситуация описывалась некоторым количеством вводных для разных ролей: тестировщика в перовую очередь, затем разработчики, аналитики, менеджеры и т.д. — кто участвовал в реальном прототипе игровой ситуации. Студенты брали на себя эти роли и взаимодействовали, исходя из вводных.
Примеры вводных по бизнес-ролям
| Вы — аналитик. Вы долго превращали облако ожиданий клиента в конкретную спецификацию и по праву гордитесь своей работой. Она не безукоризненна с точки зрения описания, но все что в ней есть было согласовано с заказчиком. |
|---|
| Вы — руководитель проекта. Вы принимаете окончательное решение, но важно учитывать не только текущую ситуацию, но и общий контекст. Это поточный проект с этим заказчиком. Вам важно уложиться в срок, потому что следующий проект обещает быть большим и интересным. |
| Вы— тимлид тестировщиков. Недавно в компании, первый раз на таком проекте. Хотите, чтобы все прошло безукоризненно. |
| Вы — аккаунт-менеджер. И вы только что долго извинялись перед клиентом за баг, который чуть не уронил ему базу. Клятвенно обещали, что больше такого не повториться. |
| Вы — профессиональный промышленный программист. Строго выполняете поставленную в спеке задачу и требуете такой же аккуратности и дисциплины от коллег. |
| Вы — программист. Работаете в этой компании уже 4 года. Привыкли к тому, что спеки всегда неточные. Вы считаете себя ключевым специалистом, от которого зависит конкретная реализация. |
| Вы настоящий тестер — формалист, зануда, аккуратист. Благодаря этому все продукты, проходящие через вас удерживают высокую планку качества. В первую очередь благодаря тому, что вы строго придерживаетесь спецификации. |
| Вы — саппорт. Устанавливаете приложения так и туда, куда вам удобно на объеме в сотни рабочих станций. Очень озабочены безопасностью. |
После такой разыгранной сцены каждый: и участники, и зрители — отвечали на 3 вопроса:
Что ребята на сцене сделали верно в соответствии с процессами отрасли?
Что они сделали не так?
Как бы я организовал всю коммуникацию на их месте?Такой опрос тоже стал важным инструментом, он позволил вовлечёно анализировать ситуацию всем участникам. Соответственно вначале опрос проводился на бумаге, потом— через гугл-документ, который позволял собирать всё в едином пространстве.
Почему так много разговоров про метрики? Потому что все эти 4 слагаемых они в итоге носят объективный характер. Тестирование либо пройдено, либо нет. Логирование или зафиксировало активность, или нет. Кратное повторение одних и тех же артефактов: багрепортов, чек-листов, мастер планов — либо собрано, либо нет. Соответствующая ситуация прорефлексирована, анализ по ней сделан или нет. Все носит совершенно объективный характер, который позволяет это предъявить кому угодно, в том числе и за пределами университета.
И мы подбираемся к оставшимся двум метрикам. И они как раз субъективные.
Квалификация
Квалификация подтверждается оценкой игрока из индустрии, того самого руководителя отдела тестирования, с одной стороны. С другой стороны, мы вместе со студентами брали и тестировали реальные приложения, начиная от видеоигр, заканчивая яндекс.маркетом и голосовым помощником Яндекса Алисой. Соответственно, все проанализированные и найденные баги мы отправляем напрямую в компанию разработчика. Тем самым наши студенты попадали в позицию аутсорсинговой тестирующей компании. И на основе этого опыта заключение специалиста из индустрии служило подтверждением их квалификации.
Командная работа
Оценка же командной работы базировалась на мнении студентов во вкладе товарищей в их работу. В семестре студенты комментировали работу друг друга, давали разные советы, находили ошибки, помогали их исправлять. Каждый получивший комментарий отмечал, пошёл ли тот на пользу его работе или наоборот — оказался бесполезен. Так же разбирали все ответы, начиная с тестов и заканчивая анализом сценок из деловой игры. Все это собиралось в рейтинг тех, кто был наиболее полезным как для конкретного студента, так и для группы в целом.
Итого, имеем простые правила игры, которые дают нам все 6 параметров.
Как получить отлично?
И возвращаясь к тому, что в конечном счете у нас должна быть оценка, какой-то балл по итогам прохождения этого спецкурса, мы договорились, что по каждому из этих параметров можно набрать от половины балла до полутора. На зачёт нужно полбалла по всем, остальное — на повышение оценки.
Пример того, как складывается оценка студента:
| Метрика | 0,5 | 1 | 1,5 |
|---|---|---|---|
| Знания | X | X | X |
| Умения | X | ||
| Навыки | X | ||
| Компетенции | X | ||
| Квалификация | X | X | |
| Командная работа | X | X |
То есть кто-то мог глубже разбираться со знаниями, кто-то больше шлифовал навык. Все выполняли норму, но могли эту норму по любому из параметров повысить в 3 раза. Зачем? Если минимальная характеристика по 6 по полбалла дает 3, то максимальная 9. И вот из этих дополнительных 6 баллов каждый студент себе добирал 2, если он претендовал на “отлично”.
И в конечном счете это позволяло мне занять позицию: в любой момент времени, когда любой студент набирает себе пятерку, то он может сразу ее у меня получить. Не нужно дожидаться конца сессии, не нужно делать мне красивые глаза, нужно обеспечить результат в размеченном для этого пространстве. И в зависимости от того, какие «зачем» выдвигали студенты, они так себе эту индивидуальную историю и собирали. Кто-то хотел больше практики, акцентировался на навыках, умениях. Кто хотел взаимодействовать с разработчиками — на контекстах, компетенциях и квалификации. Кто-то находился в позиции саппорта и активно помогал, качая командность.
Организация очных занятий
Теоретический материал
Итак, у нас есть материал, который нужно освоить. На очных занятиях каждый студент должен хотя бы одну главу из этого онлайн-материала рассказать. Учащиеся сами выбирают, договариваются, кто какую главу рассказывает. На следующей встрече докладчики выступают. Конечно же поначалу все пытаются просто пересказывать содержание. Мол, в главе излагается вот это, вот это, вот это… Это мной тут же сворачивается: а зачем вы нам это рассказываете? Мы все читали. Я читал, студенты читали, мы договорились, что вы это освоите заранее. Поэтому давайте доклад будет строиться вокруг того, что докладчик для себя понял. То есть нужны сразу выводы, информацию-то все и так читали. И отдельно то, что докладчику показалось спорным или он не понял. И важно, что здесь они не мою лекцию обсуждают, а внешний материал. А я им помогаю в этом материале разобраться. И формулировка – у лектора вот в этой части вот какая-то такая штуковина, которая вообще, на мой, докладчика, взгляд, ересь или я, докладчик, тут туплю и в этой части разобраться не смог вот по этой причине. Это нормальная формулировка, более того, желаемая.
Следующим шагом я говорю – коллеги, а кто из тех, кто читал, разобрался? А читали вроде как все. Понятно, что на второй паре читают не все. Но в таком контексте нечитающие начинают стремительно, во-первых, читать, и это нормально. Во-вторых, понимают, что они немного на периферии, а метрики мы озвучивали. И уже к третьей паре, во второй половине сентября, студенты всё читают заранее и включаются, чтобы обсудить. Потому что это помогает им доразобраться в сложных моментах материала или еще с чем-то в курсе. Все обсуждение идет не вокруг пересказа, а вокруг либо барьеров непонимания, либо вокруг озарений – а я для себя вынес вот это, кто по этому поводу, что думает?
Еще раз о ментальных картах
Фиксацией разобранных знаний был не конспект, а mindmap. Студенты укладывали разобранную самостоятельно и на занятиях информацию в форму ментальной карты. А как я уже говорил mindmap позволяет заглянуть студента в голову и увидеть то, что у него получилось вынести, а что нет — высветить лакуны, какие-то пробелы, которые на текущий момент у студента возникли и одновременно озарения, инсайты, выводы, которые студент на основе всего этого материала сделал.
В конспекте нужно было не просто передать содержание, а отразить выводы и эти выводы обосновать содержанием. То есть почти всегда стартовая работа выглядела так – ну давайте структурируем в качестве оглавления, подоглавления, абзацы. Хорошо, а что из этого можно сделать какой вывод? Поскольку это mindmap, то он легко пересобирался уже в подвыводы. Карта принималась с итоговыми обобщающими выводами на основе этой главы методички материала. И это позволяло увидеть авторскую позицию студента. То есть это была форма рефлексии по поводу прочитанной информации. Возможность видеть, чем студент пренебрег, и позволяла с ним говорить именно про эту часть. Потому что у меня была выборка, во-первых, мое прочтение, а во-вторых, выборка десятков других студентов, которые на этот же самый источник делали свои ментальные карты. И у кого-то одна тема была практически не раскрыта, а другой, наоборот, именно на этом ставил свой акцент, строил свои выводы. И это позволяло говорить – смотрите, вот этот момент в карте у одного студента максимально развернут, давайте, он расскажет про это коллегам. И если в начале семестра мы говорили – расскажи про главу такую-то в формате вот такие выводы ты сделал, вот такие барьеры тут возникли, то здесь в этом же самом залоге, но мы уже обсуждали выводы по поводу материала. А предварительная рассылка mindmap позволяла заранее понимать повестку того, что мы будем обсуждать и кто будет про это рассказывать, а кто будет соответственно потребителем этой информации.
Экология проектного подхода
Это давало экологичный режим, где не существует отрицательного зачета. То есть всегда мы встречаемся, чтобы друг друга дополнить. Один дополняет вот этим, другой этим, и не обязательно со всем соглашаться, но мы точно обсуждаем все идеи. И это нужно за тем, чтобы успешно сделать тот проект, который мы ведем по тестированию конкретного ПО, при встрече с конкретным заказчиком. Так появлялся очень понятный ракурс рассмотрения любого материала — как мы его можем применить в нашей проектной работе, что полезного можно из этого извлечь. И подобная обратная связь от каждого из участников и формировала ту фактуру для зачета шестой компоненты командной работы. То есть человек понимал – вот эти элементы были для меня полезными, я их подсвечиваю. И тем самым оценивая пользу конкретной реплики он в том числе и взвешивал рейтинг тех, кто такую поддержку оказывал.
Перевернутое обсуждение внешнего материала позволяло довольно глубоко разбирать информацию, которая давалась заранее. В том числе это позволяло фиксировать и неудачи по тестированию знаний. Проходить тесты можно было сколько угодно раз. Более того, я всегда своим студентам рекомендовал и рекомендую вначале пройти тестирование, а потом уже с пониманием, как будут измерять, разбираться с информацией. Иногда тестирование не очень корректное, мы это тоже отдельно разбирали. Разговор про тест, как метрику оценки знаний.
Такой теоретический ликбез о тестировании ПО позволил разделить некую общую установку о том, что это такое, чем оно отличается от отладки и как вообще к этому вопросу подходить.
Отраслевая специфика
Следующий шаг — это знакомство с техническими стандартами, которые в тестирование заведены — что такое мастер тест-план, чек-листы, как оформлять баг-репорт и для чего это так делается. То есть зачем мы этим занимаемся, зачем мы этот материал изучаем. Из него очень понятно, почему у нас такие документы. Уже в этот момент возникала та самая инициатива, которую я упоминал ранее. Студенты начинали добавлять материал в рассмотрение. Мол, есть такой онлайн-курс, что-то на youtube или есть такая книжка, которую он хотел бы разобрать. В частности таким интенсивным методом мы разбирали методичку по тестированию Семена Костантиновича Черноножкина, из которой в магистратуре был целый курс собран. Методичка толковая, особенно хорошо описаны психологические установки тестирования. Но мы то, что растягивалось на целый курс в магистратуре, осваивали за 2-3 недели и брали в рассмотрение следующий материал.
Практика по тестированию
Такая работа с источниками, с курсом, с ментальными картами и т.д. позволяет договориться до некоторых общих оснований. В том числе проверить, что студенты владеют отраслевыми стандартами написания рабочих документов, мастер-планов, баг-репортов и т.д. После этого выбиралось программное обеспечение для тестирования. Это и с одной стороны — обучающий процесс, с другой — тестирование реальных продуктов. При выборе мы руководствовались тем, что А — есть прямой контакт с командой разработчиков, это нам понадобится на финальном этапе, Б — интересно потестировать, любопытно. Брали крупные продукты, как уже упоминалось, от компьютерных игр до яндекс.маркета и Алисы.
И для того, чтобы такой софт протестировать, нужно делать это командой. То есть с середины семестра мы становились проектным офисом компании, которая тестирует софт в режиме аутсорс. Кто-то пишет планы, чек-листы. Поскольку до этого мы разобрали как в принципе тестировать, кто-то брал на себя тестирование этого модуля, кто-то брал на себя системное тестирование, интеграционное и т.д. И шла активная работа.
Базовая технология и площадка — канбан в трелло. Это давало нам логирование для отслеживания и зачета по умениям. И там же складывались ссылки на материалы, которые служили подтверждением навыков. В результате, наши встречи становились уже окончательно спринтами, где мы разбирали, что сделано за неделю, что нужно сделать на следующей, какие трудности мешают нам это сделать.
Примерно месяц такой работы давал большую фактуру артефактов, например, баг-репортов. По его итогам было организовано спринт-ревью, собственно, с разработчиками софта. В ситуации, когда это были новосибирские разработчики, они просто приходили к нам на занятие. В ситуации москвичей был созвон. И это, с одной стороны, конечно же сильно работало на мотивацию студентов. Группа на тот момент уже, считай, становилась проектной. А с другой стороны, ревью с профессионалами позволяло соотносить текущую ситуацию с тем самым первоначальным мотивационным ориентиром, который мы в ответе на вопрос “зачем” формулировали. И внутри этого пространства каждый участник как раз-таки и набирал себе баллы именно там, где ему хотелось. На основе артефактов, которые создавала группа, и делался вывод, с одной стороны, о квалификации этой работы, а в режиме — да спасибо, этот баг мы тоже зафиксили, о, а вот этого бага мы не знали, спасибо за то, что нам подсветили, а можно ли еще вот этот момент потестировать. В соответствии с этим финализировался семестр и там же проигрывалась та колода ситуаций, о которых я уже говорил.
В результате с самого начала все студенты понимали, что им нужно сделать, чтобы получить отлично, что можно не делать, если устраивает. И каждый спринт мы в том числе фиксировали вот эту дельту в баллах. То есть люди обосновывали свой еженедельный прирост.
Вопросы педагогики
Что делать с неуспевающими?
Для тех, кто страдал студенческой болезнью и появлялся в середине семестра, была уже созданная инфраструктура. Вот, пожалуйста, все материалы, вот, разбирайся. Вот коллеги, которые уже это сделали, к ним можно приходить за советом. Для них это будет с одной стороны зачет, а с другой стороны, проектная работа всегда означает, что ещё над чем-то можно поработать. Студенты могли ставить задачи друг другу, в первую очередь, не успевающим. Вот, мол, давай тогда еще вот этот модуль потестируй. Или вот этот статус-репорт оформи. Или еще что-то. И человек включался в середине семестра, он понимал, над чем ему нужно работать и насколько ему это полезно. И в конечной ведомости очень прозрачным способом, обсужденным на первом занятии, выставлялись соответствующие отметки. Кто-то вышел на удовлетворительно и ему этого хватает. Кто-то хочет больше и понимает, что для этого нужно сделать. То есть не стояла задача понравиться преподавателю как персоне, что-то ему доказать. Стояла задача обосновать результат своего труда по известным критериям.
Соотнесение с отраслью
И мы соответственно могли делать выводы методом сравнения как с группой в целом, так и с уровнем квалификации в отрасли, ведь у нас была обратная связь от технологической компании.
Мы понимали, сколько таких задач за неделю или за месяц решает junior, senior тестировщик, что он делает сам, что он делает автотестами. Мы соотносили результаты своего труда и скорость, с которой мы это делаем, с отраслью и это позволяло из года в год договариваться до прозрачных критериев.
Что ставить в зачетку?
Поэтому больше половины студентов всегда получало пятерки, но были ребята, которые получали двойки, тройки и приходили на пересдачу именно, потому что у них не было достаточно подтвержденных зачетных единиц. Но они знали, что нужно сделать и как поработать над тем, чтобы это появилось. И отметку в свою зачетку они получали самостоятельно. Я всего лишь фиксировал и в спорных моментах требовал обоснования, почему кто-то претендует не на 0.5 балов по этому компоненту, а 0.7 или даже целый балл? Каждая десятая требовала чёткого обоснования.
Дальнейшее развитие
Онлайн-обучение
В 2017-м году, когда я получил приглашение руководить гимназией Хорошколы и уехал из Новосибирска в Москву, курс по тестированию ПО всё ещё шёл. Так получилось, что со студентами очно мы увиделись только в самом начале семестра, на первой неделе сентября, и в конце декабря-январе, когда я приехал, в общем-то, в зачетках расписаться. Весь семестр они учились дистанционно. И такая организация позволила не потерять планку качества именно в тех терминах, которые мы на первой установочной паре и определили: востребованность на рынке труда, понимание, как устроен отдел тестирования, и работа внутри этого отдела над конкретным кейсом с получением обратной связи от работодателя. При дистанционном сопровождении для студентов была критична возможность работать в команде, обсуждать материалы курса “в короткую” в чате, а в trello вести планирование задач.
Формальное соответствие
Мы проводили этот спецкурс в одном из ведущих вузов страны и это означает, что его нужно было защитить как на научном совете вуза, так и потом на этапе аккредитации. И, разбираясь во ФГОСах, мы не просто выстраивали курс в с соответствии с нормативным требованиям, а смотрели насколько мы можем собирать необходимую отчетность в разрезе учебный действий и компетенций на основе тех данных, которые мы собираем. Пусть для этого рабочую программу дисциплины пришлось дважды серьезно переписывать, но этот опыт позволил нам замахиваться на более серьезные эксперименты, которые легли в основу дальнейших образовательных инициатив.
Границы применимости
В 2015 году мы спроектировали bigdatansu.ru — англоязычную магистратуру по большим данным на мехмате НГУ в таком же залоге. Параллельно я вел другие курсы: по СУБД, предпринимательству, проектному управлению как для иностранных студентов НГУ, так и для студентов технического университета НГТУ. Этот опыт позволяет сказать, что подобный подход применим в разных предметных сферах, а не только для тестирования ПО.
Более того, начиная с 2014 года, мы в рамках i3.school начали его реализовывать в средних школах, так или иначе перелопачивая уже всю общеобразовательную программу не только в Новосибирске, но и в Томске, Тюмени, ХМАО. Так в школах Урая и Мегиона на 10 параллели нет классов, а сотни учеников учатся по своим индивидуальным траекториям.
Но, пожалуй, органичнее всего такой подход развертывается в профильном колледже IThub.ru, который весь построен вокруг “заточки под профессию”. На принципах смешанного, дуального обучения и обучения по метрикам мы выстраиваем весь методический процесс и чем раньше студент осваивает общеобразовательные дисциплины, тем быстрее он переходит к проектной работе, которая уже на 3-4 курсе позволяет ему не только окупать свое обучение, но и примерять на себя ту или иную бизнес-роль не только в игре, но и в практической деятельности. А именно такой мы и видели систему образования в далеком уже 2010 году.
