Smoke Testing không phải là thử nghiệm toàn diện, mục đích của nó là để xác minh các chức năng cơ bản của phần mềm đã hoạt động như mong muốn hay không. Loại kiểm thử này sẽ được thực hiện đầu tiên và đối với mỗi version của phần mềm. Câu hỏi đặt ra là tại sao chúng ta cần làm như vậy? Bởi khi đội phát triển phát triển xong và bàn giao cho QA thì họ cũng không thể kiểm tra và chắc chắn rằng không có lỗi nào xảy ra hay toàn bộ chức năng đã hoạt động chính xác. Vậy chúng ta hãy cùng nhau đi tìm hiểu Smoke Testing các bạn nhé! Sau khi bản dựng đã được đánh dấu đã hoàn thành Smoke Testing đồng nghĩa với việc bản dựng đó QA đã chấp nhận kiểm tra chuyên sâu. Giả sử bản dựng nào không thành công thì sẽ bị từ chối và nhóm phát triển sẽ phải khắc phục sự cố đó bằng cách phát hành một bản dựng mới. Dựa theo lý thuyết thì Smoke được hiển là kiểm thử về cấp độ bề mặt nhằm xác minh rằng bản dựng đó đã sẵn sàng để thử nghiệm, cũng có thể thử nghiệm này sẽ được thực hiện bởi nhóm phát triển trước khi phát hành. Thông thường thử nghiệm được dùng trong Integration Testing, System Testing and Acceptance Level Testing.

    Một số ví dụ Smoke Testing

    Thử nghiệm này được sử dụng nhằm Tích hợp, Chấp nhận và Kiểm tra hệ thống. Chúng ta hãy cùng nhau đi vào các vị sau tôi sẽ nói đến sau đây để hiểu hơn về thử nghiệm ‘khói’ nhé!

Acceptance Testing

    Bản dựng nào trước khi được phát hành cho QA cũng sẽ phải thực hiện thử nghiệm Smoke Test ở dạng Acceptance Testing. Trong thử nghiệm này thì Smoke Testing có vai trò xác minh các chức năng cơ bản như mong đợi của việc triển khai. Như vậy chúng ta nên xác minh tất cả các triển khai cho bản dựng đó. Chúng tôi sẽ lấy ví dụ dưới đây về việc triển khai trong một tòa nhà để các bạn hiểu các thử nghiệm Smoke:

• Đã triển khai chức năng đăng nhập, cho phép các trình điều khiển đăng ký và đăng nhập thành công.
• Đã triển khai chức năng bảng điều khiển để hiển thị các tuyến đường mà người lái xe sẽ thực hiện ngày hôm nay.
• Đã triển khai chức năng hiển thị thông báo thích hợp nếu không có tuyến nào tồn tại trong một ngày nhất định. Trong bản dựng này, đối với mức chấp nhận thì Smoke sẽ có nghĩa là xác minh rằng ba phương thức triển khai trên cơ bản đã hoạt động tốt. Nếu chỉ 1 trong 3 yêu cầu bị fail thì chúng ta nên từ chối bản dựng đó và trả lại cho đội phát triển.

Integration Testing

    Thử nghiệm này khác với Acceptance Testing ở chỗ nó sẽ được thực hiện khi các mô-đun riêng lẻ được triển khai và thử nghiệm. Kiểm tra này được thực hiện để đảm bảo rằng tất cả các chức năng tích hợp cơ bản và đầu cuối đều hoạt động tốt như mong đợi.

    Cũng có thể là sự tích hợp của hai mô-đun, nhiều hay tất cả các mô-đun với nhau, do đó độ phức tạp của thử nghiệm Smoke test sẽ khác nhau và tùy thuộc vào mức độ tích hợp. Chúng ta hãy cùng xem các Ví dụ sau về việc triển khai tích hợp cho thử nghiệm này:

• Triển khai tích hợp cho phân hệ tuyến và điểm dừng.
• Triển khai tích hợp cho cập nhật trạng thái đến và phản ánh tương tự trên màn hình.
• Triển khai việc tích hợp hoàn chỉnh từ việc nhận hàng cho đến các mô-đun chức năng giao hàng.
• Ở bản dựng này, ngoài việc Smoke test xác minh ba cách triển khai cơ bản này mà đối với lần triển khai thứ ba, một số trường hợp sẽ xác minh để tích hợp hoàn toàn. Nó giúp ích rất nhiều cho việc tìm ra những vấn đề được đưa vào trong quá trình tích hợp và những vấn đề mà nhóm phát triển không chú ý.

