故事是這樣開始的…

前一陣子, 團隊裡面的成員們, 正在為一段 story acceptance critira 的描述進行辯論, 後來得到兩個選項 :

A: Then the results page displayed
B: Then I should see results page

當大家正在針對上面這兩個選項進行辯論的過程中, 突然間有一個成員舉手了, 說 :

請問一下, 如果 scenario 用中文來寫, 會如何來描述???

這個問題真的敲醒我, 對ㄝ, 中文的話要怎麼表達這個句子.

A : 那麼結果頁面成功顯示
B : 那麼我能夠看見結果顯示成功

於是我開始反查 cucumber 裡面有沒有類似的作法, 結果發現 cucumber 在約兩個月 ( 10 月左右) 前提供了 i18n (多國語系) 的支援, 範例可以在這找到 :

../cucumber-2.4.0/examples/i18n/..

於是, 小弟我就寫一個 API 測試的範例來說明吧 :

Steps:

1. 在 feature 檔一開始定義繁體中文

#language: zh-TW

2. feature 檔寫法 :

過去我們習慣用 Feature: , 但是在 i18n 裡面我們可以用 功能: 表示.

功能: 
     為了避免愚蠢的錯誤
     作為一個 QA 初學者
     我希望有人能告訴我測試 API 結果

場景大綱: 代表 Scenario Outline:

場景大綱: 測試 API
 當我測試圖片API編號 <數值_1>
 那麼我驗證回傳編號 <驗證_1>

例子: 代表 Examples:

例子:
 | 數值_1 | 驗證_1 |
 | 1    | 1    |
 | 2    | 2    |
 | 20   | 10   |

當大功告成之後, 我們就來實作 step 檔吧 :

When /我測試圖片API編號 (\d+)/ do |op|
    @response = @req.get("photos/#{op}")
end

Then /我驗證回傳編號 (\w+)/ do |op|
    json = Json_Parser.new(@response)
    ids = json.get_json_values_by_key("id")
    if not ids.eql? "#{op}".to_i
        raise "expect id : #{op}, actual id : #{ids}"
    end
end

在這裡我是引用 rest_client 及 json, 這兩個 ruby 的 package 來處理 API 的 request 及 response, 詳細的實作在這裡就不多做說明了.

當一切都完成後, 我們就來執行 cucucmber 吧!

cucumber

結果 :

經過這一番努力後, 得到一個結論 : 

誰說中文不能寫測試案例 :)

Github : 

https://github.com/jerseysu/ruby-cucumber-rest-api

[Cucumber] 如何用 rakefile 重跑 Cucumber Fail 的 Features ???

Use --format rerun --out rerun.txt to write out failing features. You can rerun them with cucumber @rerun.txt. 

• :run 用來執行任務
• :rerun 用來重跑任務

require 'rubygems'
require 'cucumber'
require 'cucumber/rake/task'

namespace :test do

    desc 'ExecuteTestCase'
    task :execute do
        Cucumber::Rake::Task.new(:run) do |t|
            t.cucumber_opts = "-f pretty --format rerun --out rerun.txt"
        end

        is_first_run_successful = run_rake_task ("run")

        if not is_first_run_successful
            Cucumber::Rake::Task.new(:rerun) do |t|
                t.cucumber_opts = "@rerun.txt"
            end

            run_rake_task("rerun")
        end
    end

    def run_rake_task(name)
        begin
            Rake::Task[name].invoke
        rescue Exception => e
            puts e
            return false
        end
        true
    end
end

$ rake test:execute

如何讓自己的自動化測試結果被團隊看見

最近讀到一篇文章在討論 如何讓你的自動化測試結果被團隊看見 (How to Make Your Test Automation Efforts Visible to Everyone on the Team), 覺得蠻有趣的, 所以來寫篇心得吧 :)

文章裡面提到許多的論點, 都能夠引起自己心裡的共鳴. 在作者的專案中, 他覺得自己的測試和自動化測試很不容易被團隊發現, 似乎沒有人在意測試結果這件事, 直到要出版的前一刻才會被重視. 然後突然間, 整個團隊中的成員就會開始討論, 為什麼這些需求沒有 PASS? 為什麼有些需求沒有被驗證到?

更很有趣的是作者也發現不是只有他一個人有這種感覺 (謎之音 : 應該是幹過 QA 的人都知道這檔事). 事實上, 作者在 webinar 也上面發問過一個問題 : 'How visible are your current testing and automation efforts to everyone in the organization? （你現在的組織內有多少人在做測試及自動化的工作?) 有趣的結論是 : 

43.5% answered “Somewhat visible.”
26.5% answered “Not very visible.”

作者認為這個數字應該可以在更高才對, 所以他在新的 Agile 專案中, 特別注意下列這些的部分 : Planning, Writing 和 Execution. 

