Trở thành Kiểm thử viên: 9 lời đồn và sự thật

Tác giả của bài viết là một người có 9 năm kinh nghiệm trong lĩnh vực Kiểm thử chất lượng phần mềm cho biết: "Tôi đã thấy rằng một số người thường tránh hay không chọn trở thành một kiểm thử viên - Tester/ QA. Với suy nghĩ không được lạc quan, họ cảm thấy mình không đủ tài giỏi, yếu kém trong lĩnh vực CNTT. Tôi sẽ chia sẻ với các bạn những quan điểm và kinh nghiệm của tôi về các lời đồn, các lầm tưởng mà chúng ta vẫn thấy"

Đây được coi là một trong những lầm tưởng lớn nhất. Nếu điều này là thực thì dự án sẽ có những vấn đề lớn.

• Bởi việc QA tham gia vào những giai đoạn gần như sau cùng là một rủi ro lớn đối với chất lượng và tiến độ của dự án.
• QA cũng cần có khoảng thời gian giống như các Lập trình viên để hiểu các yêu cầu, phân tích các lỗ hổng/ thông tin còn chưa đầy đủ của yêu cầu. Từ đó, QA sẽ xây dựng các tài liệu cho giải đoạn kiểm thử: lập kế hoạch, viết test case, bộ dữ liệu kiểm thử...
• Nếu QA tham gia vào giai đoạn sau của dự án thì lúc này họ sẽ gần như chỉ dựa vào sự hiểu biết của các Lập trình viên và coi nó như là tiêu chuẩn để thực hiện kiểm thử dự án. Những cải tiến cho chất lượng sản phẩm vào giai đoạn này là gần như không có.

Chính vì vậy, QA cần phải được tham gia vào các giai đoạn đầu tiên của dự án, bởi họ sẽ có cách tư duy, sự hiểu biết, khả năng phân tích của chính họ. Điều này sẽ không chỉ giúp đội ngũ QA có thể test tốt hơn mà còn cho phép toàn bộ nhóm dự án thực hiện đảm bảo chất lượng tốt hơn. Nhiều tổ chức nhận ra điều này và bao gồm các nhóm QA từ khi bắt đầu dự án.

Nhiều người nghĩ rằng nếu bạn là QA thì bạn không thể phát triển sự nghiệp nghiêng về hướng quản lý. Đó hoàn toàn là hai mảng độc lập với nhau. Để trở thành người quản lý, bạn cần phải có được những kỹ năng như quản lý nhân sự, quản lý chi phí, quản lý thời gian... Như bạn thấy, điều này không liên quan gì đến việc thực hiện kiểm thử, lập trình hay bất cứ vấn đề kỹ thuật nào.

Các kỹ năng của PM phải được phát triển riêng rẽ và bất cứ ai trong thế giới này, dù bạn thuộc về mảng công nghệ hay bất kỳ mảng nào khác cũng có thể làm được. Vì vậy, không có bất cứ điều gì có thể ngăn cản một QA trở thành PM, quản lý các dự án. Nó là một lĩnh vực độc lập và bất cứ ai có quan tâm có thể làm cho nó.

Lý tưởng hơn hết là việc báo cáo nên được thực hiện riêng biệt; cả Dev leader và QA leader đều phải báo cáo tình hình dự án với PM. Nhưng đôi khi dự án chỉ có một Dev leader quản lý các Dev và đội QA. Rất có thể lúc này chúng ta sẽ báo cáo cho một người không chuyên sâu về lĩnh vực kiểm thử. Đó không phải là tình huống tốt nhất nhưng chắc chắn không phải là tệ nhất.

Hãy cứ đảm bảo là bạn đang làm đúng công việc của mình và kiên nhẫn với sự dẫn dắt để giúp họ bắt kịp với việc kiểm thử. Bạn nên làm tốt điều này và về lâu dài họ có thể là người sẽ hỗ trợ cho bạn rất nhiều trong phần công việc của bạn .

Có một suy nghĩ khá phổ biến: khi bạn lập trình/ code kém thì bạn sẽ chỉ có thể trở thành QA. Trên thực tế, việc kiểm thử luôn luôn liên quan đến lập trình trong hầu hết mọi trường hợp.

• QA vẫn cần viết các câu lệnh truy vấn SQL phức tạp để xác nhận tính hợp lệ của dữ liệu hoặc để tạo dữ liệu kiểm thử.
• QA thực hiện chuyển đổi mã được viết bằng một DB khác trong trường hợp migrate dữ liệu.
• Hay khi thực hiện automation test, QA cần phải viết các tập lệnh trong JAVA / Perl hoặc các ngôn ngữ lập trình khác.

