7 mục tiêu quan trọng hàng đầu của một người kiểm thử phần mềm

Trở thành một QA trong ngành công nghiệp phần mềm, là một trách nhiệm lớn, giống như là:

• Một người đọc thử, người sẽ phải đọc lại từng chữ, được viết bởi tác giả.
• Một nhà thiết kế thời trang, người sẽ phải tự mình thử quần áo của nhà thiết kế, trước khi đưa chúng ra trưng bày.
• Một nhà khoa học, người sẽ phải làm nghiên cứu và phát triển để hiểu tác động của việc thực hiện. Trong phần lớn sự nghiệp của mình, tôi đã thấy những người QA tạo ra do thiếu các lựa chọn nghề nghiệp khác, thiếu kiến thức kỹ thuật, v.v., thay vì những người đã tự nguyện lựa chọn nghề kiểm thử phần mềm.

Tôi nghĩ bắt đầu bằng cách nào nó không quan trọng, miễn là bạn đầu tư thời gian và công sức để có được kinh nghiệm và hiểu được các kỹ thuật của lĩnh vực này.

Như chúng ta vẫn thường nói: "một người thử nghiệm đam mê có lợi hơn một nhà phát triển có kinh nghiệm."

Hầu hết QA đều xác nhận các tính năng của phần mềm và xem xét kỹ sản phẩm / ứng dụng để tìm ra lỗi trong đó. Nhưng nó không phải là mục tiêu duy nhất.

Là một người QA, bạn phải làm nhiều việc khác ngoài những nhiệm vụ chính là tìm bug. Hãy để tôi giải thích dưới đây.

Là một QA:

1) Bạn phải tìm lỗi

Mục tiêu chính của bất kỳ QA nào là tìm ra lỗi trong sản phẩm / ứng dụng. Tìm lỗi không nên giới hạn trong việc tìm lỗi. Nó nên được mở rộng để báo cáo hiệu quả, xác định mức độ nghiêm trọng & xử lý và truyền đạt chúng cho developer.

Và điều quan trọng nhất là, không bao giờ cảm thấy rằng bạn đã quan sát / báo cáo tất cả các lỗi bởi vì như họ nói,

Bạn đã đếm tất cả những cây không có nghĩa là bạn đã nhìn thấy khu rừng.

Tìm kiếm chi tiết, xem xét những điều nhỏ nhặt và khi QA áp dụng kiến thức và kinh nghiệm, các lỗi trở nên dễ dàng nhìn thấy và đôi khi, nguyên nhân gốc rễ cũng vậy.

2) Ngăn chặn lỗi

Ngăn chặn tốt hơn là tìm kiếm, đối với một người kiểm thử phần mềm. Khi bạn thấy lỗi, hiểu mô hình, hiểu suy nghĩ của dev và hiểu hành vi của sản phẩm.

Hầu hết thời gian, cùng một loại lỗi có thể xảy ra hoặc trong phần khác của ứng dụng vì cùng một dev đã phát triển nó hoặc logic được sử dụng là giống nhau hoặc hệ thống được xử lý theo cách tương tự.

Do đó, một khi tìm thấy lỗi, hãy tìm những nơi có thể khác có thể tồn tại lỗi liên quan, báo cáo chúng và hỗ dev thực hiện fix lỗi tại tất cả các vùng ảnh hưởng có liên quan.

3) Đánh giá chất lượng sản phẩm

Kiểm thử phần mềm không phải là tìm lỗi, nó chỉ là trách nhiệm chính của người kiểm thử. Mục tiêu chính của người kiểm thử phần mềm là đánh giá chất lượng sản phẩm và cung cấp hình ảnh thực cho các bên liên quan.

Hầu hết, người quản lý không quan tâm đến bug như thế nào và số lượng bug bạn đã báo cáo là bao nhiêu. Họ quan tâm đến việc liệu sản phẩm có thể bàn giao được hay không.

Và hãy tin tôi; chỉ người kiểm thử phần mềm mới có thể trả lời câu hỏi đó vì họ biết tình trạng hiện tại của sản phẩm. Và do đó:

Mục tiêu chính của kiểm thử phần mềm là tạo niềm tin cho phần mềm.

4) Đề xuất các ý tưởng

Dựa trên kinh nghiệm, tester phải luôn sẵn sàng cung cấp các đề xuất để làm cho sản phẩm hiệu quả hơn, thân thiện với người dùng hơn.

Nhưng để tìm hiểu các sản phẩm khác, bạn cần hiểu tại sao các ứng dụng phổ biến lại phổ biến, bạn cần nhận ra lý do tại sao các sản phẩm khác thất bại, bạn cần phân tích xu hướng và nhu cầu thị trường từ người dùng là gì.

Học hỏi không ngừng có thể khiến bạn tự tin và mang lại sự tin cậy cũng như sức nặng cho ý tưởng của bạn, bởi vì

Chất lượng không bao giờ là ngẫu nhiên; nó luôn là kết quả của sự nỗ lực thông minh.

5) Truyền đạt những khó khăn thực tế

Là một khách hàng, tôi luôn muốn sản phẩm của mình được giao đúng hẹn và không có lỗi. Nhưng là một người thử nghiệm, tôi biết, những khó khăn là gì khi triển khai một ý tưởng thành phần mềm và xác minh xem nó có đúng hay không.

Hầu hết deadline bị quá hạn và có những sai sót trong việc trao đổi về nó. Học để trở thành một người giao tiếp tốt. Ủng hộ chất lượng sản phẩm và trải nghiệm người dùng, bởi vì

Sự cay đắng của chất lượng kém vẫn còn lâu sau khi sự ngọt ngào của schedule đã bị lãng quên.

6) Tuân thủ theo schedule chặt chẽ

Khi đề xuất effort của QA là 1 tuần so với 2 tuần phát triển, chỉ có QA mới biết rằng anh ta sẽ không có được hơn 2 ngày để kiểm thử.

Tất cả sự thỏa hiệp về lịch trình đang được thực hiện bằng cách hy sinh thời gian và lịch trình thử nghiệm. Và kết quả? Chà, với tư cách là một khách hàng, bạn có bao giờ muốn nghe lập luận rằng chất lượng sản phẩm không tốt chỉ vì QA không có đủ thời gian không?

7) Duy trì niềm đam mê

Có nhiều thời điểm trong sự nghiệp của QA mà họ cảm thấy vô dụng, không tìm thấy bất kỳ nguồn khích lệ nào, hay cần học cách xử lý các tình huống khác nhau, làm thế nào để đối mặt với những ý kiến phê bình về QA, làm thế nào để liên tục và tích cực phấn đấu cho chất lượng và cuối cùng là làm thế nào để giữ niềm đam mê cho chất lượng sống, đó là yếu tố quan trọng nhất.

Phần kết luận

Một người kiểm thử phần mềm cần phải là một người toàn diện chứ không chỉ đơn giản là một người kiểm thử vì một dự án được bàn giao dựa trên chuyên môn, tầm nhìn, giao tiếp, sự tự tin và nỗ lực của họ.

Vì vậy, những người thử nghiệm, không chỉ tập trung vào việc tìm lỗi mà phải thấy được tầm nhìn lớn hơn về chất lượng của một sản phẩm.

Bài viết tham khảo và dịch từ nguồn: https://www.softwaretestinghelp.com/goals-of-a-software-tester/