1. Planning

在早期的年代中, 自動化測試並不是那麼地被重視. 所以, 第一件事是必須要讓你的自動化測試工作達到你Manager 的預期. 這是非常關鍵的一件事, 因為如果你不讓他知道, 他們往往不知道自動化測試是需要投入開發的成本, 這不是像阿拉丁神燈一樣許願就能夠完成 (it’s not simply a “one and done” effort), 且測試案例是需要被維護的.

如果你不維護測試, 這將會變成你的夢靨. 因為 Managers 可能會預期自動化測試的案例要高達 90%, 這取決於你是否能夠 push 他們或者教育他們說這是很一件很難達到的事.

Managers 也需要知道測試自動化會是團隊每個成員的責任, 而不是像過去一樣只有單一 tester 來完成的事. 可參考這個 Link http://www.joecolantonio.com/2015/09/22/5-things-your-boss-doesnt-understand-about-test-automation/

Staffing and Skills

現在軟體開發的趨勢也漸漸專注於客戶導向 (customer-driven development models), 所以自動化測試也比過去更需要被重視. 其中, Agile 和 DevOps 更是需要自動化的輔助, 例如持續整合和發佈 (Continuous intergration and delivery) 就必須仰賴自動化測試來串接, 使開發流程更加快速及流暢.

作者更進一步地強調, 在他過去的經驗中, 開發人員往往多於測試人員 (謎之音 : 好像大家都是這樣的組織架構), 所以開發人員也被要求對產品的測試自動化負責, 而每一個團隊的成員也須依照自己能力來做測試的工作, 並且在一個 Sprint 中被 Planning 及 Control.

如果一個測試人員只負責開測試案例, 這反而會降低整體開發的速度. 雖然分別對不同的開發人員的產出做測試會加速開發, 但更重要的是讓你的測試策略更明確地被團隊看見. 作者提到一個方法能夠降低開發者跟測試人員的 gap, 就是透過 BDD (Behavior-Driven Development) 的方法.

Use TDD and BDD

假如看過許多導入 Agile 來做開發的公司, 大部分的公司都會提到 TDD, BDD 或者是 Red-Green-Refactor. 你一定會問說, 這是三小?? TDD (Test-Driven Development) 簡單的來說就是在你寫程式之前先設計你的測試. 在每次 commit code 的時候都要在這個 eco-system 裡面先通過這些測試. TDD 的好處是讓每個 developer 在寫 code 以前就被預見自己會產生的 defect. 所以你不用再等到 QA 花了一天測試後才告訴你結果. (謎之音 : 世界真是美好)

當 TDD 開始被重視並實現時, BDD 就是一個以使用者 (As a User) 觀點來做實現的測試了. 基本上, 你用寫 Story 的方式來寫測試, 這樣會使你的測試更專注於使用者需要的是什麼. 如果你今天是與一個跨國的團隊合作, 溝通會是你最大的障礙及耗費成本的一件事. 若是使用 BDD 裡面所提倡可執行化的文件 (executable specifications) 來成為團隊裡面協同合作的工具, 無形間會降低團隊的溝通成本, 且也能有更好的合作.

Make your automation efforts part of the DoR and DoD

一個團隊的 DoR (Definition of Ready) 是根據團隊何時將 backlog 中的工作拿到現在的 sprint 中, 這會成為團隊對於這個 story 的確認清單 (Checklist). 如果使用 DoR, 團隊成員要很明確地說出這個 story 如何被執行及實作. 如果不能產出一個合適的測試案例或者是不明確的驗收標準 (如不清楚這個功能 Pass 或 Fail 的標準), 表示這個 story 根本沒有被定義清楚且必須被退回去.

而另一個確認清單會是 DoD (Definition of Done), 在 Sprint Review 的時候, 每個團隊成員都要很明確的明白這個 story 被關閉的驗收標準. DoD 需要包含 測試類型, 測試涵蓋率 (Test Coverage) 和定義測試的條件. DoD 可以增加產品品質的能見度及滿足客戶的需求. (The DoD adds visibility to your product’s quality and customer satisfaction.)

當你是 Scrum Team 的一員, 你所定義的 ‘Done’ 就必須將自動化測試包含在 story 中. 舉例來說, 如果一個 developer 要改 login page, 他就有責任要去改 test framework 中的 page object. 所以你看自動化測試多重要 :)

2. Write Test Phase

Test Mix

測試的金字塔 (Testing Pyramid) 可以幫助我們看出測試案例類型的分佈. 單元測試在金字塔中佔了大多數, 並且是所有測試很重要的基礎. 所以寫單元測試是很划算的一件事 (bang for the buck), 因為它能夠跟你的程式一起完成, 並且很容易地在你的開發過程中被加入.

