12/08/2018, 15:27

3 quan niệm sai lầm chính mà các Tester nên loại bỏ

Đôi khi, vì nhiều lý do khác nhau, có rất nhiều kỳ vọng chúng ta đặt ra cho chính mình mà không phải lúc nào cũng đúng. Những kỳ vọng này thường dẫn đến nhiều thất vọng và tâm lý chán nản, bởi không một kỳ vọng nào được đáp ứng và vì nó đã không hợp lý ngay từ khi bắt đầu. Quan niệm sai lầm thứ ...

Đôi khi, vì nhiều lý do khác nhau, có rất nhiều kỳ vọng chúng ta đặt ra cho chính mình mà không phải lúc nào cũng đúng. Những kỳ vọng này thường dẫn đến nhiều thất vọng và tâm lý chán nản, bởi không một kỳ vọng nào được đáp ứng và vì nó đã không hợp lý ngay từ khi bắt đầu.

Quan niệm sai lầm thứ nhất: Test tự động không cần bận tâm đến Test thủ công.

Không gì có thể xấu hổ hơn so với tuyên bố này. Test tự động nó chỉ khác Test thủ công ở cách thức thực hiện Test.Cũng không nên quên rằng, thử nghiệm tự động hóa có thành công cũng là đi theo quy trình Test thủ công. Đôi khi, người Test tự động và Test thủ công là một. Ngoài ra, không phải tất cả các dự án đều là các dự án tự động hóa.

Tôi đã từng sử dụng phương pháp Test tự động cho dự án của mình nhưng kết quả đem lại không được như mong muốn, vì vậy tôi chuyển qua Test thủ công. Test thủ công là một kỹ năng mà bất kỳ một Tester nào cũng có, đó là nền tảng cơ bản nhất của chúng ta. Test tự động rất tốt, nó được coi như là một phép thuật nhỏ trong công việc Test phần mềm. Nhưng dựa vào nó để đánh giá kỹ năng tốt hơn hay kém hơn của một Tester thì thật không chính xác.

Test thủ công và Test tự động có vai trò và hiệu quả khác nhau trong mỗi quá trình và mỗi dự án, chúng không loại trừ lẫn nhau. Trong thực tế, đang có sự phân cấp cao thấp giữa người Test tự động và người Test thủ công khá lớn, chúng ta không nên khuyến khích cách nhìn nhận này.

Quan niệm sai lầm thứ hai: Test leads không cần test.

Tôi từng có một đồng nghiệp làm việc cùng tại nơi ở của khách hàng, khi chúng tôi đang xử lý một modul của dự án. Có 3 nguồn lực bên ngoài phải báo cáo công việc cho ông ấy, và bất cứ lúc nào ông estimates hay lên kế hoạch test, ông ấy luôn luôn bỏ qua mình. Khi có cuộc họp kiểm toán, anh ấy đã được hỏi, tại sao lại không tính anh ấy (đồng nghiệp của tôi) tham gia vào các hoạt động này.

Câu trả lời của anh ấy làm cho chúng tôi hiểu nhầm, anh ấy thực sự nghĩ rằng, cấp dưới của anh ấy mới chính là người phải viết Testcases và thực hiện test. Anh ấy không quan tâm tới quá trình đó, anh nghĩ rằng họ thấp kém hơn mình, và rằng anh ấy sẽ bỏ qua quá trình đó chỉ quan tâm tới điều phối tiến trình mà thôi.

Những gì tiếp theo trong cuộc họp không liên quan đến chúng tôi, nhưng hãy để tôi nói với bạn rằng ông ấy không phải người duy nhất có quan điểm như vậy.

Thực tế, tiêu chuẩn bỏ ra để điều phối chỉ là 10%. Test lead cũng là một thành viên trong nhóm QA, một nhà lãnh đạo có trách nhiệm thì nên đóng góp cho các hoạt động test, đồng ý rằng họ còn có những công việc khác nữa. Là một Test lead thì cần hỗ trợ và đồng hành cùng các thành viên trong nhóm QA.

Quan niệm sai lầm thứ ba: Testers nghi ngờ mọi thứ và đó là những người hoài nghi mãi mãi trong ngành công nghiệp CNTT.

Hãy tưởng tượng cuộc sống khó khăn thế nào nếu chúng ta không tin tưởng vào bất kỳ thứ gì. Cuộc sống đối với chúng ta rất khó khăn, thậm chí nhiều lúc chúng ta nghi ngờ cả về sự tồn tại. Thực hiện và hiệu quả của phần mềm - có nghĩa là chúng tôi đang làm việc trong khi tin tưởng rằng sản phẩm là vô ích.

Bạn có nghĩ đó là thái độ đúng không? Chúng ta có thể thực sự giành nhiều thời gian làm việc trên một phần mềm trong khi chúng ta nghĩ nó chỉ là phế phẩm? Tôi nghĩ là không.

Khi cán định hướng thì điều đầu tiên bạn nghĩ đến là gì? trích dẫn của một cựu tổng thống Hoa Kỳ, Ronald Reagan: “Tin tưởng, nhưng hãy xác nhận nó”.

Vì vậy, trái với niềm tin phổ biến, chúng tôi đặt niềm tin vào khả năng của phần mềm, hiệu suất, hiệu quả, năng suất, mục đích và khả năng của nó và chúng tôi luôn luôn tin rằng nó thành công khi đưa ra thị trường.

Nhưng, chúng tôi muốn đảm bảo rằng nó là sản phẩm có chất lượng tuyệt đối. Chúng tôi luôn luôn tự nhắc nhở rằng sản phẩm tuyệt vời và chúng tôi cần xác định và loại bỏ bất cứ thứ gì có thể ảnh hưởng tiêu cực đến một sản phẩm tuyệt vời.

Cuối cùng Chúng tôi hy vọng rằng bài viết này đã để lại một số quan điểm sẽ được dần đi vào trong các quá trình phát triển phần mềm, để đảm bảo chất lượng phần mềm một cách tốt nhất.

0