System Testing

    Đúng như tên gọi của nó, đối với cấp độ hệ thống, Smoke test bao gồm các kiểm tra cho các quy trình công việc quan trọng và thường được sử dụng nhất của hệ thống. Nó chỉ được thực hiện sau khi hệ thống hoàn chỉnh hay đã sẵn sàng & được kiểm tra. Việc kiểm tra này cho cấp hệ thống có thể được gọi là kiểm tra Smoke test trước khi kiểm tra hồi quy.

    Trước khi bắt đầu hồi quy của hệ thống hoàn chỉnh, các tính năng cơ bản từ đầu đến cuối được kiểm tra như một phần của thử nghiệm Smoke test. Bộ thử nghiệm Smoke test cho hệ thống hoàn chỉnh bao gồm các trường hợp thử nghiệm từ đầu đến cuối mà người dùng cuối sẽ sử dụng rất thường xuyên.

    Tầm quan trọng của SCRUM

    Hiện nay, hầu như các dự án đều không áp dụng theo phương pháp Waterfall và chuyển dần theo Agile và SCRUM. So với phương pháp thác nước truyền thống, Kiểm tra Smoke test được đánh giá cao về SCRUM và Agile.

    Như chúng ta biết trong SCRUM, mỗi một spint có thời gian rất ngắn và do đó việc thực hiện kiểm tra này là cực kỳ quan trọng, để trong trường hợp các bản dựng có bị lỗi thì cũng có thể được báo cáo ngay lập tức cho nhóm phát triển và kịp thời khắc phục.

    Sau đây là một số lưu ý về tầm quan trọng của Smoke test trong SCRUM:

• Mỗi một spint có thời gian khoảng hai tuần nhưng đôi khi việc xây dựng cho QA bị trì hoãn.
• Điều tốt nhất cho nhóm là các vấn đề được báo cáo ở giai đoạn đầu.
• Mỗi câu chuyện có một bộ tiêu chí chấp nhận, do đó việc thử nghiệm 2-3 tiêu chí chấp nhận đầu tiên cũng giống như thử nghiệm Smoke test của chức năng đó. Khách hàng từ chối nhận hàng nếu một trong số các tiêu chí không đạt yêu cầu.
• Giả sử điều gì sẽ xảy ra khi 2 ngày sau nhóm phát triển giao cho bạn bản dựng và chỉ còn 3 ngày nữa là bản demo nhưng đúng lúc đó lỗi chức năng cơ bản đã xảy ra.
• Trung bình, một sprint có các câu chuyện nằm trong khoảng từ 5-10, do đó, khi bản dựng được đưa ra, điều quan trọng là đảm bảo rằng mỗi câu chuyện được triển khai như mong đợi trước khi chấp nhận bản dựng vào thử nghiệm.
• Khi toàn bộ hệ thống được xây dựng hoàn chỉnh thì sẽ được kiểm tra và hồi quy, sẽ có một spint dành riêng cho hoạt động này. Cũng có thể ít hơn một hai tuần để kiểm tra toàn bộ hệ thống, do đó điều quan trọng là phải xác minh các chức năng cơ bản nhất trước khi bắt đầu hồi quy. Smoke Test Cycle

    Dưới đây là lưu đồ Chu trình Smoke test.

    Sau khi một bản dựng được triển khai cho QA, nếu Smoke test vượt qua, bản dựng đó được nhóm QA chấp nhận để kiểm tra thêm nhưng nếu không thành công, bản dựng sẽ bị từ chối cho đến khi các vấn đề được báo cáo được khắc phục.

    Ai Nên Thực hiện Smoke test?

    Smoke test không cần phải toàn bộ team QA cùng tham gia để tránh lãng phí thời gian.

    Smoke test có thể được thực hiện bởi QA Leader, người quyết định dựa trên kết quả về việc chuyển bản xây dựng cho nhóm để thử nghiệm thêm hay từ chối nó. Hoặc trong trường hợp không có khách hàng tiềm năng, chính QA cũng có thể thực hiện thử nghiệm này. Tuy nhiên trường hợp dự án có quy mô lớn thì toàn bộ team QA cũng có thể thực hiện thử nghiệm. Nhưng điều này không phải như vậy trong trường hợp của SCRUM vì SCRUM là một cấu trúc phẳng không có Khách hàng tiềm năng hoặc Người quản lý và mỗi người thử nghiệm có trách nhiệm riêng đối với câu chuyện của họ. Do đó, QA cá nhân thực hiện thử nghiệm này cho những câu chuyện mà họ sở hữu Tại sao chúng ta nên tự động Smoke test? Thử nghiệm này là thử nghiệm đầu tiên được thực hiện trên bản dựng do nhóm phát triển phát hành. Từ kết quả của thử nghiệm này, thử nghiệm thêm được thực hiện (hoặc bản dựng bị từ chối). Thường cách tốt nhất để thực hiện kiểm tra này là sử dụng tool tự động hóa và lên lịch chạy bộ Smoke test khi một bản dựng mới được tạo. Bạn có thể đang nghĩ tại sao tôi nên “tự động hóa bộ kiểm tra Smoke”? Hãy cùng xem xét trường hợp sau:

    Một câu hỏi đặt ra bạn sẽ làm gì khi bạn chỉ còn một tuần nữa là bản phát hành và trong tổng số 500 trường hợp thử nghiệm, bộ thử nghiệm Smoke test của bạn bao gồm 80-90. Nếu bạn bắt đầu thực hiện tất cả các trường hợp thử nghiệm 80-90 này theo cách thủ công, vậy bạn sẽ mất bao nhiêu thời gian? Tôi dự đoán rằng tối thiểu cũng sẽ mất 4-5 ngày.

    Thay vì bạn dùng cách thủ công và tạo các tập lệnh để chạy tất cả các trường hợp thử nghiệm 80-90 này thì các trường hợp sẽ được thực hiện trong 2-3 giờ và bạn sẽ có kết quả ngay lập tức. Nó giúp bạn tiết kiệm thời gian quý báu của mình hơn nhiều phải không nào? Do đó hãy sử dụng sự trợ giúp của tự động hóa cho quá trình thử nghiệm này bạn nhé!

    Ưu điểm và nhược điểm

    Không một phương pháp nào là hoàn hảo cả vì vậy chúng ta hãy cùng nhau tìm hiểu Ưu và Nhược điểm của phương pháp này nhé.

    Ưu điểm:

