Để hoạt động review test case hiệu quả hơn

Bài viết được sự cho phép của tác giả To Thi Van Anh

Tranh thủ mấy ngày Tết, mặc dù tình hình ăn uống, đi chơi cứ phải gọi là tưng bừng nhưng cũng không thể lơ là việc học tập được. Hehe. Thế nên là theo như kế hoạch mình sẽ tung ra một ‘hit’ mới rất không liên quan đến ngày Tết, nhưng mà lại vô cùng liên quan đến công việc mà mình đã làm được gần hai tuần trước khi nghỉ tết và dự là sau Tết còn làm nhiều nhiều và dài dài.

Tuyển dụng tester các công ty

Nghe đã thấy hoang mang, và tóm lại thì nó là gì, không lan man nữa đó chính là hoạt động review test case như tiêu đề bài viết đã gợi ý đó! 

Tất cả chúng ta (trong lĩnh vực phần mềm mềm nói riêng) đều biết được sự cần thiết của các test case, một trong những yếu tố đánh giá hiệu quả của hoạt động kiểm thử. Các test case đóng một vai trò quan trọng trong quá trình đảm bảo chất lượng đầu ra của sản phẩm phần mềm, do đó việc cần phải đảm bảo tính hiệu quả, sự chính xác và tối ưu của các test case cũng là một việc cần được ưu tiên. Và hoạt động reivew ở đây chính là để đảm bảo các yếu tố đó!

Test case sau khi được viết ra xong, đúng quy trình thì sẽ được chính người viết đó tự kiểm tra lại một lượt (self-review) trước khi chuyển cho một thành viên khác trong nhóm kiểm thử, kiểm tra chéo những test case đó (peer-review), sau khi hoàn tất công đoạn này thì test case mới được đưa vào giai đoạn thực thi.

Nắm bắt được tư tưởng và ứng dụng được một số yếu tố dưới đây mình nghĩ là nó sẽ giúp ích được kha khá cho hoạt động self-review và peer-review của chúng ta được tốt hơn đấy (vì mình cũng đang áp dụng rồi mà, ah thì tất nhiên là cũng có chọn lọc cho phù hợp với hoàn cảnh thực tế dự án của mình nhé! kaka), các bạn cùng tham khảo nha!

– Giá trị sử dụng

Việc đầu tiên cần kiểm tra đó là giá trị sử dụng của test case đó, với yêu cầu đó thì test case này có cần thiết không? Test case này đã có được cover bởi một test case nào khác hay chưa? Trong đó ta cần phải xác định được những giá trị mà test case mang lại, việc xác định này sẽ dựa theo mô tả hay chức năng của hệ thống mà test case này được viết ra cho nó.

– Mục tiêu của test case

Đọc lướt qua mô tả, nội dung test case để xác định xem là bạn có hiểu được mục đích của test case này là gì hay không? Lưu ý là mỗi một test case chỉ để kiểm tra một vấn đề cụ thể nào đó thôi nhé. Nếu trong một test case mà nó có nhiều hơn một mục đích cần kiểm tra khi thực thi thì lúc này ta cần phải xem xét tách nhỏ case đó ra.

– Điều kiện trước

Ở đây ta sẽ xác định xem là cái test case này có yêu cầu ta phải chuẩn bị, thực hiện một số setup đặc biệt nào đó trước khi thực thi test case hay không. Thứ tự thực hiện các yêu cầu ấy, và việc review là phải xem xem trong test case đã có lưu ý rõ ràng và đầy đủ những yêu cầu đó hay chưa?

– Các bước thực hiện

Các bước thực hiện được đưa ra trong test case có dễ dàng làm theo khi thực thi test case không? Với một người mới liệu có thể nắm được mục đích và làm theo được thông qua các bước này hay không? Nếu không, thì có thể là người viết chỉ đang suy đoán các bước là như vậy, lúc này cần thì phải chỉnh sửa hoặc là phải thêm một số bước cụ thể hơn để có thể dễ dàng làm theo được.

– Inputs

Các test case cần cung cấp rõ ràng và cụ thể những giá trị đầu vào nào cần cho test case đó. Ta cũng cần phải lưu ý rằng, với những giá trị cụ thể đó ta cũng sẽ có những kết quả cụ thể tương ứng. Và những giá trị này có thể là nguyên nhân mà test case sẽ trả về các kết quả khác nhau sau mỗi lần thực thi.

– Ngôn ngữ

Yếu tố quan trọng nữa là việc sử dụng từ ngữ cần phải đơn giản và rõ ràng. Từ đó, không phải chú thích hay giải thích gì khi mà test case được đưa vào thực thi – tuy  nhiên có thể sẽ có những ngoại lệ (cái này thì không tính nhé :v). Rồi liên quan đến việc diễn đạt, ngữ pháp, hay chính tả… (Lỗi dễ mắc khi mà chúng ta viết test case bằng tiếng Anh, hehe)

– Kết quả mong muốn

Một test case kiểu mẫu cần phải mô tả một cách rõ ràng kết quả mong muốn hay phản hồi của hệ thống khi thực thi test case đó. Từ đây, việc đánh giá test case đó pass hay fail có thể xác định một cách dễ dàng và công bằng.

– Clean-up

Thao tác này đối với một số test case đặc thù, trong khi thực hiện những bước làm thay đổi trạng thái hay cài đặt của hệ thống, nó có thể làm cho các bước sau đó và test case chạy không chuẩn xác nữa. Do đó, với những trường hợp này thì ta cần phải có thêm một bước để khôi phục lại những thay đổi đó.

– Sự phụ thuộc

Ta sẽ xác định test case này có phụ thuộc vào các test case khác hay không? Những test case đó có yêu cầu cần được thực thi trước hoặc sau test case này hay không? Nếu có thì cần phải lưu ý rõ ràng trong các test case đó. Lý tưởng ở đây là mỗi test case cần phải độc lập với các test case khác. Nhưng trong trường hợp không thể tránh được thì điều cần làm đó là phải note lại một cách vô cùng cẩn thận và rõ ràng các thông tin đó nhé.

– Tài liệu

Test case cần có thông tin đầy đủ về tác giả – người viết ra test case đó, độ ưu tiên của test case (nếu có), requirement của test case, những thông tin này sẽ hữu ích trong trường hợp mà cần thêm thông tin hoặc kiểm tra độ bao phủ của test case.

Về cơ bản là chúng ta sẽ nên tập trung chủ yếu vào các yếu tố trên, ngoài ra tùy theo đặc thù của hệ thống, nền tảng ta sẽ cần xem xét thêm những yếu tố khác nữa nhé, như là các thiết bị test nào cần được chuẩn bị, môi trường test là gì… Ta cũng sẽ cần kiểm tra thêm những cái đó có được mô tả đầy đủ và chính xác đối với từng case cụ thể hay chưa.

Hi vọng rằng, với những gợi ý từ bài viết sẽ mang lại những lợi ích nào đó cho tất cả những bạn nào đã đọc bài viết này.

Bài viết gốc được đăng tải tại vananhtooo.wordpress.com

Có thể bạn quan tâm:

• Lead Engineer trông như thế nào?
• Persol – Quy mô tầm cỡ và cơ hội rộng mở chào đón Technical Project Manager
• Công nghệ Cloud: Bối cảnh sử dụng Cloud & kinh nghiệm làm việc với AWS, IaC

Xem thêm Việc làm it job hấp dẫn trên TopDev