Nhật ký: Một quy trình làm việc mới cho Team mới

Có một số sự thay đổi xảy ra trong team kiểm thử của tôi. Tôi đã viết về việc chúng tôi thay đổi cách thực hiện test như thế nào khi tôi chuyển bàn làm việc của mình vào phòng của team. Lúc đó, tôi là tester duy nhất làm việc trong project và project manager chỉ liên quan đến các công việc ở cấp cao. Quy trình tổng thế khá là đơn giản:

Product manager tạo ra một roadmap đơn giả của các tính năng cần thực hiện. Leader developer viết và quản lý sự phát triển của các user tories và giao công việc (bao gồm cả fix các lỗi) cho các developer. Tôi test các user stories và các code sửa lỗi, làm việc với leader khi tôi có câu hỏi. Leader developer và tôi xem xét kết quả test và quyết định xem các stories đã được hoàn thành hay cần phải làm thêm. Dẫn đầu một nhóm là một công việc đem lại nhiều sự thích thú, nhưng tôi không chắc mình sẽ làm gì khi quy mô của team tăng lên và có nhiều hơn một tester trong nhóm.

Những sự thay đổi yêu cầu tư duy tươi mới

Bây giờ chúng tôi đã có 3 tester trong test team. Dự án mới của chúng tôi tương đối lơn, và nó sẽ cần mọi người trong team phát triển và team kiểm thử làm việc cùng nhau. Chúng tôi có nên làm việc trực tiếp với leader developer, như tôi đã làm? Trong dự án gần nhất, khi đã từng xảy ra bottleneck, tôi là tester duy nhất. Việc ba tester cùng làm việc trực tiếp với leader developer chắc hẳn sẽ không thể có kết quả tốt.

Đó không phải là khác biệt duy nhất giữa project này và project gần nhất. Còn có nhiều những công việc khác cần phải thực hiện ở project này. Chúng tôi tạo ra bản đầu tiên của website, cái mà dần dần sẽ thay thế sản phẩm flagship của chúng tôi, và nó yêu cầu tối thiểu là 6 tuần chỉ để thực hiện regression testing. Chúng tôi sẽ xây dựng lại các tính năng của sản phẩm đó từ đầu. Nếu chúng tôi cần phải dừng lại và gặp leader developer trước và sau mỗi story trong khi anh ấy đang cố gắng kiểm soát cả công việc phát triển, chúng tôi sẽ không bao giờ hoàn thành kịp.

Cuối cùng, như tôi đã đề cập ở trên, chúng tôi có một product manager mới. Product manager cũ của chúng tôi tham gia vào việc dẫn dắt các tính năng ở level cao; cô ấy không có hứng thú với việc tham gia sâu vào từng story cụ thể. Product manager mới của chúng tôi có vẻ thích thú hơn với việc phát triển các user story và tính năng một cách chi tiết. Anh ấy thích làm việc với leader developer để viết các tiêu chí chấp nhận kết quả phát triển hơn là việc tham gia từ xa.

Thử thách mới dẫn tới một quy trình mới

Dựa trên sự thay đổi của tình huống, chúng tôi đã quyết định một quy trình phát triển bao gồm product manager và giảm thiểu sự phụ thuộc của chúng tôi vào sự tham gia cá nhân của leader develop để thực hiện việc test của chúng tôi.

Stories được viết ra bởi product manager và leader developer, và họ cùng nhau tạo ra nhưng tiêu chuẩn chấp nhận

Hiện tại, test team không tham gia vào việc thảo luận về những tiêu chuẩn chấp nhận. Khi dự án được tiếp tục, chúng tôi sẽ kiểm soát việc có tăng chất lượng ban đầu của stories bằng cách yêu cầu tham gia vào các cuộc thảo luận này hay không, nhưng chúng tôi tập trung giúp leader developer và product manager có thể xây dựng mối quan hệ làm việc của họ bằng cách cùng nhau thực hiện việc này.

Nhiều tester làm việc trong nhóm phát triển để test stories và các lỗi

Có những sự ràng buộc vật lý khi thêm ba bàn làm việc vào trong phòng của team phát triển, do đó, trong hầu hết thời gian, trong phòng làm việc chỉ có hai tester. Tôi đã khuyến khích hai tester kia vào ngồi cùng để họ có thể hưởng lợi từ sự xây dựng mối quan hệ mà tôi đã trải nghiệm ở project cũ. Tôi dự định làm việc theo cặp với họ một cách thường xuyên, để chúng tôi đôi lúc sẽ có cả ba cùng làm việc trong phòng của team phát triển.

Testers also will work with developers on questions about the implementation and with the product manager on questions about the stories. This means that rather than all questions being directed to a single individual, our questions will be spread across the development team and the product manager. Các tester cũng sẽ làm việc với các developer khi có câu hỏi về việc code và với product manager khi có câu hỏi về stories. Điều này có nghĩa rằng không phải tất cả câu hỏi sẽ hướng đến một cá nhân đơn lẻ, mà nó sẽ chia ra cho khắp nhóm phát triển và product manager.

Chúng tôi hi vọng việc này sẽ giảm thiểu khả năng xảy ra bottleneck. Nó cũng cho phép product manager trao đổi nhiều hơn trong vòng đời phát triển khi chúng tôi trao đổi những câu hỏi về các stories mới và các báo cáo về lỗi.

Đánh giá kết quả test tổng thể cùng với product manager

Thay vì đánh giá kết quả test theo từng story một, chúng tôi sẽ thông báo với product manager về tình trạng của các stories sử dụng các báo cáo test đưa ra những trạng thái tổng thể của việc test, và báo cáo những thông tin riêng biệt mà product manager mong muốn. Chúng tôi hi vọng rằng việc bao gồm cả product manager trong các đoạn trao đổi khi chúng tôi test các stories, sự hiểu biết của anh ấy về sản phẩm và cách nó được test sẽ trở nên đầy đủ hơn.

Đây là kế hoạch ban đầu để quản lý việc test trong tình trạng hiện tại của chúng tôi. Chúng tôi đã đưa vào nhiều những thứ mà chúng tôi đã được học khi tôi làm việc trong team phát triển ở dự án gần nhất, nhưng chúng tôi sẽ tiếp tục điều chỉnh trong khi dự án chạy và chúng tôi sẽ tìm ra những sự cái tiến và khắc phục những sai lầm.

Tôi háo hức được bắt đầu làm việc theo cách mới và nhận ra rằng cách làm việc của chúng tôi còn tốt hơn vì chúng tôi đã kết hợp giữa việc test và nhóm phát triển với đồng nghiệp mới của chúng tôi, anh bạn product manager.