最近在公司碰到一個有趣案例,就是某一個由License Platform. SSO . Product三個系統組成的整體應用,因為License Platform某種功能需要,想要改變傳遞給SSO系統的Account Profile中的Account Type值,也就是本來可能有A.B.C三種Account Type,現在想多新增一個D Type,所以License PlatformDeveloper跑來問SSO這樣是不是會有問題。

  遇到這樣的問題,除了考慮SSO本身是否有用到Account Type的值之外(例如:本來就在程式中有設邏輯檢查Type值且只允許A.B.C,這樣當新增D TypeSSO自然會出問題),最重要的是SSO的下游系統也必須被考慮進來。更簡潔一點來說,這裡有一個系統整合測試的原則:"任何上游系統傳遞資料的變動,都必須保證下游系統不受影響!

  從QA本身的立場思考,也就是當我們的系統是在上游時,就必須知道任何整合資料的改變都有可能影響下游系統運作,因此在決定Spec Change之前,問過所有下游系統不受該新的spec影響是最重要的一件事,這就有點像是當上游工廠排放廢水時,所有下游廠商都會受到汙染,上層資料改變,下層系統自然要知道這資料改變後會不會造成問題。

  所以今天SSO上游的Licanse Platform系統來問我們有沒有concern時,不能只是檢查自己系統的邏輯,由於下家的Product 系統也會從SSO接受這些資料然後客製化自己的前端登入判斷,因此SSOQA更必需知道此舉有必要通知Product系統的人來一起了解有無影響,當對他們及SSO本身都確定沒影響,這樣License Platform才能被允許改變傳遞資料的內容,在系統整合鏈中,只要你下面有系統串接,就一定要考慮到下面所有系統,只有確定自己以下所有系統都沒問題,才能允許上家系統改變。

 

201793日星期日 2:04 AM

arrow
arrow

    jackterrylau 發表在 痞客邦 留言(1) 人氣()