• 關於軟體測試的專業領域

    ID-10097472

     

    大部人對於軟體測試的想像在於..

    重複性的測試 — yes

    程式是 RD 寫的 但是Quality 卻要 QA Manager 負責 — yes

    常常都是指出有問題的人 — yes

    這樣的工作專業為何?

    十年前剛加入 QA 團隊,筆者一開始也有這樣的迷思,慢慢隨著專案與經驗的累積,

    QA 的工作範疇,大體會接觸到 (Not limited to):

     Coding languages
     Development models
     Development paradigms
     Incidents
     Incident handling
     Maturity models
     Money
     People skills
     People types
     Process improvement
     Product architectures
     Product paradigms
     Product risks
     Quality assurance activities
     Quality factors
     Quality goals
     Resources
     Risk willingness
     Standards
     Testing obstacles
     Testing progress
     Test approaches
     Test basis
     Test effort
     Test levels
     Test objectives
     Test policy
     Test processes
     Test process improvement
     Test project risks
     Test scopes
     Test techniques
     Test tools
     Test types
     Time

    軟體測試的定義

    讓我們來看看幾個國際組織對於軟體測試的定義與定位

     

    IEEE 829: “The process of analyzing a software item to
    detect the difference between existing and required conditions (that is, bugs)
    and to evaluate the features of the software items.”

     

    BS 7925-1: “Process of exercising software to
    verify that it satisfies requirements and to detect errors.”

    ISTQB:

    “The process consisting
    of all life cycle activities, both static and dynamic, concerned with planning,
    preparation and evaluation of software products and related work products
    to determine that they satisfy specified requirements, to demonstrate
    that they are fit for purpose and to detect defects.”

     

    筆者認為:

    軟體的測試 = QA Process 測試流程 + Testing Techniques 測試技巧 + Domain Know-how 產業產品知識

    • QA process 指的是測試的流程,可能受到公司、產業等的影響,會有不同的規範與品質政策
    • Testing Techniques:如何測試,白箱或是黑箱測試、用什麼測試工具等
    • Domain know-how:對該產品、客戶與產業的熟悉。例如 consumer 的產品與 Enterprise用的產品就會有所不同。

    專業價值的提升

    從找出問題 —> 到幫助解決問題 —> 持續不斷的改善

    QA Value Level

    (圖案內容取至 “Guide to Advanced Software Testing”)

    創造價值

    QA 可以從三個構面創造價值,分述如下

    1. 產品價值的提升

    2. 產品的決策

    3. 持續改善的流程

    透過 QA 的參予可以讓好的產品品質變得更好,讓品質不好的產品品質有所提升,將品質風險可以得到控管。

    QA Business Value

     

     

     

     

     

     

    Tags: , ,

  • SAMM Construction

    資訊安全  – 開發面

    延續 SAMM (Software Assurance Maturity Model ),專案開發需要注意哪些項目呢?

    開發的過程主要參予的人員不外乎為研發團隊 (project managers, RD/QA)

    根據 SAMM 的建議,開發的過程中,在資訊安全的部分,主要有下列三個方向可以考慮:

    1. Threat Assessment (TA)  風險評估

    2. Security Requirements (SR) 資訊安全需求

    3. Secure Architecture (SA) 資訊安全架構

     

    接這讓我們分別看這三個方向,有哪一些具體的工作要執行

    1. Threat Assessment (TA)  風險評估

    每個軟體系統在執行時,潛在所可能帶來的風險為何?

    例如:該系統在做密碼傳輸時,是否有加密? 是否有被中途截取或是修改的可能性?

    TA 又分為三個階段

    • TA 1: 建立適當的威脅模型 (例如:登入的功能,潛在的威脅有密碼明文傳送、密碼cookie被盜用等..) + 建立駭客攻擊的模型
    • TA2: 建立潛在可能被濫用的模型 + 將威脅的類型案權重計算
    • TA3: 評估第三方工具使用的安全威脅 + 威脅模型與資訊安全控制

    以筆者公司為例,我們會針對每個產品所使用的 library,

    去檢查是否有已知的 CVE (Common Vulnerability Exploit),

    如果有重大的CVE,就必須要針對該 lib做更新

     

    2. Security Requirements (SR) 資訊安全需求

    這點指的是軟體的功能應該如何達到資訊安全的需求

    例如:密碼的複雜度,至少為8個字元。其中必須包含英文與數字等。

    • SR1: 從功能面定義資訊安全需求(例如密碼強度) + 評估資訊安全準則的需求 (例如:電子商務網站就必須符合PCI規範)
    • SR2: 建立控制的機制 + 針對已知的風險建立資訊安全需求(例如:敏感性資料一律用HTTPS/SSL加密的方式傳輸)
    • SR3: 將資訊安全規範導入至上下游供應商 + 資訊安全稽核

    由於有些公司的軟體或是開發工作為外包,所以就必須將這樣的資訊安全需求列入考量

    相關的資訊安全稽核也應該包含軟體需求分析的階段。

    例如:密碼的強度的規範、資料的加密傳輸、權限的管理、非法字元的檢查等。

     

    3. Secure Architecture (SA) 資訊安全架構

    整體的資訊安全架構,

    例如:帳號密法的驗證,都透過 Active Directory 整合方式進行。

    例如:資料的傳輸都是透過 SSL / HTTS 等

     

    Tags: , , , , , , , ,

  • 資訊安全的管理面

    System-Security-Reader-2-icon

     

    根據 SAMM這個模型,

    管理面 (Governance) =

    1.Strategy & Metrics +

    2.Education & Guidance +

    3.Policy & Compliance

     

     

    就讓我們分別針對這三項說明

    1.Strategy & Metrics + 2.Education & Guidance + 3.Policy & Compliance

     

    1. Governence > Strategy & Metrics (SM)

    主要的目標是要建立起整個組織對於資訊安全測試的流程與計畫。並且定義資訊安全的目標與評估風險。

    在指標的部分,需要收集企業內部與外部的一些資訊,以便建立起衡量標準。

    所以在這個階段主要的工作分為三個階段,

    SM1 : 建立組織內部的資訊安全計畫 + 評估企業風險

    SM2 : 將應用程式與資料分類 + 建立並評估各類資料的資訊安全目標

    SM3: 定期進行與業界標準的比較 + 收集歷史數據建立衡量準則

    執行的步驟與成熟度為 SM1 > SM2 > SM3

    也就是先建立整體資訊安全計畫 > 再針對資料分類與風險評估 > 收集歷史執行資料與業界比較

     

    2. Governence > Policy & Compliance (PC)

    這個部分主要是內部與外部法規上的考量。

    例如 電子商務會有 PCI 的規範。

    與個人隱私有關的資訊會有”個人資料保護法”,所以必須將這些法規併入資訊安全規範考量,

    所以這個部分會有定期性的檢查與稽核,為的就是確定相關的程序有符合法規的規範。

    PC1: 了解內部外部相關的法規與規範 + 建立遵循的準則

    PC2: 建立符合規範的資訊安全政策與標準 + 建立稽核的機制

    PC3: 建立每個專案資訊安全的出貨條件 + 針對稽核的資料作收集與分析

    執行的步驟與成熟度為 PC1 > PC2 > PC3

    首先,了解所處行業內部外部的法規限制與規範PC1 > 再根據企業內部狀況制定資訊安全政策與標準,並且定期的稽核 PC 2 > 最後針對每個專案訂定把關的條件。

    舉筆者曾經任職軟體公司為例,

    PC1: 內部外部法規的限制,例如加密解密的演算法,出口至美國需要一定的資訊揭漏

    PC2:每個產品出貨都會經過法律審查的流程,標準的審查內容包含:是否有用 GPL/LGPL的license、加解密的演算法等,並且記錄每個產品所提供的這些資訊與法律上審查的結果

    PC3: 針對每個專案出貨前,預期可以達到 2 產品瑕疵 / 每千行程式碼 ( 2 defects/ LOC) ,並且針對每個專案的狀況進行資料分析

    這些就是 Governence > Policy & Compliance

     

    3. Governence >Education & Guidance (EG)

    最後一個,也是最重要最值得投資的一環,教育訓練

    “預防重於治療”

    要預防的好,並須靠教育訓練,讓大家有一定的資訊安全觀念

    教育訓練可以透過電子、實體上課、競賽等方式讓員工了解資訊安全的議題

    除了教育訓練與宣導之外,也提供員工一定遵循的守則。

    同樣的分為三個階段進行

    EG 1 = 資訊安全認知宣導與訓練 + 資訊安全準則

    EG 2 = 針對不同的職務舉辦相關的資訊安全訓練 + 在每個專案實行資訊安全小老師

    EG 3 = 建立內部資訊安全論壇平台 + 建立相關資訊安全專業認證

     

    如果公司內部尚未有一個完整的資訊安全計畫,不防可以參考這三個方向,開始著手規劃適合公司的資訊安全政策與訓練計畫

    Governence > Strategy & Metrics (SM)

    Governence > Policy & Compliance (PC)

    Governence >Education & Guidance (EG)

     

    SAAM Overview

     

     

    Tags: , , , , , , , , , ,