•     Dễ dàng thực hiện.

•     Giảm rủi ro.

•     Sớm tìm ra các khuyết tật ở giai đoạn sớm nhất.

•     Tiết kiệm công sức, thời gian và tiền bạc.

•     Chạy nhanh chóng nếu được tự động hóa.

•     Giảm thiểu rủi ro về tích hợp.

•     Cải thiện chất lượng tổng thể của hệ thống. Nhược điểm:

•     Thử nghiệm này không tương đương hoặc thay thế cho thử nghiệm chức năng hoàn chỉnh.

•     Kể cả khi không có lỗi xảy ra trong kiểm thử này thì cũng không chứng minh được phần mềm của bạn đã hết lỗi.

•     Loại thử nghiệm này phù hợp nhất nếu bạn có thể tự động hóa nếu không tốn nhiều thời gian vào việc thực hiện thủ công các trường hợp thử nghiệm, đặc biệt trong các dự án quy mô lớn có khoảng 700-800 trường hợp thử nghiệm.

•     Smoke test nên được thực hiện trên mọi bản dựng bởi nó giúp chỉ ra những lỗi chính và phát hiện từ giai đoạn còn sớm. Điều này không chỉ áp dụng cho các chức năng mới mà còn cho việc tích hợp các mô-đun, khắc phục sự cố và ứng biến. Nó là một quá trình rất đơn giản để thực hiện và nhận được kết quả chính xác.

    Kết Luận Thử nghiệm này có thể được coi là điểm đầu vào cho Thử nghiệm chức năng hoàn chỉnh về chức năng hoặc hệ thống (nói chung). Việc kiểm tra này có thể giảm thiểu các nỗ lực, tiết kiệm thời gian và nâng cao chất lượng của hệ thống và đặt biệt khi thời gian cho một spint của bạn còn khá ít. Việc kiểm tra này có thể được thực hiện cả thủ công và cũng có thể nhờ sự trợ giúp của các công cụ tự động hóa. Nhưng cách tốt nhất và được ưu tiên là sử dụng các công cụ tự động hóa để tiết kiệm thời gian.

    Tài liệu tham khảo https://www.softwaretestinghelp.com/smoke-testing-and-sanity-testing-difference/