Tester

Trong nhiều năm, cách tiếp cận phổ biến để thử nghiệm đã dựa trên định nghĩa khung về chất lượng của Philip Crosby: chất lượng là mức độ phù hợp với các yêu cầu. Nếu chất lượng là mức phù hợp với yêu cầu, thì những yêu cầu đó sẽ phải được ghi lại. Điều này đã khiến nhiều chuyên gia kiểm thử theo đuổi quá mức một tài liệu yêu cầu hoàn hảo để họ có thể xác nhận rằng hệ thống phù hợp. Tuy nhiên, sự phù hợp với các yêu cầu là tốt nhưng sự phù hợp với nhu cầu của người dùng thậm chí còn tốt hơn.

Khi sử dụng Scrum, chúng ta thừa nhận rằng không thể dự đoán hoàn hảo tất cả các nhu cầu của người dùng. Giống như các developer không còn có thể nói: “Đưa cho tôi tài liệu specifications hoàn chỉnh; sau đó hãy tránh sang bên trong khi tôi làm cho hệ thống thực hiện đúng những gì được yêu cầu trong đó”, tester không thể nói: “Đưa cho tôi tài liệu yêu cầu hoàn hảo và tôi sẽ đảm bảo hệ thống thực hiện mọi thứ trong đó.” Khi nói như thế các developer hoặc tester dường như đang từ bỏ trách nhiệm tối hậu là đảm bảo cho thành công cuối cùng của dự án. Mỗi người cần phải suy nghĩ về sản phẩm và đặt câu hỏi về từng tính năng và cách nó thêm vào (hoặc bỏ đi khỏi) tổng thể sản phẩm.

Vì các nhóm Scrum khi thu thập các yêu cầu đã chuyển từ viết ra các yêu cầu sang kể về chúng, các cuộc hội thoại với  Product owner trở thành cách chính của tester để tìm hiểu cách một tính năng mới sẽ hoạt động. Tester có thể nói chuyện với  Product owner về cách thức một tính năng hoạt động, thời hạn thực hiện công việc, tiêu chí nghiệm thu nào phải được thỏa mãn, v.v… Tester không bị giới hạn trong việc thu thập thông tin này chỉ từ Product owner. Khi thích hợp, tester cũng nên nói chuyện với người dùng, khách hàng và các bên liên quan khác. Cũng như các developer, làm việc trong một môi trường tương tác như vậy có thể gây khó chịu cho những tester đang bắt đầu dịch chuyển sang Scrum. Những tester trong nhóm Scrum sẽ cần phải làm quen với các cuộc trò chuyện thường xuyên và có ý nghĩa hơn với đồng nghiệp của họ và với những người bên ngoài nhóm dự án.

Cùng với việc từ bỏ quan niệm rằng một đặc điểm kỹ thuật hoàn chỉnh có thể được viết trước, một trong những thay đổi lớn nhất đối với tester là học cách làm việc theo các sprint. Về mặt khái niệm, đây không phải là một điều khó làm. Nếu chúng ta nghĩ về mỗi sprint như thể là một dự án riêng nó, thì việc kiểm thử cho từng “dự án” sprint được thực hiện trong sprint đó. Làm việc này không đơn giản là nhóm sẽ dành hẳn tuần cuối cùng mỗi sprint chỉ để kiểm thử. Thay vào đó hãy tạo ra những chu trình waterfall (red-green-refactor, red-green-clean) thu nhỏ bên trong mỗi sprint. Trong vài sprint đầu tiên những tester sẽ phải đối mặt với một thử thách lớn. Trong thời gian đó, các developer cũng đang học cách làm việc theo vòng lặp và có lẽ cũng sẽ không giỏi cho lắm. Các developer có thể sẽ không có bất kỳ tính năng nào nằm trong kế hoạch của sprint được coding đầy đủ cho đến tận khi gần hết thời gian của sprint: họ sẽ bàn giao code cho những tester vào ngày thứ mười tám của sprint kéo dài 20 ngày! Sau khi các thành viên học cách làm việc của một dự án agile, những lần chuyển giao code sát nút như vậy sẽ không còn.

Tự động hóa thử nghiệm đang dần trở thành một đặc trưng của các nhóm Scrum. Các agile team đã vất vả trong nhiều năm để đạt được tiến bộ trong việc tự động hóa các bài kiểm thử nhận thấy rằng các sprint ngắn của Scrum làm cho tự động hóa kiểm thử là một điều cần thiết. Tự động hóa kiểm thử làm giảm sự phụ thuộc vào công tác kiểm thử thủ công của tester, những người đọc tập lệnh, nhấn nút và ghi lại kết quả. Những tester này thường được yêu cầu phải tìm hiểu một hoặc một vài công cụ tự động hóa thử nghiệm để sử dụng cho cả nhóm dự án. Một số công cụ tự động hóa thử nghiệm dựa trên việc phải lập trình để tạo ra các bài test, một số công cụ khác không đòi phải lập trình. Chỉ có một số ít tester đã quá quen làm thủ công đến mức không thể chuyển đổi sang đóng góp cho nỗ lực tự động hóa thử nghiệm của team. Nhiều người cảm thấy lo lắng khi buộc phải chuyển đổi sang kiểm thử tự động. Chỉ có rèn luyện, thực hành, được đào tạo và ghép cặp với những người có kinh nghiệm hơn (có thể đi cặp với một developer) là cách hữu hiệu để họ vượt qua nỗi sợ hãi phải thay đổi.

