Nghề QA trong thế giới Agile (Part 2)

Giúp tầm nhìn và mục tiêu của dự án được rõ ràng

Khi cả nhóm làm việc trong suốt quá trình testing cũng như các công việc khác, QA nên đi đầu trong việc lập kế hoạch, tổ chức team vào trong các hoạt động testing và giữ “lửa” cho tất cả các thành viên. Vì rất ít các Developers thích thú với công việc testing cho nên QA, cùng với Scrum Master, phải làm cho tầm nhìn và mục tiêu testing được rõ ràng và giúp giữ vững và nâng cao tinh thần cho các đồng nghiệp. Nó có thể đến từ nhiều cách và không nhất thiết phải gò bó vào một khuôn khổ. Ví dụ: những kịch bản testing thú vị, những dữ liệu testing hài hước, các cuộc thi nhỏ mang tính chất khích lệ, v.v.

Cộng tác với Clients và Developers

Một trong những trách nhiệm chính của QA là đưa ra cũng như thu thập những phản hồi cho Product Owner. QA sẽ phối hợp rất chặt chẽ với Product Owner để giúp họ phát triển các tiêu chí chấp nhận cho các User story. Dựa vào những bài học rút ra trong suốt mỗi Sprint, QA có thể giúp Product Owner chỉnh sửa cũng như cải tiến các User Story sẵn có để mô tả chính xác các yêu cầu. Đôi khi, QA cũng sẽ được yêu cầu thay thế vai trò cho Product Owner. Lúc này, QA và Developers sẽ ngồi lại để nâng cao chất lượng của dự án bằng cách viết những test cases cho kiểm thử đơn vị (Unit test) và trao đổi về tiêu chí chấp nhận. Bằng cách này, các yêu cầu sẽ trở nên rõ ràng hơn, giảm thiểu số lượng câu hỏi và thắc mắc đến từ Developers trong suốt quá trình coding, đồng thời nâng cao hiệu quả và tiết kiệm thời gian/chi phí cho cả đội Developers lẫn QA. Toàn bộ nhóm nên sẵn sàng tham gia hỗ trợ công việc testing bất cứ khi nào dựa trên nhu cầu và sự sẵn có của các thành viên trong nhóm. Việc này cũng giúp tạo sự cân bằng trong nhóm và nâng cao tinh thần chia sẻ trách nhiệm để hoàn thành công việc. Nó cũng giúp tăng tốc độ làm việc với những phản hồi đến từ việc testing sớm cũng như gia tăng chất lượng của dự án.

Phản hồi nhanh chóng

Chu kỳ phát triển – kiểm thử - sửa lỗi trong mô hình Waterfall truyền thống tốn rất nhiều thời gian cũng như công sức cho cả nhóm khi sự lặp lại của nó dường như là vô tận. Chu kỳ này đơn giản hơn rất nhiều trong Scrum khi QA và Developers làm việc cùng nhau trong suốt cả dự án. Developer có thể hỏi ý kiến của QA về các tiêu chí chấp nhận hoặc kết quả mong đợi của bất kì tính năng nào trên phương diện người dùng một cách nhanh chóng, giúp tiết kiệm rất nhiều thời gian và loại bỏ rất nhiều lượt sửa lỗi.

Kiểm thử tự động

Sự ổn định, hiệu suất cao và độ bao phủ lớn là những ưu điểm không thể chối cãi của kiểm thử tự động (Automation Testing). Điều này luôn đúng trong một dự án Scrum nơi chu kỳ của một sprint chỉ từ 2 tới 4 tuần, vốn rất hạn chế thời gian testing của QA. Trong suốt 2 tuần đó, QA phải thực hiện kiểm thử hồi quy (Regresion Test) cho tất cả các tính năng đã hoàn thiện trước đó. Và điều này trở nên kinh khủng hơn khi mà cứ mỗi sprint qua đi, số lượng tính năng lại càng nhiều thêm. Automation testing là cứu cánh cho các QA trong trường hợp này. Automation testing rất hữu ích khi nó liên tục phản hồi kết quả testing khi team thiết lập các công cụ Tích hợp liên tục (Continuous Integration). Cứ mỗi khi có một build mới, automation test lại được thực thi và lập tức trả những kết quả kiểm tra những tính năng mới cũng như những tính năng đã hoàn thiện trước đó có hoạt động đúng hay không. Nếu không có automation testing, QA phải làm những công việc này một cách thủ công một cách nhàm chán và dễ sai sót. Automation Testing còn giúp phát hiện lỗi sớm và cho phép các QA có thêm thời gian để thực hiện test các khía cạnh liên quan của chức năng đó... (còn tiếp)