Cuộc giải phẫu của một QA

Nếu Dev team là trung tâm của một dự án, và các PM là bộ não, thì các kỹ sư QA sẽ là dòng máu của nó. Nếu không có QA, các lập trình viên không thể đưa máu đến não, và kết quả cuối cùng quá rõ ràng - một dự án thất bại.

Là một kỹ sư QA sáu năm trên cả hai dự án phần mềm và phần cứng, tôi có thể nói rằng vị trí này vào những thời điểm khó khăn để chiến đấu. Vậy tôi đang nói gì? Nó áp đảo tất cả các thời gian! Khi là một QA bạn chịu trách nhiệm đầy đủ của lỗ hổng thiết kế và lỗi thậm chí nếu bạn không làm gì để tạo ra một trong hai vấn đề trên. Câu hỏi đặt ra là tại sao lại xảy ra như vậy? Bởi vì đó là công việc của bạn để tìm thấy những lỗi đó và tái hiện nó. Nhất là khi QA không phải là lập trình viên, cũng không phải là PM của dự án, bạn chỉ là người trung gian.

Bạn thấy đấy, công việc không chỉ bao gồm tìm kiếm các lỗi hay khiếm khuyết, đó là về tái hiện nó theo một cách mà một lập trình viên thấy hữu ích và là một cách mà một đội ngũ phát triển sản phẩm có thể hiểu được. Đó là hai ngôn ngữ khác nhau. Sử dụng ngôn ngữ sai tạo ra tiếng ồn và không hữu ích cho bất cứ ai.

Ngoài ra còn có các trường hợp qua quá trình communication giữa các members trong team. Quá nhiều thông tin gây hiểu lầm, trong khi, quá ít thông tin gây ra sự mơ hồ và nhầm lẫn. Thách thức để tìm kiếm trung bình hạnh phúc giữa quá nhiều và quá ít.

Đối với kinh nghiệm phần mềm QA của tôi, các quy trình kỹ thuật bảo đảm chất lượng là một cái gì đó mà tôi tạo ra trên đường đi và rất ít đã từng dạy cho tôi. Lúc đầu, tôi nghĩ rằng tôi chỉ cần tìm thấy một lỗi và nói cho các lập trình những gì đã sai. Trong một môi trường phần cứng, điều này có thể làm việc. Các lập trình viên chỉ cần nhấn mạnh rằng nó làm việc vì anh ta không thể tái hiện nó và close lỗi. Nếu bạn để cho nó, điều này có thể dễ dàng trở thành một trận chiến trở lại-và-tới vô tận. Tôi đã phải rất tinh tế với mỗi và mọi tình huống.

Vấn đề đi xuống đối với các đội dự án khi giao tiếp với nhau. Thông thường, các lập trình viên thì quá bận rộn để lắng nghe và PM tiếp tục yêu cầu đẩy nhanh các chức năng hơn nữa. Một bộ lọc là cần thiết. Cần có một cách để xoa dịu các PM trong khi, cùng một lúc, không làm cho các lập trình viên bất mãn. Đây là câu hỏi hóc búa của QA. Nhìn lại, tôi mong ước có nhiều công cụ có sẵn. QA thì rất bận rộn, là chất keo giữ một dự án với nhau. Chúng tôi không có thời gian để nghiên cứu và thiết lập các giải pháp mới bởi vì hiệu suất của chúng tôi được dựa trên có bao nhiêu lỗi được tìm thấy, chúng tôi có thể close bao nhiêu bugs và để lack ít lỗi nhất có thể trong hệ thống. Nếu tim ngừng đập, thì trò chơi kết thúc!

Tôi sẽ kết thúc lời hùng hồn này với một danh sách ngắn của một vài đặc điểm mà - theo ý kiến của tôi - có xu hướng make up của một kỹ sư QA tốt:

1. Tổ chức

Nó là cực kì quan trọng để theo dõi với mục tiêu dài hạn và ngắn hạn. Cho phép một lỗi lọt qua lý do đơn giản là quên nó sẽ gây ra đau đầu hơn sau này.

2. Giao tiếp

Phương pháp truyền thông đúng đắn là cần thiết để truyền đạt những kết quả mong muốn của một kỹ sư. Ý kiến của bạn là không muốn về mặt kỹ thuật, chỉ có bằng chứng về defects. Ý kiến của bạn có thể được đưa lên với PM và hoặc designer bởi vì họ thường là bộ não của dự án. Sản phẩm này thường là sản phẩm trí tuệ của họ, vì vậy họ có thể tận dụng tốt hơn suy nghĩ sáng tạo.

3. Kiên trì

Có một làn da dày luôn luôn có lợi của QA bởi QA đang được đẩy bởi cả hai bên của chiếc nhẫn. Quản lý căng thẳng sẽ là cần thiết. Hãy đối mặt với nó, không phải ai cũng là một điệu nhảy để làm việc, nhưng giữ đầu của bạn lên sẽ cho phép bạn tập trung và không đổ mồ hôi vào những thứ nhỏ.

4. Kỹ thuật

Bạn không cần phải là một lập trình viên, nhưng bạn cần phải có khả năng nhận skillsets kỹ thuật mới nhanh. Mỗi ngày một lần, tìm một điểm để ngồi xuống và tìm hiểu một cái gì đó mới, cho dù đó là học tập về code hoặc đọc về các công cụ mới có thể làm cho cuộc sống của bạn dễ dàng hơn.

Kết Luận: Quan điểm của bạn là gì? Đặc điểm gì khác mà bạn tin rằng một người cần phải có để là một kỹ sư QA hiệu quả? Hãy vui lòng share các ý kiến của bạn để tôi có thể bổ sung thêm vào bài viết của mình.

Nguồn dịch: http://blog.smartbear.com/testing/the-anatomy-of-a-qa-engineer/