Kiểm thử phần mềm có rất nhiều thách thức cả trong manual testing và automation testing. Nói chung, trong kiểm manual testing developers sẽ thông qua các bản build cho team test hoặc team test sẽ chọn bản build và sẽ đến hỏi bản build về những gì? Đây là trường hợp trong các tổ chức không tuân theo cái gọi là ‘quy trình. Tester là người trung gian giữa đội ngũ phát triển và khách hàng, xử lý áp lực từ cả hai phía.
Đây không phải là trường hợp luôn luôn. Đôi khi những người tester có thể gây ra những sự phiền phức trong một quy trình kiểm thử do cách làm việc thiếu kỹ năng của họ. Trong bài đăng này, tôi sẽ chỉ ra những thử thách khi kiểm thử được tạo ra do nhân viên tester, nhân viên phát triển, quy trình kiểm thử và các quyết định quản lý sai.
1) Testing the complete application (Kiểm thử hoàn thành cả ứng dụng):
Có thể không? Tôi nghĩ rằng không thể. Có hàng triệu kết hợp kiểm thử. Không thể kiểm tra từng hoặc mọi sự kết hợp cả trong manual testing cũng như automation testing. Nếu bạn thử tất cả các kết hợp này, bạn sẽ không bao giờ giao sản phẩm.
2) Misunderstanding of company processes (Hiểu sai về quy trình của công ty):
Đôi khi bạn không chú ý đúng mức những quy trình công ty đã đề ra và mục đích của chúng là gì. Có một vài quan điểm không đúng trong nghề tester rằng họ chỉ nên áp dụng với các quy trình của công ty ngay cả khi những quy trình này không được ứng dụng cho kịch bản kiểm thử hiện tại của họ. Điều này dẫn đến kiểm thử ứng dụng không đầy đủ và không phù hợp.
3) Relationship with developers (Mối quan hệ với các nhà phát triển):
Đây là thử thách lớn. Yêu cầu người kiểm thử có kỹ năng để xử lý mối quan hệ này một cách tích cực và thậm chí bằng cách hoàn thành công việc theo cách của tester mong muốn. Đơn giản là có hàng trăm lời bào chữa mà các đội phát triển hoặc tester có thể đưa ra khi họ không đồng ý với một số điểm. Đối với người kiểm thử cũng đòi hỏi kỹ năng giao tiếp, xử lý sự cố và phân tích tốt.
4) Regression testing (Kiểm tra hồi quy):
Khi một dự án tiếp tục mở rộng, công việc kiểm tra hồi quy đơn giản trở nên khó kiểm soát. Áp lực để xử lý các thay đổi chức năng hiện tại, kiểm tra chức năng làm việc trước đó và theo dõi lỗi.
5) Lack of skilled testers (Thiếu người kiểm tra có tay nghề):
Tôi sẽ gọi đây là “quyết định quản lý sai” trong khi chọn hoặc đào tạo người kiểm thử cho công việc dự án. Những đồng nghiệp thiếu kỹ năng này có thể thêm nhiều hỗn loạn hơn là đơn giản hóa công việc kiểm thử. Điều này dẫn đến kiểm thử không đầy đủ, không đầy đủ trong suốt quá trình kiểm thử.
6) Testing always under time constraint (Kiểm tra luôn trong thời gian hạn chế):
Hey tester, khách hàng muốn nhận sản phẩm này vào cuối tuần này, bạn đã sẵn sàng để hoàn thành chưa? Khi có quyết định này từ phía khách hàng, tester chỉ tập trung vào hoàn thành nhiệm vụ chứ không tập trung vào phạm vi kiểm tra và chất lượng công việc. Có một danh sách lớn các nhiệm vụ mà bạn cần hoàn thành trong thời gian quy định. Điều này bao gồm viết, thực thi test, tự động hóa và xem xét các trường hợp kiểm thử.
7) Which tests to execute first? (Kiểm thừ gì đầu tiên):
Nếu bạn đang đối mặt với thử thách được nêu ở điểm 6, thì bạn sẽ đưa ra quyết định những trường hợp kiểm thử nào sẽ được thực hiện và với mức độ ưu tiên nào? Hãy xem xét những quan điểm nào là quan trọng hơn những quan điểm khác? Điều này đòi hỏi kinh nghiệm tốt để làm việc dưới áp lực.
8) Understanding the requirements (Hiểu các yêu cầu):
Đôi khi tester có trách nhiệm giao tiếp với khách hàng để hiểu các yêu cầu. Điều gì xảy ra nếu tester không hiểu các yêu cầu? Liệu anh ta có thể kiểm tra ứng dụng đúng cách? Tất nhiên là không! Người kiểm tra đòi hỏi khả năng nghe và hiểu tốt.
9) Automation testing:
Nhiều thách thức phụ – Có nên tự động hóa công việc kiểm thử? Bạn có đủ nguồn lực và kỹ năng cho tự động hóa? Thời gian liệu cho phép để tự động hóa các trường hợp thử nghiệm? Quyết định tự động hóa hoặc thử nghiệm thủ công sẽ cần phải giải quyết phụ thuộc vào từng quy trình phát triển dự án.
10) The decision to stop the testing (Quyết định dừng thử nghiệm):
Khi nào dừng kiểm thử? Quyết định rất khó khăn. Yêu cầu đánh giá cốt lõi của các quá trình kiểm thử và tầm quan trọng của từng quá trình.
11) One test team under multiple projects (Một nhóm thử nghiệm theo nhiều dự án):
Thử thách để theo dõi từng task của nhiều dự án. Thử thách giao tiếp. Nhiều lần dẫn đến thất bại của một hoặc tất cả dự án.
12) Reuse of Test scripts (Tái sử dụng các kịch bản kiểm thử):
Các phương thức phát triển ứng dụng đang thay đổi nhanh chóng, gây khó khăn cho việc quản lý các công cụ kiểm thử và kịch bản kiểm thử. Việc tái sử dụng các kịch bản kiểm thử là rất cần thiết nhưng là công việc khó khăn.
13) Testers focusing on finding easy bugs (Người kiểm tra tập trung vào việc tìm kiếm các lỗi dễ dàng):
Nếu tổ chức thưởng cho người kiểm tra dựa trên số lỗi (cách tiếp cận rất tệ để đánh giá hiệu suất của người kiểm thử) thì một số người kiểm thử chỉ tập trung vào việc tìm lỗi dễ dàng mà không cần phải hiểu sâu hệ thống. Những lỗi sâu của chức năng vẫn không được chú ý trong phương pháp kiểm thử như vậy.
14) To cope with attrition (Để đối phó với rủi ro):
Tăng lương và lợi ích khiến nhiều nhân viên rời công ty trong khoảng thời gian làm việc rất ngắn. Quản lý đang phải đối mặt với các vấn đề khó khăn để đối phó với ruit ro về nhân sự. Thách thức – Người kiểm thử yêu cầu đào tạo dự án ngay từ đầu, dự án phức tạp rất khó hiểu, chậm trễ trong thời gian bàn giao!
Đây là một số thách thức kiểm thử phần mềm hàng đầu mà chúng ta phải đối mặt hàng ngày. Dự án thành công hay thất bại phụ thuộc phần lớn vào cách bạn giải quyết những vấn đề cơ bản này.