了解需求？
由於我算是中途加入此專案，所以我並沒有參與到了解客戶需求部分，所以首要工作就是先了解此專案到目前為止的進度。
當主管Christy開啟Wireframe網頁時，我下意識地睜大眼睛與嘴巴。
這是我同時第一次接觸正規的Wireframe＆Figma＆Spec，腦袋資訊量直線激增，主管可能也看出來我有點嚇到，但也是細心講解了整個系統的內容給我聽，並讓我先行消化內容。
讀了整整一天後，歸納出以下結論：
●這間公司會經常性的安排活動(Ex：各式研討會)，而員工可以在班表安排參與活動，參與活動視同出席上班。
●活動可能會舉行在假日，為了要符合勞基法，於是參與活動的同仁，也同時需要安排對應的休假日來進行補假。
●員工在下個月開始之前，都會需要安排與上傳下個月的班表供主管簽核，簽核通過後就可以依照班表進行行程。
●公司會有內部調動員工的情況，所以也需要能夠管理員工資料。
總而言之，此系統是結合了 排班/安排活動/員工管理 ，這裡讓我了解到兩件事情：
1. 功能再複雜，都一定有路可以讓你去找到最終目的。
2. 寫Spec真的是一門學問，要寫到讓第一次看到此系統的人也能理解內容。記得當天回家後，我的腦細胞也跟著我的人一起躺平。
測試表大魔王
在了解完系統之後，很快就到我的正式工作，寫系統測試表。
開始面對我真正的第一個大魔王。
讓我印象很深刻的地方有兩個地方：
第一是我對測試完全改觀，我從來沒想過一個看似單純不過的輸入欄位，也會需要去知道它的長度限制，或是只能輸入某些字元，以及根據輸入的資料，會顯示哪種錯誤的紅字訊息…。
最後發現，網站上的所有物件，都有可能變成測試項目。
第二是因為這個系統裡有主管、員工、人資等角色，所以我要飾演每一種角色，去想我在系統中會有哪些權限，會怎麼去使用功能。
●當我是員工時，我要建立活動、安排班表、以及送審班表。
●當我是主管時，我要審核活動、審核班表、以及調度員工。
●當我是人資時，我要審核新進員工，並設定每個月班表的審核期限。
真的很考驗自身的邏輯是否清晰！
修改調整輪迴
測試遇到的最大心魔就是：這到底是真的問題，還是因為系統還在開發階段，所以會出現這個畫面？然後就會盯著螢幕十分鐘。
到後來告訴自己：不准合理化問題！不合理就是問題！全部給我寫進問題單！
第二大心魔，就是要跟工程師過問題，每一次過問題，都不禁懷疑是系統的問題，還是我的問題。
但真的要感謝RD主管，一聽就知道問題在哪，並告訴我問題中有哪些表達不清楚的地方，都讓我往後寫問題單以及與工程師的溝通上，都有莫大幫助。
總而言之，在不斷的溝通與測試下，最後系統順利上線了。
對於這個系統最開心的不是上線那一刻(當然系統能成功上線還是非常開心😅)，而是能夠完全沈浸在找出問題的過程，試著讓自己成為無知的人，才會發現平常找不到的問題。
回顧專案
最有印象的地方，就是撰寫測試表的過程。
因為系統本身的複雜度，就會影響思考情境的過程，從簡單的情境「點下登入按鈕，會進入系統畫面」，到複雜情境「當我送出了班表，但我也同時被調度到別的單位，那我的班表需要出現在新的主管底下」。
對當時的我來說，思考複雜情境真的是苦手，也是花最多時間的地方。
現在回頭看，也許我當時可以去思考，利用可變動與不可變動的因素去確認情境，比如說送出班表的過程，我跟班表無法變動，但我的部門跟主管是可變動的，是否就有機會去找出可能會發生的情境。
但找尋問題跟鑽牛角尖是一線之隔，很有可能找到最後是根本不會發生的問題也說不定，所以時間成本也要控制得宜，不然可能就會影響後續的專案進度。
第一個專案雖然沒有參與完全，但也已經扎扎實實的感受到專案所需要的細心耐心。
我是Eros，回顧完將繼續走上旅程，下次分享見。
時賦科技首頁：
想了解更多時賦，也可以看看實習生的文章喔：