Lisa Crispin, đồng tác giả với Janet Gregory viết cuốn sách “Agile Testing”, nhớ lại khi cô chuyển sang làm việc trong một team agile, điều đầu tiên cô nhận thấy là cô cần phải chủ động.

Đừng ngồi chờ đợi mọi thứ đến với bạn. Hãy chủ động! Chúng tôi các kiểm thử viên không thể chờ đợi nhiệm vụ thử nghiệm đến với chúng tôi. Chúng tôi phải đứng dậy, tham gia và tìm ra những việc cần để làm. Cộng tác với các developer là điều mới mẻ đối với rất nhiều tester. Cộng tác với khách hàng cũng là điều mới mẻ. Đó là nỗi lo sợ khi ra khỏi vùng an toàn đối với nhiều người. Developer là những người bận rộn và đôi khi khó cộng tác. Khi tôi là tester duy nhất trong một nhóm gồm tám developer, mặc dù hầu hết trong số họ là những người tôi đã làm việc trong nhiều năm tại một công ty khác, phải có nhiều can đảm để yêu cầu họ giúp đỡ.

Thiết kế trải nghiệm người dùng

Người thiết kế trải nghiệm người dùng (UED User Experience Designer) thường có mối quan tâm chính đáng với việc áp dụng Scrum. Mặc dù họ đã quen với sprint, họ thích chạy các sprint trước một bước so với phần còn lại của dự án. Tuy nhiên, trong một dự án Scrum, chúng ta không muốn thực hiện tất cả các công việc của UED trước rồi mới bắt đầu các hoạt động phát triển khác. Lynn Miller (năm 2005) và Desirée Sy (năm 2007) đã viết về phương pháp mà họ đã sử dụng để tích hợp công tác thiết kế vào một quy trình agile. Theo Miller và Sy, cần có hai luồng công việc song song trong dự án: một cho phát triển và một cho thiết kế tương tác. Hình vẽ ở trên mô tả hai luồng này và sự tương tác giữa chúng. Ý tưởng cốt lõi là công việc của UED luôn đi trước công việc phát triển ít nhất một sprint. Các UED được khởi đầu sớm một dự án thông qua sự kết hợp một sprint zero (Sprint 0) với sprint thứ nhất chỉ thực hiện các feature không đòi hỏi hoặc yêu cầu rất ít về giao diện người dùng. Cách tiếp cận được trình bày ở hình trên có thể hoạt động tốt nhưng chứa đựng rủi ro khi các UED xem mình là một nhóm riêng biệt. Bất cứ khi nào tôi dạy khái niệm này, tôi luôn nhấn mạnh rằng các nhà thiết kế không nên nghĩ mình là một nhóm riêng biệt và việc giao tiếp chặt chẽ và thường xuyên là điều cần thiết để làm cho khái niệm 2 luồng công việc hoạt động được. UED phải xem mình là một phần của đội. Ý tưởng về các cross-functional team là nền tảng cho Scrum; nhóm cần bao gồm tất cả mọi nhân sự cần thiết để biến ý tưởng thành hiện thực. Tương tự như vậy một nhóm tester hoàn toàn có thể chuẩn bị một phiên bản của riêng mình để thể hiện tiến trình chạy song song của luồng công việc lập trình và luồng thử nghiệm.

Nếu tôi gặp một UED và hỏi, bạn sẽ làm gì? Tôi có thể nhận được câu trả lời là: “Tôi là nhà thiết kế trải nghiệm người dùng. Tôi làm việc một sprint đi trước các developer. Công việc của tôi là đảm bảo rằng khi họ bắt đầu sprint, tôi có thể cung cấp cho họ một thiết kế họ sẽ phát triển trong sprint đó.” Câu trả lời này cũng tương ứng với hình vẽ, nhưng nó không phải là câu trả lời tôi muốn nghe. Tôi muốn nghe thấy câu này: “Tôi đã thiết kế giao diện trải nghiệm người dùng. Tôi đã tham gia nhóm phát triển và công việc chính của tôi là đảm bảo chúng tôi hoàn thành công việc chúng tôi cam kết thực hiện cho sprint. Nhưng điều đó không chiếm hết thời gian của tôi, vì vậy tôi dành thời gian để nhìn trước những gì chúng tôi sẽ xây dựng trong một hoặc hai sprint tiếp theo. Sau đó tôi thu thập dữ liệu, mô phỏng các thiết kế để khi chúng tôi bắt tay vào làm một feature trong sprint tương lai, chúng tôi có thể hoàn thành nó trọn vẹn trong sprint đó.”

Cả hai trích dẫn hư cấu này đều mô tả cùng một ý. Trong cả hai trường hợp, các UED đang làm việc với nhóm để giải quyết các vấn đề về sprint hiện tại, nhưng họ cũng đang nhìn về phía trước. Đầu tiên và quan trọng nhất, tôi muốn các UED cảm nhận được mình là một phần của nhóm và ưu tiên hàng đầu của họ là bàn giao được các feature đã cam kết cho sprint hiện tại. Ngoài ra, công việc của họ là nghĩ trước được những thiết kế mà người dùng sẽ mong muốn.

Một agile mindset là rất quan trọng đối với UED trong việc chuyển đổi sang Scrum. Sở hữu kiến ​​thức sâu rộng về thiết kế trải nghiệm người dùng sẽ giúp bạn hiểu được làm thế nào để thay đổi phương pháp đánh giá và thiết kế truyền thống sao cho đáp ứng các mục tiêu khác nhau của team agile.

Theo Mike Cohn

Succeeding with Agile