Hẳn ai làm trong mô hình Agile gần đây đều nge đến khái niệm shif-left testing. Hiểu nôm na nó kiểu giống 1 hướng tiếp cận để làm sao tăng quality, giải quyết vấn đề testing khi có quá nhiều tickets cần testing nhưng tester không đủ thời gian và nguồn lực có thể test hết. Vậy nó là gì, team mình đang và đã vận dụng nó thế nào cho việc delivery features. Trong blog này mình sẽ chia sẻ những kinh nghiệm đó để mọi người có thêm 1 góc nhìn, nếu áp dụng được thì càng tốt nhé.
Shift-left là gì
Nếu hiểu theo nghĩa đen của “shift-left” có nghĩa là “dời qua trái” vậy chẳng lẽ nó đang ở “phải” và việc mình làm là đưa nó qua “trái” là xong sao? Đùa một chút thôi, các bạn có thể hình dung lại một vòng đời release của mỗi feature thì đều trải qua các môi trường sau:
Local => SIT(system intergration testing) => UAT(user acceptance testing) => PROD(production)
Như ai cũng thấy để 1 ticket được đi tới PROD thì các tickets đều phải ghé qua Local, SIT, UAT. Và thông thường tới các môi trường này việc testing mới được tiến hành ở cuối các giai đoạn, dẫn tới người tester sẽ có rất nhiều việc làm và thường trở thành bottleneck tại môi trường đó. Cho nên “Shif-left testing” có nghĩa là mình đưa việc testing của 1 ticket đó từ “cuối” giai đoạn thành testing từ “đầu” giai đoạn trong chu trình phát triển phần mềm. Việc đảm bảo quality ko phải dành riêng cho tester nữa mà là trách nhiệm của cả team từ developer, BA, designer, …

Áp dung shift-left như thế nào?
Quay lại với câu hỏi ban đầu, vậy áp dụng shift-left thế nào? Test sớm là test thế nào? Nó được tiến hành cụ thể trong từng môi trường thế nào? Có những activity xảy ra cho việc này?

Hình trên là câu trả lời cho tất cả những câu hỏi trên. Các bạn có thể thấy việc testing được tiến hành từ rất sớm và đều được tiến hành trên cả 3 môi trường, nhưng với mỗi môi trường thì chúng mình có các activity khác nhau để đảm bảo quality cho nó.
- Local: Đây là giai đoạn phát triển features nên thứ nhất chúng mình tập trung vào việc đảm bảo những acceptance criteria phải được develop như trong user story đề cập, thứ hai là làm sao đưa feedback nhanh nhất để developer có thể sửa ngay tai giai đoạn này. Chúng mình thực hiện việc đó bằng những buổi demo tại ngay bàn của anh developer đó. Tại buổi này có sự tham gia của cả BA, Designer, PO và Tester, tất cả mọi người sẽ nge anh dev đó nói những criteria mà anh đó đã implement, tiếp theo mọi người sẽ hỏi những câu hỏi liên quan đến features đó để làm rõ requirement, có thể bổ sung những negative case còn thiếu do không aware được lúc develop.
- SIT: Đây là môi trường để có thể test integration tới các 3rd party. Cũng là giai đoạn mà có rất nhiều tickets được deploy xong đồng thời cùng 1 lúc. Vậy thì xử lí bài toán testing thế nào đây? Câu trả lời là tụi mình sẽ nhóm các user story thành từng nhóm feature, thì trước sprint sẽ có 1 bạn QA được assign cho feature đó. Bạn QA đó sẽ nghiên cứu các story đó trước, tạo ra những bộ test case, cũng như chuẩn bị test data. Tiếp theo bạn tester sẽ tiến hành pair-test với developer, thứ nhất hoạt động này sẽ giúp cho ticket được verify nhanh vì developer có thể chia sẻ các test case mà họ đã test từ local, sẽ tiết kiệm thời gian cho tester, vì lúc này tester chỉ cần thêm những case về hệ thống hay những negative case mà thôi. Thứ hai, việc này sẽ thay đổi mindset của tester từ việc tìm ra bug thay bằng việc phòng ngừa, cũng như từ developer sẽ có trách nhiệm hơn với ticket mà mình làm, mục tiêu cuối cùng là làm sao cả team cùng delivery features đúng hẹn.
- UAT: Trên môi trường này thì công việc của tụi mình chỉ chạy regression test lại những test case quan trọng đã test trên môi trường SIT. Những test case quan trọng này là những test case cover được nhiều business nhất, thường sẽ được chọn theo kiểu user journey. Có 1 điểm lưu ý là các bạn nên nói chuyện nhiều với BA hoặc PO để hiểu context mà 1 enduser dùng hệ thống, để từ đó hiểu được nếu đa số khách hàng sử dụng tính năng đó thì họ sẽ sử dụng ứng dụng của mình theo những use case nào.
Vậy shift-left có phải toàn màu hồng?
Câu trả lời của mình là không. Việc áp dụng nó là không dễ cho bất kì team nào. Lí do cho việc đấy là nó đòi hỏi phải thay đổi mindset và cách làm việc cho việc này. Thí dụ cho việc này là pair-test, mình cũng từng cố gắng áp dụng pair-test cho team mình nhiều lần nhưng đa số là failed cả, nó chỉ mới hiệu quả gần đây. Bởi vì để làm được nó, ngoài việc bạn hiểu ý nghĩa tại sao phải làm vậy thì đồng đội của bạn cũng phải hiểu nó nữa. Thông thường mọi người đã quen làm việc theo cách cũ, nhưng nay nếu họ áp dụng shift-left thì họ phải thay đổi cách thức làm việc, process làm việc, cũng như phải tăng khả năng giao tiếp, trình bày trong những buổi demo, hơn nữa phải sử dụng thêm tools cho công việc. Một điều quan trọng nhất là làm sao tất cả các roles cùng hiểu và áp dụng đúng cách. Ví dụ như buổi demo, làm sao cho các role khác như PO, BA, và designer tham gia và đóng góp feedback.
Nhưng nó là điều đáng thử
Túm lại theo mình thì bất kì 1 cách tiếp cận nào đều có ưu và nhược điểm nhưng với shift-left testing thì nó mang lại nhiều ưu điểm hơn nhược điểm. Thứ nhất là tester sẽ không còn là bottleneck tại giai đoạn cuối của release, trách nhiệm testing là của cả team và ai cũng là người đóng góp vô quality cuối cùng của sản phẩm. Thứ hai là quality sẽ được tăng lên nhờ việc testing từ sớm, các defect được phát hiện, phòng ngừa từ giai đoạn phân tích requirement và giai đoạn development chứ không còn trễ như trước đây, do vậy chi phí sữa và nỗ lực sẽ được giảm đáng kể.