Shift Left Testing - Bí quyết cho Phần mềm thành công
Bài đăng này đã không được cập nhật trong 6 năm
Shift Left Testing, một thần chú DevOps mới trong phát triển phần mềm: Khi tôi sử dụng thuật ngữ 'Shift Left', có thể bạn đang tự hỏi không biết Shift Left có liên hệ gì tới một phần mềm? Khoảng 2 thập kỷ trở về trước gần như là không có ‘Testing Phase’ (pha kiểm thử) riêng cho việc phát triển phần mềm và vai trò của người kiểm thử (Tester Role) gần như là không tồn tại. Các developer thường tự mình phát triển và test phần mềm của họ và release phần mềm. Khái niệm Kiểm thử phần mềm đã được giới thiệu một cách dần dần khi các khiếm khuyết của sản phẩm bắt đầu có ảnh hưởng đến ngân sách của dự án và do đó người ta mới bắt đầu quan tâm tới lĩnh vực kiểm thử phần mềm. Ngành công nghệ thông tin bắt đầu theo mô hình thác nước để phát triển phần mềm trong đó, như chúng ta đã biết, vòng đời phát triển phần mềm đi theo thứ tự : Requirements => Design => Coding => Testing Vì vậy, nếu bạn bắt đầu từ trái sang phải, giai đoạn Thử nghiệm là ở góc phải nhất (pha cuối) của vòng đời phát triển phần mềm.
Giới thiệu về khái niệm Shift Left
Theo thời gian, mọi người nhận ra tầm quan trọng của Kiểm thử phần mềm và tác hại của việc để 'Giai đoạn Thử nghiệm' ở cuối khi kết thúc vòng đời Phát triển Phần mềm - Điều này đã làm chi phí của lỗi là rất cao và nỗ lực rất lớn và mất nhiều thời gian để khắc phục chúng.
Có những trường hợp sau khi tốn rất nhiều thời gian và nỗ lực vào một phần mềm, thì lỗi nghiêm trọng mới được xác định, phát hiện ra ở phần cuối, do đó phần mềm không thể được phát hành ra thị trường dẫn đến một mất mát rất lớn. Do đó, việc xác định lỗi trong giai đoạn cuối là quá muộn : việc phát hành đã bị hoãn hoặc đôi khi, phần mềm đã bị loại bỏ hoặc đập đi làm lại khi xem xét các nỗ lực cần thiết để sửa chữa lỗi là không thể, điều này thật không đáng. Dưới đây là bảng chi phí sửa lỗi theo thời gian (càng về sau chi phí sửa lỗi càng lớn):
‘Defects are less costly when caught early’.
Nhận thức này đã đem lại một cuộc cách mạng tuyệt vời trong ngành công nghiệp phần mềm và sinh ra một khái niệm mới gọi là 'Shift Left', có nghĩa là thay đổi từ phải sang trái bắt nguồn từ 'Giai đoạn Kiểm thử' hoặc rõ hơn là liên quan đến Kiểm thử ở mọi giai đoạn và kiểm thử liên tục trong suốt quá trình phát triển phần mềm. Để hình dung rõ hơn, bạn hãy nhìn vào ảnh dưới đây: Ảnh ở trên là vòng đời phát triển phần mềm theo mô hình thác nước còn phía dưới là theo phương pháp Shift Left, chúng ta dễ dàng nhận thấy pha Kiểm thử tồn tại song song và xuyên suốt trong cả vòng đời phát triển phần mềm.
Shift Left Testing là gì?
Thứ nhất, nguyên tắc 'Shift left' hỗ trợ đội Test để hợp tác với tất cả các bên liên quan sớm trong giai đoạn phát triển phần mềm. Do đó họ có thể hiểu rõ các yêu cầu và thiết kế các trường hợp thử nghiệm (bộ test case) để giúp sớm phát hiện lỗi của phần mềm tạo điều kiện cho đội khắc phục tất cả các lỗi sớm nhất có thể.
Shift Left cũng không có gì đặc biệt, chỉ là phải kiểm thử nhiều hơn trong vòng đời phát triển phần mềm, do đó sẽ cho phép họ hiểu các yêu cầu, thiết kế phần mềm, kiến trúc, mã hóa và chức năng của nó, đặt câu hỏi cho khách hàng, các nhà phân tích nghiệp vụ và các nhà phát triển , tìm kiếm sự làm rõ, và cung cấp phản hồi khi có thể để hỗ trợ cho nhóm.
Sự tham gia và sự hiểu biết này sẽ dẫn dắt những người Kiểm thử có được kiến thức đầy đủ về sản phẩm, suy nghĩ thông qua các kịch bản khác nhau, thiết kế các kịch bản dựa trên hành vi phần mềm, giúp nhóm nghiên cứu xác định các khiếm khuyết ngay cả trước khi mã hóa (coding) hoàn tất.
Làm thế nào để Shift Left có hiệu quả trong quá trình Phát triển phần mềm?
Có nhiều cách để sử dụng Shift Left liên tục trong quá trình Phát triển phần mềm. Dưới đây là vài điểm chính về Shift Left:
- Shift Left tập trung vào việc người Kiểm thử phải tham gia vào tất cả các pha của vòng đời Phát triển Phần mềm và quan trọng nhất là ở các giai đoạn quan trọng của chương trình. Điều này cho phép người kiểm tra chuyển hướng tập trung của họ từ việc chăm chăm soi tìm lỗi sang ngăn ngừa lỗi và thúc đẩy các mục tiêu nghiệp vụ của chương trình.
- Trong phương pháp Shift Left, người kiểm thử có vai trò và trách nhiệm rất lớn.
- Với trách nhiệm như vậy, nhóm Kiểm thử không chỉ tập trung vào "Kiểm tra phần mềm để xác định lỗi", mà cần chủ động làm việc với đội phát triển ngay từ những giai đoạn ban đầu để lên kế hoạch và xây dựng một chiến lược thử nghiệm mạnh mẽ và hiệu quả. Cần có một QA leader giỏi để hướng dẫn cho đội Test, người này phải biết tập trung vào tầm nhìn dài hạn của sản phẩm chứ không chỉ là chịu trách nhiệm về công việc kiểm tra.
- Shift Left là một cơ hội để Tester thiết kế các bài kiểm tra đầu tiên, nơi các bài kiểm tra hoàn toàn tập trung vào trải nghiệm của khách hàng và những mong đợi của họ, điều này sẽ giúp các nhà phát triển phát triển phần mềm dựa trên các bài kiểm tra này và do đó đáp ứng được nhu cầu của khách hàng (người dùng).
- Shift Left không chỉ dừng lại ở việc kiểm thử mà còn là quá trình trao đổi qua lại liên tục giữa Tester và Dev, giúp dev có trách nhiệm hơn đối với những dòng code của mình.
- Phương pháp tiếp cận Shift Left cũng khuyến khích các Testers áp dụng BDD (Behavioral driven development : phát triển theo định hướng hành vi) và TDD (Test-driven development : phát triển theo định hướng kiểm thử), giúp ngăn ngừa các khiếm khuyết cho phần mềm.
- Shift Left Testing trong Agile: hỗ trợ việc tạo thành các nhóm Scrum Agile, bao gồm các Testers cùng với các vai trò khác nhau. Trong các cuộc họp đứng, các tương tác khác, các cuộc họp đánh giá đã làm cho các thử nghiệm có thêm thông tin liên quan đến chương trình và do đó đã cho phép họ tham gia vào các phân tích chi tiết của phần mềm và cung cấp phản hồi nhanh chóng mà có thể giúp đỡ trong việc ngăn ngừa các khiếm khuyết tiềm ẩn trong phần mềm.
Nói chung việc để cho các tester tham gia vào quá trình phát triển phần mềm càng sớm thì càng tốt, họ có thể tham gia vào các cuộc thảo luận và cộng tác trên các ý tưởng, yêu cầu ở mỗi giai đoạn để mang về giá trị cho sản phẩm cuối cùng và cũng giúp dự án xác định những rủi ro và giảm nhẹ nó trước.
Tester cần làm gì khác đi trong kiểm thử Shift Left?
Dưới đây là vài yếu tố chính cần được lưu ý là những gì các Tester cần làm khác đi trong kiểm thử Shift Left:
- Nhóm thử nghiệm cần phải tham gia sớm vào hệ thống ngay từ khi bắt đầu dự án để phát triển tích hợp với phần còn lại của nhóm và doanh nghiệp để cung cấp đầu vào hữu ích ở mọi giai đoạn phát triển phần mềm.
- Nhóm thử nghiệm nên làm việc với nhóm nghiệp vụ và nhóm hoạt động để làm rõ về chương trình và cung cấp một cái nhìn rõ ràng về yêu cầu, giúp lập kế hoạch một cách hiệu quả vào các nhu cầu nguồn lực, nhu cầu đào tạo và yêu cầu công cụ thử nghiệm cho chương trình trước .
- Các nhóm thử nghiệm phải tương tác với tất cả các bên liên quan trong phát triển phần mềm để có được tầm nhìn rõ ràng về sản phẩm và thiết kế một chiến lược thử nghiệm hợp lý nhất và lên kế hoạch cho effort để kiểm tra tối ưu, phân tích sự phụ thuộc vào môi trường thử nghiệm, bên thứ ba, ... và chuẩn bị một chiến lược, framework tự động hóa mạnh mẽ, xây dựng kế hoạch quản lý dữ liệu kiểm thử hiệu quả.
- Cần thống nhất trong đội để chọn ra một QA leader giỏi để hướng dẫn cho đội Test, người này phải biết tập trung vào tầm nhìn dài hạn của sản phẩm chứ không chỉ là chịu trách nhiệm về công việc kiểm tra.
- Các yêu cầu (từ khách hàng) là chìa khóa và cơ sở để thành công của bất kỳ chương trình phần mềm nào, các yêu cầu được xác định rõ ràng góp phần lớn vào sự thành công của dự án. Trong suốt giai đoạn Lập kế hoạch Yêu cầu, người kiểm thử cần phải xem xét và phân tích các yêu cầu, làm rõ bất kỳ sự mơ hồ nào để rõ ràng hơn, đầy đủ, khả năng kiểm tra, xác định tiêu chí chấp nhận ... Cũng cần xác định các yêu cầu thiếu (nếu có), hiểu các phụ thuộc và các chiến lược thực hiện. Loại bỏ các yêu cầu giúp phần mềm 'Fail Fast' và sửa chữa tất cả các lỗi sớm nhất có thể.
- Đưa ra đầy đủ, rõ ràng và chính xác trong yêu cầu bằng cách đưa ra các ví dụ thực minh hoạ các tính năng đang được sử dụng.
- Người kiểm tra cần tham dự các cuộc họp đánh giá thiết kế thường xuyên và hiểu thiết kế và kiến trúc sản phẩm, xác định các sai sót về thiết kế, đề xuất lựa chọn thiết kế luân phiên, xác định sơ hở và tạo các kịch bản kiểm tra phù hợp để phá vỡ thiết kế.
- Người kiểm tra cần tiến hành kiểm tra tĩnh (đánh giá) trước và cung cấp phản hồi về các tài liệu dự án chính để các khuyết tật không được tiếp cận với phần mềm và mở rộng ảnh hưởng của nó sau này.
- Nhóm thử nghiệm cần cộng tác với nhóm thiết kế và phát triển trong việc cung cấp các kịch bản thử nghiệm trước để phát triển mã và giải quyết tất cả các kịch bản thời gian thực có thể và các luồng nghiệp vụ.
- Nhóm thử nghiệm phải thiết kế các kịch bản kiểm thử mạnh mẽ và chính xác để chỉ xác định được một vài khiếm khuyết trong quá trình kiểm tra và các khuyết tật chính bị ngăn chặn trong pha Kiểm Thử (cuối cùng).
- Người kiểm tra phải kiểm tra càng sớm càng tốt, dù là trên một hệ thống độc lập hoặc cục bộ, để khiếm khuyết không vào được giai đoạn sau.
Toàn bộ mấu chốt của khái niệm 'Shift Left' đều xoay quanh việc để người kiểm thử tìm ra các lỗi càng sớm càng tốt bằng tất cả các phương tiện có thể.
Ích lợi của Shift Left Testing đem lại:
- Tìm ra các khuyết tật sớm do đó làm giảm chi phí của dự án.
- Thử nghiệm liên tục để giảm khuyết tật cuối cùng.
- Tự động hoá mọi thứ và cải thiện thời gian cho ra thị trường.
- Tập trung vào các yêu cầu của khách hàng và cải thiện trải nghiệm của khách hàng.
Lời kết:
Khái niệm "Shift Left" đã mang lại một sự thay đổi lớn cho toàn bộ vai trò "Testing". Từ trước đó, sự tập trung duy nhất của việc Kiểm thử chỉ là 'Phát hiện khuyết tật' và bây giờ mục đích của 'Shift Left' từ góc độ Kiểm thử là một hành trình của 'Phát hiện khuyết tật sớm để Ngăn ngừa Hư hỏng'. Do đó, Shift Left là một bước nhảy vọt lớn trong ngành công nghiệp phần mềm trong phương pháp phát triển phần mềm hướng tới tốc độ phát triển thị trường, nâng cao chất lượng phần mềm và giảm thời gian ra mắt thị trường.
Bài dịch trên còn nhiều thiếu sót, nếu bạn quan tâm có thể tham khảo bài viết gốc tại đây : http://www.softwaretestinghelp.com/shift-left-testing-approach/
All rights reserved