Các bước khi thực hiện testing 1 dự án phần mềm: Đọc tài liệu

Phương thức phát triển phần mềm Agile là một cách thức làm phần mềm linh hoạt để đưa sản phẩm đến tay người dùng càng nhanh chóng và càng sớm càng tốt. Agile được xem là mô hình cải tiến hơn so với những mô hình cũ (“Thác nước (waterfall)” hay “CMMI”). Trong dự án Agile, chúng ta xây dựng một sản phẩm tốt ngay từ ban đầu, sử dụng kiểm thử để phản hồi ngay khi phát triển, nhằm tạo ra sản phẩm tương đồng với yêu cầu của khách hàng. Hoạt động kiểm thử không phải là một giai đoạn trong quá trình phát triển Agile mà là hoạt động tham gia vào quy trình phát triển ngày từ ban đầu. Cách tiếp cận Agile là tập trung vào việc xác nhận những điều đúng đắn ngay từ đầu, giảm việc nhất thiết phải có "nhiều" kiểm thử viên (QA Tester) ở cuối quy trình mới đạt được kết quả, đảm bảo tiến độ dự án được liên tục. Khi thực hiện Testing 1 dự án phần mềm, các tester cần phải trải qua các bước chính sau: 1. Đọc, tìm hiểu tài liệu dự án 2. Tạo Test Design 3. Tạo Test Plan 4. Tạo Testcase 5. Thực hiện Test, Log bug Sau đây, chúng ta sẽ cùng tìm hiểu bước đầu tiên và quan trọng trong quá trình kiểm thử: Đọc tài liệu dự án

1. Đọc và tìm hiểu tài liệu dự án - Khi bắt đầu dự án, khách hàng sẽ gửi tài liệu tổng quan về sản phẩm họ mong muốn nhận được, giúp cho nhóm phát triển hiểu rõ những yêu cầu của người dùng và trên cơ sở đó đề ra giải pháp cụ thể và ước tính giá thành. - Tuy nhiên, thực tế cho thấy, chúng ta gặp rất nhiều khó khăn trong việc thu thập đầy đủ và chính xác các yêu cầu của khách hàng để lập kế hoạch tốt ngay từ đầu. Nguyên nhân một phần do khách hàng không có kiến thức chuyên môn về kỹ thuật, tài liệu mô tả chỉ ở mức người dùng; một phần khác là do bên đội phát triển không có kiến thức chuyên môn về nghiệp vụ phía khách hàng, nên không nắm bắt được mong muốn của khách hàng. - Thông thường Tester mới thường chỉ nhìn vào tài lệu requirement và viết testcase theo tài liệu đó mà không quan tâm đến tài liệu đó có hợp lý không, có hữu ích cho người dùng cuối hay không? Tuy nhiên, trong quá trình đọc tài liệu của mô hình Agile, nếu có những vấn đề khúc mắc thì Tester cần trao đổi với team ngay để làm rõ Specs và đặt câu hỏi với khách hàng một cách hiệu quả nhằm tạo ra sản phẩm tương đồng gần nhất với yêu cầu của khách hàng. - Thực tế có những trường hợp ngay cả khi confirm với khách hàng mà vẫn chưa thể làm rõ được vấn đề, nguyên nhân là do khách hàng không hiểu về kỹ thuật, luôn thay đổi yêu cầu liên tục. Khi đó ta nên refer đến những hệ thống đã có sẵn, có chức năng tương tự để đưa ra suggestions hợp lý cho khác hàng lựa chọn. Việc tạo câu hỏi cho khách hàng cũng cần rõ ràng để tránh mất thời gian chờ đợi confirm. VD1: Thay vì hỏi "Khách hàng muốn validate khi input vào textbox username như thế nào?" thì ta nên đưa ra gợi ý rõ ràng như sau: " Tham khảo hệ thống ABC, tôi thấy rằng: Validate trường user:

• Cho nhập account có dạng 'abc@abc.com';
• Maxlength từ ... đến ... ký tự,
• Khi nhập trùng với account đã có sẵn, hệ thống hiển thị message: "..."
• Khi nhập Blank/ Space, hệ thống hiển thị message: "..."
• Khi nhập Invalid, hệ thống hiển thị message: "..."
• ...

Với ví dụ trên, ngay cả với khách hàng không hiểu gì về kỹ thuật cũng sẽ dễ dàng đưa ra quyết định do người hỏi đã gợi ý đến 1 hệ thống có sẵn, và họ có thể tìm hiểu qua hệ thống đó để đưa ra mong muốn của mình thay vì suy nghĩ các TH nào xảy ra khi input vào trường User name.

Mỗi dự án sẽ có những yêu cầu khác nhau và tài liệu đặc tả khác nhau, tuy nhiên trong quá trình tìm hiểu tài liệu nói chung chúng ta cần chú ý 4 tiêu chí sau:

• “Cá nhân và sự tương tác hơn là quy trình và công cụ” Đặt trọng tâm vào con người và sự tương hỗ giữa những thành viên trong nhóm. Nếu dự án có những thành viên có năng lực, chịu làm việc cùng nhau thì sẽ mang đến thành công cho dự án. Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn. Khi có các vấn đề liên quan đến Specs, tester cần cùng team trao đổi để giải quyết vấn đề, đưa ra và trình bày các giải pháp để sản phẩm tốt hơn với khách hàng thay vì áp đặt làm theo tài liệu ban đầu.

• “Phần mềm chạy tốt hơn là tài liệu đầy đủ” Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm Dev không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống. Nhóm Test thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm QA đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng. Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người cần đọc.

• “Cộng tác với khách hàng hơn là đàm phán hợp đồng” “Khách hàng là thượng đế” hay “khách hàng luôn luôn đúng”. Tuy nhiên có khách hàng am hiểu về công nghệ, có người không. Cách duy nhất để có thể làm việc tốt là phải cộng tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.

• “Phản hồi với sự thay đổi hơn là bám theo kế hoạch” Chúng ta phải tập thích nghi với những thay đổi, trong đó có sự thay đổi về tài liệu, yêu cầu của khách hàng. Tuy nhiên nên cố gắng giảm thiểu các thay đổi một cách tối đa bằng cách đưa ra các gợi ý ngay từ đầu để hướng khách hàng đến những lựa chọn phù hợp, có ít thay đổi nhất.

Trên đây là những chia sẻ của mình về kinh nghiệm đọc và tìm hiểu tài liệu dự án. Hi vọng sẽ giúp ích cho mọi người trong quá trình làm việc