在這個金字塔的中間是整合測試, 它雖然小但卻也是最花成本的, 然而它確可以測到你系統的每個部分. GUI 的測試, 在金字塔的頂端, 以圖來說它也會是佔你的測試案例中的極小部分.

坦白來說, 這個金字塔常常會誤導我們. 作者甚至認為這個金字塔常常會把人們帶往錯誤的方向 (我也是這麼覺得), 作者提出兩個論點, 第一個是這個金字塔根本無視市場的風險, 所以要整個降低風險, 最好的方法就是執行金字塔頂端 GUI test. 而且這個金字塔無形中就暗示你要多做些 Unit Test, 因為它告訴你這是一件 C/P 值很高的事. 但這卻常常使人迷失了焦點, 我們往往會乎略開發跟維護的時間, 當然這也取決於你是如何看待這些測試. 有趣的事, 作者訪問了 Todd Gardner 這個想法, 他的回答是 :  this concept (he calls it terrible testing) that you should definitely check out.

Make your Tests More Visible with Code Reviews

作者提到你應該好好對待你的測試程式就向開發人員對待他的程式一樣. 這意味者你需要跟開發人員一樣使用對的開發模式. Code Review 是一個很棒的方法讓任何的偏差 (deviations) 更明顯的被指出來,

作者常常看到在大型的企業裡面, 做自動化測試的 Team lead 會加入所有的 code review, 他能夠幫助團隊找到一個好的自動化測試實踐就像做測試一樣. 另一方面, 一個好的 checklist 也能夠幫助在做 code review 的測試人員們定義出正確的測試涵蓋率. 所以當測試人員也加入開發人員 code review 的時候, 就能夠幫助開發人員找出他們未想到且需要被測試的部分.

3. Execution

Make Your Tests Visible with Continuous Integration

另一個好的方法是使用 CI (Continuous Integration) 來幫助團隊的每個成員看見現在產品的狀態. 比起使所有人都在等待你的測試結果, 使用 CI 工具能夠確保你的產品不會 broken 並且是可以隨時被發佈到客戶的狀態. CI 應該也要能夠發出警訊當這個版本是不穩定的狀態, 使每個成員都有能力來判斷是否將這個版本發佈給客戶.

CI 的好處 :

• Provides fast feedback about the quality of their code
• Displays real-time status of your project using wall displays
• Helping team to detect a team’s code might conflict other team

Manage Tests with Metrics

作者提供了下面幾個 Test Metrics, 使你測試的能見度提高 :

1. Mean time to diagnosis (AKA the Alan Page Object) 

如果在你的 CI 環境裡面, 測試需要花很長的時間, 且你也需要花一天的時間來查錯誤. 當你正在查的時候, developer 同時又 push 新的 code, 這個時候你無形間就浪費了一天的時間在 debugging 你的測試, 因為這個時候錯誤可能就被修正了. 所以隨時注意你的 mean time, 盡量縮短時間去查問題.

2. Automated to manual ratio

你需要隨時的注意手動測試跟自動化測試的比例. 更多的手動測試只會讓你在出版前花更多的時間而已. 這個觀念可以幫助你隨時反應 (keep a pulse) 你需要花多久的時間來做出版的測試, 且還可以幫助你洞察團隊是否自動化（或不自動）正確的事情。

3. Flasky ratio

這個東西會讓你抓狂 (謎之音 : 真的), 因為有時候 flasky 會隨機的讓有問題 cases 無原因的 PASS. 這會消耗你很多的時間, 並且讓你的信用度下降和使團隊忽略你的測試結果. 這個 metrics 可以幫助你確保測試的正確性.

4. Bug found by automation

這個絕對是能夠幫助你的測試能見度上升的 metric.

Becoming Visible

作者提到了在軟體開發週期中幾個重要的地方能夠增加測試能見度, 倘若你能夠專注在 planning, coding 及執行的階段, 你將會看到一個團隊對於測試的重視. 慢慢的你的團隊會邁向一個更世界大同的境界 <= 作者是這樣說的啦 (This in turn will make your teams happier, your customers happier and ultimately yourself happier like it did me.)

這篇中確實提到了幾個重要的點, 除了教育你的 Manager 外, 在 Scrum Team 中要更重視 DoR 及 DoD, 使得 story 能更明確的被驗證. 並且每個測試都需要被 code review, 如果有機會的話也加入 developer 的 code review 來找出更多盲點. 更重要的是多注意: mean time of diagnosis, automated to manual ratio, flasky ratio 和 bug found by automation, 這些無形中都能幫助你的測試能見度提升. 

[Reference]

1. How to Make Your Test Automation Efforts Visible to Everyone on the Team

2. Alan Page Principles – Lessons Learned at Microsoft