12 nhiệm vụ của một kỹ sư kiểm thử Agile chuyên nghiệp - P2
7. Xác thực các bản vá Được rồi, đây không phải chuyện gì mới mẻ. Từ trước tới giờ bạn vẫn cứ phải xác thực các bản vá lỗi đó thôi. Nhưng những bản vá này có thể đã được thực hiện hàng tuần thậm chí hàng tháng trước, và bạn chỉ có thể kiểm thử chúng khi một bản build đầy đủ được chuyển tới cho ...
7. Xác thực các bản vá
Được rồi, đây không phải chuyện gì mới mẻ. Từ trước tới giờ bạn vẫn cứ phải xác thực các bản vá lỗi đó thôi. Nhưng những bản vá này có thể đã được thực hiện hàng tuần thậm chí hàng tháng trước, và bạn chỉ có thể kiểm thử chúng khi một bản build đầy đủ được chuyển tới cho QA. Trong mô hình Agile, mục tiêu là sửa và xác thực trong cùng một sprint, bởi nếu không thì các kiểm thử sẽ không thành công và các kịch bản người dùng sẽ không thể được công nhận là "hoàn thành". Trong các tổ chức lớn hơn, có thể vẫn có trường hợp mà không thể nào vá một lỗi trong cùng một sprint, có lẽ là do bạn đang làm việc với một bộ phận của tổ chức mà không tương đồng về mục đích với bạn. Rất nhiều tổ chức bao gồm một sprint để cải tiến và lên kế hoạch, cho phép bạn xác thực các bản vá muộn hơn, nhưng vẫn nằm trong tổ hợp các sprint có nhiệm vụ tạo ra các tăng cường cho sản phẩm.
8. Tham gia các buổi Daily Meetings
Việc tham dự và đóng góp cho các buổi daily meeting là rất quan trọng. Để thực sự hiệu quả, đừng chỉ nói về những gì bạn đã hoàn thành hôm qua và những gì bạn định sẽ làm hôm nay. Phần quan trọng nhất của một buổi daily meeting là chia sẻ các chướng ngại mà sẽ ngăn cản bạn thực hiện công việc của một Tester trong team. Tập trung vào việc chỉ ra và mô tả những khó khăn này với phần còn lại của team và ghi ra những gì team có thể giúp đỡ để gỡ bỏ chúng. Những điều cần phải nói nên bao gồm việc review những bước cụ thể để tái hiện bug, quyết định bug nào cần được vá đầu tiên bởi vì chúng là vật cản để test phần còn lại của hệ thống, và những điều tương tự vậy.
9. Theo dõi các số liệu
Lúc trước, khi bạn còn là một phần của team QA, bạn tuân theo các số liệu quan trọng với tổ chức của bạn, ví dụ như trạng thái của Requirement, số lượng bug bị degrade, etc. Giờ đây, bạn sẽ phải nhìn vào một bộ số liệu mới mà bạn cần phải theo dõi như một phần của tổ chức mô hình agile, ví dụ như tiến dộ sprint, tốc độ, và tiến độ bàn giao sản phẩm cuối cùng.
10. Thất bại
Phải, bạn được phép thất bại. Điều đó là bình thường. Bạn thậm chí có thể nói rằng trách nhiệm của bạn là phải thất bại một đôi lần, nhưng chỉ khi nào mà bạn thất bạn chóng vánh và học được bài học từ những sai lầm đó. Trong phát triển phần mềm truyền thống, thất bại không chỉ làm nhụt chí mà còn thường để lại hậu quả nặng nề.. Trong agile, sai lầm được chấp nhận, và các bài học rút ra từ sai lầm được chia sẻ với cả team. Sự hỗ trợ từ cấp quản lí để xử lí sai lầm là tối quan trọng trong sự thành công của mô hình agile trong doanh nghiệp.
11. Tiếp nhận sự thay đổi
Giờ đây, bạn phải thử nguyên tắc thứ hai đằng sau mô hình Agile: Chào đón các Thay đổi. Chỉ mỗi việc chuyển đổi sang mô hình Agile đã là một sự thay đổi lớn, nhưng giờ đây khi bạn đã theo agile, bạn phải sẵn sàng với việc không chỉ dự đoán các thay đổi mà cả việc chấp nhận giải quyết chúng. Trong mô hình truyền thông, một sự ngắt quãng nhỏ trong quá trình phát triển có thể làm tê liệt cả dự án. Nhưng trong agile, bất kì kịch bản người dùng nào mà đã được coi là "hoàn thành" thì có thể yên tâm được rồi. Bởi liên tục tinh chỉnh và rà soát lại bảng phân chia công việc là một phần của agile, nên team có thể xử lí và chấp nhận các gián đoạn. Nạn nhân chính duy nhất của những gián đoạn này trong agile chỉ là sprint hiện tại mà thôi, bởi vì bạn nhắm tới những sprint ngắn, nên sẽ chỉ có cùng lắm hai tuần làm việc bị ảnh hưởng.
12. Học tập
Bạn luôn luôn phải bắt kịp với sản phẩm mà mình kiểm thử và các công nghệ mà bạn gặp phải, ngoài chuyện kiểm thử ra. Nhưng giờ đây khi bạn đã ở trong một tổ chức agile, bạn sẽ cần phải học về chính agile, bao gồm cả những gì hợp và không hợp với bạn. Thay đổi những gì cần thiết, và liên tục rà soát lại xem chúng có đang hoạt động tốt không hay là cần phải sửa chữa hoặc hủy bỏ.
Những thói quen và trách nhiệm mới
Trước đây, bạn còn là một tester trong QA team. Giờ đây, bạn là thành viên của một team lập trình agile làm việc với những team agile khác trong công ty của bạn. Để chuyển đổi vị thế đó, bạn cần phải tạo lấp các thói quen mới và nắm giữ những trách nhiệm mới. Thấu hiểu những nhiệm vụ trên sẽ giúp bạn và các thành viên team bạn tối ưu hóa những đóng góp của họ trong một tổ chức agile. Bạn có ý kiến gì về chúng không? Bạn có muốn bổ sung gì không? Điều đó là do chính bạn tự quyết định.
(Hết)