Vì vậy, đây là một ý kiến không chính xác.

Có một nhận thức chung rằng kiểm thử chỉ là việc kích chuột ngẫu nhiên trên giao diện và so sánh thực tế những gì đang xảy ra với các chi tiết trong file excel hoặc các tài liệu khác.

Thực tế là các QA thực hiện từng bước đã được định nghĩa trước một cách rõ rang, để đảm bảo rằng giao diện - UI, tính năng cũng hoạt động trong các trường hợp ngoại lệ. Vì vậy, nó là những quan điểm test đã được tính đến.

QA cũng sẽ đóng vai trò như người sử dụng cuối - là người không có phân định rõ ràng về những gì họ có thể và không thể làm trên 1 hệ thống. Đây cũng là lý do mà mọi người nghĩ việc test hệ thống - giao diện người dùng, có thể trông giống như rất nhiều lần nhấp chuột ngẫu nhiên.

Đầu tiên, hãy để tôi mạnh mẽ nói điều này, xây dựng tài liệu là việc của tất cả mọi người trong cùng một dự án. Một tài liệu rõ ràng, đầy đủ và chính xác cho thấy một nền tảng và bằng chứng lịch sử về dự án.

Tuy nhiên, đối với QA, tài liệu là quan trọng hơn bởi vì sản phẩm mà chúng ta tạo ra không phải là một chương trình hoặc một chức năng, mà là một minh chứng đảm bảo cho chất lượng của toàn hệ thống- cái không có hình có dáng. Bộ MS Office là lựa chọn của các QA, nhưng hiện nay nó được đưa lên quản lý ở mức độ cao hơn, chuyên nghiệp hơn - các tool quản lý bug.

# 7) QA có thang lương thấp Nếu điều này xảy ra thật thì có thể họ đang ở không đúng nơi phù hợp, có thể cân nhắc đến sự thay đổi. Có ý kiến cho rằng, việc trả lương phụ thuộc vào rất nhiều yếu tố khác nhau: kỹ năng công việc, kỹ năng mềm.... Nên để nói rằng là nghề QA là một lý do thì điều đó không đúng sự thật.

Đôi khi người ta nghĩ kiểm thử là một nghề khá là bạc bẽo, chẳng có lợi gì nhiều cho bản thân. Có thể hiểu rằng công việc này không giúp bạn tỏa sáng, thể hiện được cá nhân mình. Và đôi khi đó cũng là vấn đề về văn hóa của công ty trong việc làm thế nào đội ngũ QA được đánh giá cao hơn.

Cố gắng giữ thái độ tích cực và hãy để cho kết quả công việc của bạn tự nói ra. Cố gắng không phải để đạt huy chương và giải thưởng cho công việc của bạn. Đồng ý rằng mọi thứ sẽ dễ dàng hơn nếu các đội khác và khách hàng đánh giá cao đội ngũ QA, nhưng nếu họ không làm vậy thì cũng không có nghĩa là chúng ta nên đánh giá thấp mình.

Tôi đã từng có cả tâm trạng cực đoan và thích thú khi làm việc với khách hàng mà họ biết QA là ai và tầm quan trọng như thế nào.

Bất kể bắt đầu song song với đội ngũ phát triển, thì QA vẫn phải chờ cho đến khi sự phát triển hoàn tất để bắt đầu thử nghiệm. Sau đó là các công đoạn: báo cáo lỗi, sửa chữa, kiểm tra lại... Điều này sẽ khiến mọi người lầm tưởng rằng các công việc test đang làm kéo dài dự án như lầm tưởng trên.

Đây sẽ không phải là vấn đề đối với các đội dự án đã có kế hoạch phát triển dự án. Vì vậy, thử nghiệm không trì hoãn dự án nhưng có thể làm kế hoạch không chính xác và kỳ vọng không hợp lý.

Hãy thử nếu bạn tin vào QA. Bởi đó là một công việc tuyệt vời để làm và bạn sẽ thích thú và thích nó. Đừng quên rằng bạn được trả tiền để nâng cao chất lượng của sản phẩm cuối cùng và cho các kỹ năng xuất sắc của bạn.

Tin vào bản thân, công việc của bạn và chấp nhận thử thách. Nó thực sự không phải là sở thích của tất cả mọi người.

Về tác giả: Đây là bài báo dành cho khách của Meenal B. Cô ấy làm việc như là người dẫn đầu Nhóm trong một MNC và chuyên về quy trình kiểm tra chất lượng tổng thể để thực hiện kiểm tra chức năng, dữ liệu, hiệu suất và bảo mật.

Nguồn tham khảo: http://www.softwaretestinghelp.com/myths-about-being-software-tester/