NỘI DUNG BÀI VIẾT
Tìm hiểu nội dung phát triển của sprint
Thường các ticket về nội dung phát triển phần mềm sẽ được tạo ra trước buổi họp refinement. Việc đọc lướt qua một lượt các ticket này giúp Tester có thể hình dung được các tính năng mới, và tìm hiểu thêm về các specification có liên quan.
Lắng nghe giải thích về nội dung của các ticket
BA – PO team chính là những người hiểu rõ về hệ thống và mục đích của các chức năng mới nhất. Chính vì vậy việc lắng nghe BA giải thích nội dung ticket của các màn hình và chức năng mới sẽ giúp Tester hiểu rõ hơn về chúng. Nhờ đó việc thiết kế testcase và tiến hành kiểm thử cũng sẽ trở nên dễ dàng và chính xác hơn nhiều.
Ghi lại những lưu ý để tránh thiếu xót
Ghi lại Những ý chính của tính năng/màn hình mới – Những điểm cần chú ý – Những phần chưa hiểu rõ – Các câu hỏi và ý kiến của chính Tester. Vì không thể ghi nhớ chắc chăn toàn bộ các nội dung đó nên lời khuyên là Tester nên ghi lại chúng, suy nghĩ thêm và có thể đặt câu hỏi sau đó.
Lắng nghe Developer trình bày
Teste thường thì không hiểu rõ về coding, nên sẽ khó phán đoán được mức độ khó, dễ khi phát triển một tính năng mới của phần mềm. Vậy nên thông qua các ý kiến của DEV,Tester có thể nắm bắt được các khó khăn khi phát triển các tính năng mới này để dễ hợp tác hơn. Có thể sau khi tham khảo ý kiến của developer, PM hay BA sẽ nhất trí thay đổi một vài điểm để dễ dàng cho việc phát triển hệ thống. Và cũng lúc này Tester có thể học hỏi và tích lũy thêm kinh nghiệm.
Xác nhận lại các nội dung liên quan nếu cần
Tester nên đọc lại để hiểu rõ nội dung ticket, specification, hỏi lại nếu cần. Tìm hiểu lại các bug trước đó có liên quan trong khi triển khai, bao gồm cả bug còn tồn tại lẫn các bug đã được giải quyết. Liên kết với các chức năng, màn hình liên quan để tìm ra phạm vi ảnh hưởng…. Những đièu này giúp Tester tìm ra lỗ hổng trong logic, các phần thiếu/thừa trong ticket, các phạm vi ảnh hưởng, các phần cần lưu ý để tránh sai sót, các bug đã có và phán đoán ảnh hưởng của chúng lên các tính năng mới cũng như việc phát triển hệ thống.
Vì có những điểm rất nhỏ trong specification thường bị bỏ sót nhưng đôi lúc sẽ dẫn đến ảnh hưởng rất lớn cho các tính năng và toàn bộ hệ thống, nên việc đọc lại là “không thừa”. Không chỉ team PM, BA, developer mà chính các Tester cũng khó để có thể ghi nhớ hết được những kiến thức domain, các chức năng, màn hình liên quan mà không tìm hiểu lại specification.
Tester đưa ra câu hỏi, ý kiến với đội nhóm
Thông qua việc đưa ra các câu hỏi, ngòai việc developer cũng sẽ có thêm cái nhìn toàn diện hơn về nội dung của màn hình và các tính năng mới, mà việc thiết kế testcase cũng như tiến hành kiểm thử của Tester sẽ trở nên thuận lợi hơn.
Tương tự như vậy, những ý kiến của Tester cũng góp phần rất quan trọng đối với dự án. Từ quan điểm và cái nhìn của Tester, mọi người trong nhóm đều có thể góp phần cải thiện các tính năng, tìm ra lỗ hổng trong nội dung ticket, giảm thiểu rủi ro trước khi tiến hành phát triển và release. Việc này không chỉ giúp giảm thiểu thời gian và chi phí sửa lỗi, mà còn góp phần hoàn thiện hệ thống tốt hơn.
Phản hồi về giải đáp và ý kiến của PM team, BA team và developer team
Sau khi nhận được câu hỏi và ý kiến từ Tester, các team khác sẽ bàn bạc lại về specification cũng như phương hướng giải quyết và đưa ra câu trả lời. Tester cũng sẽ hiểu rõ hơn về specification, giải quyết được những hiểu lầm của chính bản thân. Cũng có trường hợp specification và nội dung ticket sẽ được thay đổi, Tester sẽ lưu ý lại để chuẩn bị cho việc thiết kế testcase và tiến hành kiểm thử.
Xem thêm: Khóa học Tester ở Hà Nội
