主承辦商及系統整合伙伴
需要明確測試工作包、清楚開發責任,以及可供客戶檢視的證據。
按您的責任及下一個決定,選擇合適安排。
需要明確測試工作包、清楚開發責任,以及可供客戶檢視的證據。
驗收前,需要有依據評估供應商交付、系統升級或新應用。
需要針對流程、介面、發佈或效能疑問,取得聚焦答案。
未解問題及證據缺口,可能拖延驗收,或令重要業務風險仍然不清。
一個約定工作包,連結業務疑問、技術團隊可跟進的發現及下一步驗收決定。項目主管取得清楚結論;處理問題的人取得相關證據及跟進責任。
SMERP 於 2005 年在香港成立。團隊成員持有 PMP、PMI-ACP 及 CISA 等項目管理及 IT 審計資格,均為個別成員持有。團隊介紹說明支持我們規劃及檢視方法的背景。
了解我們的經驗及團隊資格開始前,雙方會確認測試與開發責任的分隔、匯報安排及相關關係。是否適合承接,取決於客戶或合約要求的獨立程度。
重要驗收或上線,需要完整而範圍明確的測試輪次。
以下四類主要交付,連同證據索引及約定交接材料。
需要回答指定流程、介面、發佈或效能問題。
聚焦測試說明、相關案例及證據、發現,以及回應指定問題的結論。
客戶正進行驗收,或評估現有測試證據。
約定驗收記錄或檢視發現。報告識別檢視過的材料,以及我們實際執行過哪些測試。
初步討論免費,工作按項目或約定測試輪次報價。建議書列明範圍、版本、環境、投入、交付項目、檢視時間及包含重測輪次。除非明確包含,程式修正及專項評估另行安排;新增範圍或重跑測試先批准,再開始額外工作。
六步工作連結決定與證據。建議書列明您的方案適用哪些活動及交付。
確認驗收或上線決定、重要流程、準則、決定日期及各方責任。
確認失敗對業務的影響,再安排相關要求及檢查的優先次序。
執行前檢查指定版本、環境、權限、測試資料、介面及預期結果。
記錄預期及實際結果、重現步驟與證據。分流應用、資料、環境及介面問題;原因未明則標示待分析。
在指定版本重測修正,並按約定範圍檢查受影響流程的回歸結果。
按約定準則整理結果,說明剩餘風險、證據缺口及下一步,供客戶作決定。
六步工作歸納為下列四類交付。檢視時間、包含重測投入、交接格式及證據存取安排,均在建議書確認。
每個檢查點記錄現有證據、缺口及下一位負責人。最終驗收或上線決定由客戶作出。
檢查版本、環境、資料及預期結果是否符合約定開始條件。如有阻礙,記錄對計劃檢查的影響,以及由誰處理。
在指定版本驗證相關結果,分開記錄:供應商報稱修正、已驗證修正、客戶接受剩餘風險。單憑供應商更新,未足以確認修正已獲驗證。
每項約定準則標示符合、不符合或證據不足,列明剩餘風險、下一步及負責人。即使整體通過率高,重要流程仍可能有未解問題。
完整 ITS 服務整合以下四類交付。聚焦測試、UAT 支援或證據檢視,則在建議書列明適用項目、詳細程度及檢視時間。材料按約定權限及保密安排交付。
決定、準則、範圍、責任及準備條件,連同業務流程、要求、風險與計劃測試的對照。
帶來的價值:檢視計劃是否處理真正重要的業務風險。
輸入、預期及實際結果、執行狀態及證據參照,連結受測版本及環境。
帶來的價值:知道檢查過甚麼,亦讓下一位接手者有可用記錄。
影響、重現步驟、問題分流狀態、負責人、供應商回覆,以及包含重測和回歸檢查的結果。
帶來的價值:跟進問題至有解決證據,或清楚記錄尚待完成的行動。
一頁列明準則、結果、剩餘風險、限制及下一步負責人,連結詳細證據及交接材料。
帶來的價值:快速檢視下一個決定,需要時亦可找到支持細節。
純屬示意:以下為測試環境中的虛構應用,準則、參照及結果均為例子,並非客戶結果或認證。
結論:尚未符合全部約定準則。兩項未通過及兩項未完成檢查,需要在下一次驗收檢視前跟進。此示例尚未記錄已驗證修正,亦未記錄客戶接受剩餘風險。
執行狀態:計劃 12 個案例,8 個通過、2 個未通過、1 個受阻、1 個未執行。結果適用於 DEMO-02 版本及已記錄的測試條件。
TC-01–08 符合各自預期結果,EV-01–08 提供約定範圍內的檢查證據。
TC-09 退回更正時遺失已輸入資料(D-01,高優先);TC-10 未符合約定角色權限檢查(D-02,中優先)。EV-09–10 記錄相關發現。
TC-11 因測試端點未能使用而受阻,預期介面行為尚未驗證。
TC-12 尚未執行,計劃回歸準則未獲驗證,並保留在證據索引內。
交接索引:測試計劃 TP-01 連結約定準則、TC-01–12、執行記錄、EV-01–10 及 D-01–02。受阻及未執行檢查保留原有狀態及下一步,並無通過結果。詳細記錄支持摘要,亦供日後重用。
對照約定流程、風險與已完成檢查,看清哪些重要範圍已驗證、仍有缺口或受阻。
追蹤重要未解問題、已在指定版本驗證的修正及未完成行動。報稱修正保留獨立狀態。
每項準則列明符合、不符合或證據不足,連同剩餘風險、下一步及負責角色。
透過約定索引找到案例、條件、結果及支持證據,讓交接材料可用於日後檢視或約定回歸工作。
展開測試活動,了解相關範圍。建議書確認選定檢查及條件。
按約定預期結果,檢查業務規則、權限、正常操作、例外情況及重要完整流程。
檢查約定介面、資料交換、錯誤處理,以及連接系統之間傳遞的記錄。
先確認工作負載及門檻,再觀察指定條件下的回應、處理量、錯誤及資源使用。
在修正、升級或改動後,按約定版本及回歸範圍,重新檢查選定的既有流程。
協助整理情境、測試資料、問題記錄及跟進。業務負責人保留驗收責任。
按約定要求檢視現有測試材料,指出覆蓋缺口、結果不清或需要跟進的事項。
安全、滲透、無障礙及 AI 專項評估,需要另行確認範圍及專業能力,一般功能或效能測試不代表已包含這些項目。
可以,前提是確認權限、要求、環境、測試資料及配合安排,並訂明發現如何交予開發團隊,以及誰負責修正。
我們會確認開發參與、相關關係、匯報途徑及客戶所需分隔。如 SMERP 曾開發或修改系統,會先披露。若要求外部獨立評估,我們不會將自身交付描述為該項外部評估。
可提供現有要求或驗收準則、指定版本、測試環境與權限、代表性資料及決定日期。我們會在規劃前協助確認缺口。
結果適用於受測範圍、版本、資料及環境。報告會列明未測部分及剩餘風險。測試為決定提供依據,並非保證軟件沒有缺陷,亦不代替客戶批准。
建議書會列明修正負責方,以及包含的重測輪次或投入。額外修正、範圍或重跑安排會另外評估及確認。
結果反映受測工作負載及環境。我們會記錄與正式環境的相關差異及解讀限制。正式環境測試需要另行確認計劃及授權。