Phát triển Agile và kiểm thử Agile là hai thuật ngữ riêng biệt tiếp tục gây nhầm lẫn cho nhiều cá nhân. Quá trình phát triển dự án Agile tuân thủ Agile Manifesto và các khái niệm chung được chia sẻ bởi tất cả các phương pháp Agile.
Danh sách các nguyên tắc "kiểm thử" Agile của chúng tôi xuất phát một phần từ những ý tưởng này. Do di sản Lập trình cực đoan được chia sẻ của chúng tôi, chúng tôi đã kế thừa nhiều niềm tin cốt lõi và nguyên tắc hướng dẫn của nó. Ngoài ra, chúng tôi đã tích hợp các quy tắc và ý tưởng đã được chứng minh là hiệu quả cho các nhóm của chúng tôi. Niềm tin và nguyên tắc của nhóm sẽ hướng dẫn bạn khi bạn lựa chọn các phương pháp thực hành và đưa ra quyết định về cách bạn muốn làm việc.
Chúng tôi tin rằng các khái niệm sau đây rất quan trọng đối với một Agile Tester:
Cho rằng các dự án Agile được thúc đẩy bởi các bài kiểm tra, không có gì ngạc nhiên khi phản hồi đóng một vai trò quan trọng trong các nhóm Agile. Vai trò truyền thống của người kiểm thử với tư cách là "nhà cung cấp kiến thức" khiến họ thực sự có giá trị đối với một nhóm Agile. Một trong những đóng góp thiết yếu nhất của Agile tester là hỗ trợ chủ sở hữu sản phẩm hoặc khách hàng trình bày rõ ràng các yêu cầu cho từng câu chuyện dưới dạng các ví dụ và kiểm thử. Sau đó, người kiểm thử cộng tác với đồng nghiệp để phát triển các bài kiểm tra có thể thực hiện được dựa trên các tiêu chí này. Tester, lập trình viên và các thành viên khác trong nhóm hợp tác để thực hiện các kiểm tra này thường xuyên và sớm để liên tục được hướng dẫn bởi phản hồi hữu ích.
Trong cuốn sách này, chúng tôi sẽ dành nhiều nỗ lực để giải thích cách thực hiện điều này. Khi nhóm gặp khó khăn, phản hồi có thể được sử dụng để hỗ trợ loại bỏ chúng. Chúng tôi không thể cung cấp giao diện người dùng đáp ứng mong đợi của khách hàng? Hãy tạo một thẻ nhiệm vụ để nhắc chúng ta cộng tác với khách hàng trên các nguyên mẫu giấy của câu chuyện giao diện người dùng tiếp theo.
Ban quản lý có quan tâm đến việc công việc đang tiến hành như thế nào không? Hiển thị một biểu đồ lớn có thể nhìn thấy về các bài kiểm tra hàng ngày được chuẩn bị, thực hiện và thông qua. Hiển thị phạm vi phủ sóng chức năng quy mô lớn, chẳng hạn như ma trận kiểm thử. Có khó khăn ổn định xây dựng? Nhóm của Lisa đã đăng số ngày trước thời điểm phát hành bản dựng để mọi người tập trung vào việc hoàn thành các câu chuyện đúng hạn. Sau khi nó trở thành thói quen, họ không còn cần tín hiệu hình ảnh nữa.
Phát triển Agile đòi hỏi phải cung cấp giá trị trong các bản phát hành nhỏ chứa khả năng chính xác mà khách hàng đã ưu tiên gần đây. Thông thường, điều này liên quan đến việc giới hạn phạm vi. Rất dễ bị phân tâm bởi nhu cầu của nhóm khách hàng về các tính năng thú vị. Bất cứ ai cũng có thể phản đối những sửa đổi này, nhưng những người kiểm tra thường nhận ra tác động của chúng đối với câu chuyện vì họ phải xem xét các phân nhánh kiểm tra.
Người kiểm tra Agile duy trì một quan điểm rộng. Chúng tôi có thể cung cấp chức năng quan trọng nhất trong lần lặp lại này và thêm vào chức năng đó trong các lần lặp lại tiếp theo. Nếu chúng tôi cho phép các tính năng bổ sung được đưa vào, chúng tôi có nguy cơ không đáp ứng thời hạn của mình. Nếu chúng ta quá bận tâm đến các trường hợp cạnh và bỏ qua chức năng cơ bản trên con đường hạnh phúc, chúng ta sẽ không đáp ứng được nhu cầu của công ty.
Những người kiểm thử Agile sử dụng cùng một phương pháp. Mặc dù một trong những điểm mạnh của nhóm Agile là xác định các trường hợp kiểm thử nằm ngoài kế hoạch, nhưng trước tiên chúng tôi phải đảm bảo rằng các kế hoạch đó hoạt động. Sau đó, chúng ta có thể thêm các bài kiểm tra phủ định và đường viền, đồng thời tự động hóa các bài test cho dự định trước đó. Hãy luôn xem xét điều gì mang lại nhiều giá trị nhất cho người tiêu dùng và nhận thức được bối cảnh của bạn. Thêm các kiểm thử vào một ứng dụng chú trọng về bảo mât là điều cơ bản phải làm. Trong giai đoạn ước tính, thời gian kiểm thử phải được xem xét để đảm bảo phân bổ đủ thời gian cho việc lặp lại để tạo ra tính năng "an toàn".