Khi làm QA cũng như BA, có 1 thực tế là document (Test case, Requirements) viết bằng plain text thì các bạn Developer ít đọc nó. Một trong những lý do khách quan là cách dùng từ ngữ của chúng ta không thống nhất, dễ gây hiểu lầm. Một lý do khá chủ quan là "chữ quá nhiều" và Developer lười đọc nó. Mình cố gắng chuyển những document của mình thành charts nếu có thể, để giúp team có 1 ngôn ngữ chung khi bàn bạc. Trong các loại chart, Flowchart là loại thể hiện được logic tốt nhất với những icon đơn giản nhưng có thể adapt được trong rất nhiều trường hợp. Trong bài viết này, mình sẽ giới thiệu cách chuyển tải những document của bạn ( nếu có thể) thành flowchart với vai trò là QA hay BA.

 

Flowchart là gì?

Nói đơn giản, Flowchart là một sơ đồ bao gồm các bước, và những điều kiện được sắp xếp theo trình tự nhất định để giải quyết 1 vấn đề. Khi lập trình, Developer thường hay dùng nó để thể hiện logic mà mình muốn code trước khi bắt tay vào làm. Có thể nói, nó là loại chart dễ hiểu nhất đối với Developer.

 

Các thành phần của Flowchart

Flowchart có thể được làm ra khá phức tạp, tất cả những symbol của nó có thể tham khảo ở đây. Tuy nhiên, phần lớn các logic có thể được thể hiện bằng những symbol đơn giản nhất:

 

Với kinh nghiệm của mình, 5 symbols này sẽ vừa đủ để cho bạn thể hiện những logic và process trong dự án. Trong trường hợp bạn có nhu cầu sử dụng thêm ký tự, hãy nhớ thông báo cho toàn team về ý nghĩa. Hạn chế sử dụng thêm ký tự cũng là cách tốt để giữa cho Diagram của bạn simple và dễ đọc

Mình sẽ cho một số ví dụ về cách mình chuyển tải những document của mình thành Flowchart, dưới vị trí là QA và BA

 

Flowchart cho 1 Manual/Automation test case

Đây là một trong những document mà khi chuyển thành Flowchart, mình thấy hiệu quả nhất. Khi mình vẽ Flow diagram cho test case, nó được dùng cho những mục đích sau:

  • Làm cơ sở để viết automation test case
  • Làm document để Developer review test case ( thường là khi chạy fail)

Ví dụ của mình, mình sẽ lấy trong bài viết này. Ở phần 3/, các bạn sẽ thấy chúng ta đoạn code test cho trang login và các step viết ra theo plain text sẽ như sau:

import unittest

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import time


class Demophantom(unittest.TestCase): 
    def setUp(self):
        # self.driver = webdriver.PhantomJS()
        # self.driver.set_window_size(767, 550)
        self.driver = webdriver.Safari()
        self.timeout = 40
    def test_sign_in(self):
        # Step 1 : Access to the website
        self.driver.get("http://automationpractice.com")
        # Step 2: Click to link Sign In
        link_SignIn = self.driver.find_element(By.CLASS_NAME, 'login')
        link_SignIn.click()

        # Wait until the element email appear to make sure the load 
        # is completed
        WebDriverWait(self.driver, self.timeout).until(

            EC.presence_of_element_located((By.ID, "email"))
        )
        # step 3: input the email into field id="email"
        txt_email = self.driver.find_element(By.ID, 'email')
        txt_email.send_keys("[email protected]")


        # step 4: input the password into field id="passwd"
        txt_passwd = self.driver.find_element(By.ID, 'passwd')
        txt_passwd.send_keys("123456")

        # Step 5: Press button which has id="SubmitLogin"
        btn_login = self.driver.find_element(By.ID, 'SubmitLogin')
        btn_login.click()

        # Step 6: Confirm it go to home page with login. In here, 
        # I choose to verify if link LogOut existed
        lnk_logout = self.driver.find_elements(By.CLASS_NAME, 'logout')
        self.assertEqual(len(lnk_logout), 1, 'problem')

        # time.sleep(20)
        # import pdb;
        # pdb.set_trace()



    def tearDown(self):
        self.driver.quit()

if __name__ == '__main__':
    unittest.main()

Vậy, nếu chúng ta, trước hoặc sau khi viết code, chuyển tải logic này thành Flowchart thì nó sẽ là gì?

 

Xin lỗi các bạn vì khả năng vẽ í ẹ của mình ^^!

Ở trong Flowchart này, mình chỉ tập trung show logic, mình không tập trung để thể hiện code được làm ra như thế nào. Ví dụ, làm cách nào để xác định được textbox email, là chuyện sau này của code. Nếu các bạn có ý định làm ra 1 flow chart rõ ràng hơn cũng OK luôn. Nhưng mình nghĩ, nếu người dùng của bạn là Developer hoặc 1 tester ngang hàng thì họ chỉ cần biết logic, họ có thể thay đổi cách implement sau này nếu muốn, nhưng logic thì prefer là giữ nguyên.

Tại sao những action như "Enter 'nguyenduonghai...." lại sử dụng hình con thoi thay vì là hình chữ nhật?

Vì trong code, hay trong logic của mình nó sẽ là hành động input. Nó sẽ dùng data user nhập vào và bỏ vào trong 1 varibale để làm việc sau này. Tương tự như vậy, việc "Show error message" sẽ là hành động output nên cả 2 sẽ được thể hiện ở hình con thoi

 

Flowchart cho Business Analyst?

Cũng tương tự như trên, nhưng như là BA, họ chú trọng vào logic nhiều hơn là data input vào. Khi là BA, mình vẫn hay vẽ những diagram sau để:

  • Giúp Developer hiểu rõ hơn về feature bằng ngôn ngữ logic của họ
  • Giúp team thấy rõ hơn mối liên hệ giữa feature này và feature kia. Đôi khi, nó giúp chúng ta nhận ra rằng nếu không làm xong feature A thì Flow sẽ bị ngắt quãng, có làm feature B cũng không deliver được.

Mình vẫn viết document bằng plain text, nhưng chỉ khi mình muốn explain "Why We do this feature?" và những note của requirement liên quan đến design (ví dụ như field này phải là dropdown với những value này) thôi.

Ví dụ với feature login như trên, BA sẽ có cách thể hiện như sau:

 

Các bạn để ý sẽ thấy mình có dùng 1 symbol lạ cho Login. Đó là "Predefine Process". Mình hay dùng symbol đó để nói rằng trong cái "login" này thực ra làm khá nhiều việc và nó được định nghĩa ở một nơi khác rồi. So far đây là symbol duy nhất mà mình muốn add vào tong list symbol của mình khi mình vẽ 1 Flowchart.

 

Lợi ích cho QA

Với những diagram như trên, sẽ rất dễ dàng cho QA chúng ta

  • Communicate với Developer thông qua logic.
  • Có 1 ngôn ngữ, ký tự chung để discuss trong team.
  • Dễ dàng xác định Statement branch coverage cho test case của mình.
  •  

Lời kết

Mình tin rằng Flowchart diagram là công cụ hiệu quả để giúp team thể hiện được ý tưởng của mình. Chúc các bạn thành công trong việc làm cho document trong dự án dễ đọc và dễ quản lý hơn. Cám ơn các bạn rất nhiều!