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.
Những việc cần lưu ý của Tester khi khách hàng gửi SPECs:
1. Đọc SPECS
Trong các dự án, đặc biệt là các dự án phần mềm chúng ta sẽ 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 sản phẩm (SPECS) để lập kế hoạch tốt ngay từ đầu. Có quá nhiều vấn đề gây ảnh hưởng đến việc phát triển phần mềm. Trong khi đó có quá nhiều vấn đề mà chúng ta không lường trước được. Những vấn đề này có thể đến từ những yếu tố như kinh doanh, kỹ thuật, con người ....
Trong quá trình tìm hiểu tài liệu từ khách hàng 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ưởng là đặ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. Cơ bản là 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. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người. Có một câu bằng tiếng Anh khá phổ biến nói về điều này là “a fool with a tool is just a fool”

  • “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 thì khách hàng có đủ loại khách hàng. Có khách hàng am hiểu về công nghệ, có người không. Có người suy nghĩ nhất quán có người thay đổi xoành xoạch, có người lạnh lùng có người cười nói suốt ngày, v.v và 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”
    Có một điểm chung mà mình thấy trong hầu hết những dự án mình đã trải qua đó là không có dự án nào không có sự thay đổi điều chỉnh khi thực thi. Sự thay đổi đó có thể là thay đổi về yêu cầu, thay đổi công nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc, v.v mặc dù kế hoạch đã được định ra rõ ràng từ đầu. Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi.

Chính vì vậy, trong quá trình đọc tài liệu, nếu có những vấn đề khúc mắc thì Tester cần trao đổi với team để làm rõ Specs và đặt câu hỏi với khách hàng một cách hiệu quả để làm rõ specs ngay từ đầu 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

2. Tạo Testcase
Trong quá trình tạo testcase, cần quan tâm đến những vấn đề:
2.1 Confirm GUI
GUI là giao diện của hệ thống/ apps cần kiểm thử. Kiểm thử GUI là đảm bảo GUI đúng với yêu cầu của khách hàng

2.2 Confirm Value
Confirm các giá trị hiển trị trên hệ thống/ apps:

  • Confirm giá trị mặc định
  • Confirm các giá trị lấy ra

2.3 Confirm Function

  • Confirm từng Function của từng Module
  • Confirm Ảnh hưởng của Function đó với các module khác

3. Thực hiện Test
Ta có thể tham khảo bài viết: https://viblo.asia/p/mot-so-van-de-tester-can-luu-y-khi-tham-gia-vao-qua-trinh-test-bxjvZBAOvJZ
Trong quá trình tìm hiểu Specs và tạo testcases sẽ có những TH specs không đầy đủ, ngay cả khi confirm với khách hàng cũng chưa thể làm rõ được vấn đề. 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. VD:
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: "..."
  • ...