在註冊新的機器學習高級課程之前，我們會對未來的學生進行測試，以確定他們的準備程度，並了解他們到底需要提供什麼來準備課程。 但出現了一個困境：一方面，我們必須測試數據科學的知識，另一方面，我們又無法安排一次完整的4小時考試。
為了解決這個問題，我們在資料科學課程開發團隊中部署了一個 TestDev 總部（看起來這只是一個開始）。 我們向您列出了開發知識評估測驗時遇到的 10 個陷阱。 希望線上學習的世界在此之後會變得更好一些。
Rake 1：未能明確定義測試目標
為了正確定義目標並建立將這些目標納入考量的測試，在規劃階段我們必須回答幾個問題：
- 我們實際上在檢查什麼？
- 測試將在什麼環境中進行以及使用什麼機制？ 在這種環境下有哪些限制？ 同一點將使您了解將進行測試的設備的技術要求，以及內容的技術要求（如果測試是從手機上進行的，即使在小螢幕上，圖片也應該可讀，它應該可以放大它們等）。
- 測試需要多長時間？ 您需要考慮使用者參加測試的條件。 會不會有什麼狀況需要他中斷測試過程然後再繼續？
- 會有反饋嗎？ 我們如何形成並交付它？ 您需要收到什麼？ 測試執行和回饋之間是否存在時間延遲？
在我們的例子中，回答了這些問題後，我們定義了以下測試目標清單：
- 測驗應顯示未來的學生是否準備好學習該課程以及他們是否擁有足夠的知識和技能。
- 測驗應該給我們回饋資料，指出學生犯錯的題目，以便他們提高知識。 下面我們將告訴您如何寫它。
Rake 2：未能為專家測試編寫者制定技術規範
為了編寫測試項目，讓測試知識領域的專家參與其中非常重要。 而對於專家來說，您需要一份合格的技術規格（描述），其中包括測試主題、所測試的知識/技能及其水平。
專家不會為自己做這樣的技術規範，因為他的工作是提出任務，而不是測試的結構。 而且，即使在教學過程中，也很少有人專業地發展測驗。 這是在一個單獨的專業——心理測量學中教授的。
如果您想快速熟悉心理測量學，那麼在俄羅斯有 對於所有有興趣的人。 為了進行更深入的研究，教育研究所 和研究生院。
在準備技術規格時，我們會為專家（或更好的是，與他一起）收集測試的詳細描述：任務主題、任務類型、任務數量。
如何選擇任務類型：確定主題後，我們決定哪些任務最能測試這個主題？ 經典選項：開放式任務、多選或單選任務、配對等（不要忘記測試環境的技術限制！）。 在確定並指定任務類型後，我們為專家提供了現成的技術規格。 您可以將其稱為測試規範。
Rake 3：沒有專家參與測試開發
當讓專家沉浸在測試開發中時，不僅要向他表明“工作範圍”，而且要讓他參與開發過程本身，這一點非常重要。
如何使與專家的合作盡可能有效：
- 提前做好準備，花一些時間討論測驗開發和心理測量的科學知識。
- 將評估者的注意力集中在創建有效且可靠的評估工具上，而不是問題清單。
- 解釋他的工作包括一個準備階段，而不僅僅是任務本身的發展。
一些專家（由於他們的性質）可能認為這是對他們自己工作的測試，我們向他們解釋，即使我們創建了出色的任務，它們也可能不適合特定的測試目標。
為了使過程快速進行，我們與專家一起準備了一個主題覆蓋範圍（知識和技能）表，這是測試規範的一部分。 正是這張表使我們能夠準確地解決問題並確定我們要測量的內容。 在每種特定情況下，它的編譯方式可能略有不同。 我們的任務是檢視一個人對先前基礎課程的知識和技能的理解程度，以便了解他對學習新課程的準備程度。
Rake 4：認為專家“最了解”
更了解該主題。 但它並不總是解釋清楚。 檢查作業的措詞非常重要。 寫下清晰的說明，例如「選擇 1 個正確的選項」。 在 90% 的情況下，專家會以他們自己理解的方式準備問題。 沒關係。 但在把考試交給考生之前，一切都需要檢查和梳理，以便考生準確理解自己的要求，而不會因為誤解任務文本而犯錯。
為了避免任務的雙重解釋，我們建立了「認知實驗室」。 我們要求目標受眾參加測試，大聲說出他們的想法並詳細記錄。 在“認知實驗室”，你可以“發現”不清楚的問題、錯誤的措辭，並獲得測試的第一個回饋。
Rake 5：忽略測試執行時間
諷刺模式：開
當然，我們的測試是最好的，每個人都夢想能通過！ 是的，總共4個小時。
諷刺模式：關閉
當有一個可以檢查的所有內容的清單時，最重要的是不要這樣做（乍一看這聽起來很奇怪，不是嗎？）。 你需要狠狠地剪裁，與專家一起辨識關鍵知識和技能（是的，有些技能也可以在測驗中得到檢驗）。 我們查看任務類型並估計目標完成時間：如果一切仍然超過合理限制，我們就會削減它！
為了減少體積，您也可以嘗試（仔細）在一項任務中測試兩種技能。 在這種情況下，很難理解這個人為什麼會犯錯，但如果做得正確，兩種技能都可以被考慮。 重要的是要確保這兩種技能對應於同一知識領域。
Rake 6：沒有考慮評分系統
通常，在編寫評估測驗時，他們會使用經典的評分系統，例如，簡單的任務 1 分，困難的任務 2 分。 但這並不普遍。 僅基於測驗結果的分數總和並不能告訴我們太多：我們不知道這些分數是針對哪些任務獲得的，我們只能確定正確任務的數量。 我們需要準確地了解考生所展現的技能。 此外，我們希望向他們提供有關哪些主題需要改進的回饋。
畢竟，我們正在做一個測試，將人們分為準備好和未準備好完成課程的人；我們會建議一些人透過免費培訓來準備課程。 對我們來說重要的是，這個群體只包括那些真正需要它並做好準備的人。
我們在我們的情況下做什麼：我們在測試開發人員的工作小組中確定需要識別哪些人群（例如，準備好學習，部分準備好），並形成這些人群的特徵表，表明哪些技能和知識將與準備學習培訓的群體相關。 透過這種方式，您可以製定此類測試任務的「難度」。
Rake 7：僅自動評估結果
當然，評估應該盡可能客觀，因此一些學生材料是自動評估的，“按鍵” - 與正確答案進行比較。 即使沒有專門的測試系統，也有很多免費的解決方案。 如果您了解編寫腳本的原理，那麼您就可以使用 Google 表單和表格結果做任何您想做的事情。 如果某些任務是由專家檢查的，那麼我們需要考慮在不提供有關考生資訊的情況下向專家提供答案。 並思考如何將專家測試的結果融入最終的評估中。
我們最初想用程式碼製作幾個開放式任務，專家根據預先制定的標準評估解決方案，我們甚至準備了一個系統，將測試參與者的個人答案匯出到專家的特殊表格中，然後將結果匯入包含評估計算的表格。 但在與目標受眾代表、產品經理和教育設計師討論後，我們認為進行技術訪談並獲得即時專家回饋和對程式碼以及個人問題的討論，對於參與者本身來說會更加有效和有用。
現在專家驗證了測試的完成情況，並澄清了一些問題。 為此，我們準備了技術面試的問題指南和評估標準。 在技術面試之前，考官會收到應試者的答案圖，以幫助他選擇要問的問題。
Rake 8：不解釋測試結果
向參與者提供回饋是一個單獨的問題。 我們不僅需要告知測驗分數，還需要提供對測驗結果的理解。
它可以是：
- 參與者犯了錯誤但正確完成的任務。
- 參與者犯錯的主題。
- 他在參加考試的人中的排名。
- 參與者層級的描述，例如與專家層級的描述一致（基於職缺的描述）。
在我們測試的試點啟動過程中，我們向想要加入該計劃的人以及結果展示了一系列需要改進的主題。 但這肯定不理想，我們會改進並提供更好的回饋。
Rake 9：不要與開發人員討論測試
也許最尖銳的耙子就是「按原樣」將測試、描述和評分標準發送給開發人員，這讓人特別不舒服。
具體需要討論什麼：
- 問題的出現、結構、圖形的位置、正確答案的選擇是什麼樣的。
- 分數是如何計算的（如果需要），是否有任何附加條件。
- 回饋是如何產生的，在哪裡獲取文本，是否有額外的自動生成的區塊。
- 您需要收集哪些額外資訊以及在什麼時間收集（相同聯絡人）。
為了避免誤解，我們要求開發人員編寫 2 到 3 個不同的問題，以便他們可以在編寫測試本身之前了解它們的樣子。
Rake 10：無需測試，直接上傳至生產環境
3次，夥計們，測試應該由不同的人檢查3次，或者更好的是，每次檢查3次。這個真理是用血汗和程式碼行像素得出的。
我們的測試檢查以下三項：
- 產品 - 檢查性能、外觀、機械測試。
- 測驗開發人員 - 檢查任務文字、任務順序、測驗工作形式、任務類型、正確答案、可讀性和圖形的正常檢視。
- 任務的作者（專家）以專家的身份檢查測試的保真度。
實踐中的一個例子：只有在第三次運行時，任務的作者發現有 1 個任務仍保留舊版本的措辭。 之前的諸位也都積極統治。 但當測試被編碼時，它看起來與最初想像的不同。 很可能需要修正某些內容。 需要考慮到這一點。
總
小心地繞過所有這些“耙子”，我們創建了一個特殊的 ，測試申請人的知識水平。 任何人都可以在我們準備下一個材料時對其進行測試，我們將在其中告訴您機器人內部發生了什麼，以及它之後會變成什麼。
您可以透過參加 SkillFactory 線上課程從頭開始獲得受歡迎的職業，或者在技能和薪水方面進行升級：
- （12 週）
- （20 週）
- （20 週）
- （12個月）
更多課程
- （12個月）
- （14 週）
- （5 週）
- （18個月）
- （6個月）
- （12個月）
- （8個月）
- （9個月）
- （12個月）
- （18個月）
- （18個月）
- （12個月）
- （9個月）
- （7個月）
來源： www.habr.com