Bạn có biết 8 suy nghĩ tối kị đối với QA là gì?

Thiếu định hướng là câu chuyện muôn thuở của nghề QA.

Không phải một bộ môn chính được giảng dạy trong nhà trường, không có một chuyên ngành cụ thể, thậm chí nhiều QA cũng không có kiến thức nền về CNTT — trên đây chỉ là 3 trong rất nhiều lý do khiến bạn gặp khó khăn khi bắt đầu bước vào nghề kiểm thử phần mềm (Software Testing).

Vậy cần làm gì để trở thành một QA Engineer chuyên nghiệp? Hay nói cách khác, điều gì khiến bạn thụt lùi trong nghề kiểm thử? Hãy xem 8 tư duy tối kị dành cho QA sau đây, Got It tin rằng suy nghĩ của bạn sẽ thay đổi đáng kể đấy!

1. QA không cần biết code hay automation

Nhiều người vẫn nghĩ, nếu thành thạo về lập trình thì làm Software Engineer cho rồi, sao còn làm QA!? Nhưng điều đó không có nghĩa QA không cần tìm hiểu về phần code của sản phẩm. Bạn là một phần chủ chốt trong quá trình phát triển phần mềm, và việc biết đọc code sẽ giúp bạn phân tích sản phẩm, cũng như hiểu được những thay đổi, những lần fix bug có ảnh hưởng thế nào lên sản phẩm đó. Những ngày mà tester chỉ quanh đi quẩn lại với “black box” và “white box” đã qua rồi!

Là một QA Engineer, bạn chẳng cần cố bắt bản thân viết code nếu không muốn. Nhưng nếu không chịu khó đọc code, rất có thể bạn sẽ bỏ lỡ những thông tin vô cùng hữu ích, thậm chí ảnh hưởng lớn đến cả quá trình kiểm thử của cả một domain.

2. QA chỉ tham gia sau khi dev đã build xong phần của mình

Nếu bạn đã đi làm, hãy thử hỏi bản thân: Bạn tham gia từ bước nào của quá trình phát triển sản phẩm?

Về lý thuyết, ta đều hiểu QA nên tham gia từ khi cả team phân tích các requirements, cùng PM và các software engineer để xác minh khả năng sử dụng (usability) và tính khả thi (feasibility) của tính năng mới, bắt đầu nghĩ test cases từ trước cả khi software engineer bắt tay vào việc.

Thế nhưng, thực tế lại là một chuyện khác. Ở nhiều nơi, QA thường chỉ lên tiếng sau khi các dev đã build xong phiên bản đầu tiên và yêu cầu họ (QA) đưa feedback. Điều này không chỉ khiến công việc của bạn trở nên bị động mà còn dễ xảy ra sai sót vì không lường trước các test cases, hoặc không đủ hiểu sản phẩm.

Ở Got It, QA team sẽ luôn tham gia các buổi họp về thiết kế tính năng (feature design meeting) để đào sâu về requirements, đặt nhiều câu hỏi nhất có thể để hiểu rõ sản phẩm mình sắp làm. Là QA Engineer bận thật đấy, nhưng đó không phải là lý do để bạn bỏ mặc và chờ đến khi dev xong việc. Hãy tham gia từ những bước đầu tiên, đồng thời rèn luyện kỹ năng sắp xếp thứ tự ưu tiên và quản lí thời gian để làm được điều đó.

3. QA chỉ cần viết và chạy các test cases có sẵn

Nhất là với những QA Engineer ở trình độ Fresher, Junior, công việc của bạn dễ bị giới hạn ở mức chỉ làm theo những cái khung có sẵn, cùng lắm là thay đổi một chút cho phù hợp với từng lần test mà thôi. Đây cũng là lý do khiến nhiều người nhanh chán, cảm thấy nghề QA chỉ lặp đi lặp lại, không phát triển được bản thân.

Vậy ngoài chạy và viết các test cases có sẵn, QA Engineer sẽ làm gì?

Trên đây chỉ là một phần rất nhỏ công việc của team QA tại Got It. Và thực tế cho thấy rằng, QA không chỉ gói gọn trong việc chạy những test cases có sẵn rồi quy hết thành pass — fail.

4. Test Automation là kỹ thuật nâng cao, lúc nào “có thời gian” mình sẽ học sau

Nếu một người thực sự quyết tâm muốn làm điều gì đó, họ sẽ tìm cách làm bằng được thay vì đưa ra lý do.

Nhiều QA thường coi test automation (hay scripting) là một thứ khá “đao to búa lớn”, suy nghĩ “không tốt nghiệp chuyên ngành CNTT thì không đủ sức học automation” chẳng hạn. Tất nhiên test automation không phải thuốc tiên có thể chữa khỏi mọi “căn bệnh” kiểm thử, nhưng việc thành thạo kỹ thuật này sẽ giúp bạn mở ra nhiều hướng đi mới trong công việc. Không chỉ workload hàng ngày được tối ưu, mà cơ hội thăng tiến hoặc tìm một công ty phù hợp của bạn cũng sẽ tăng lên nhiều.

Bởi vậy, đừng bao giờ tự giới hạn bản thân nhé! Thử làm một phép so sánh nhỏ, bạn sẽ chọn nhóm lửa bằng cách đánh đá, hay học cách sử dụng bật lửa nào?

5. Quản trị rủi ro thì liên quan gì đến QA

Một điều bất thành văn nhưng ai cũng hiểu: không một QA nào có thể test hết mọi tình huống có thể xảy ra. Đó là một quy luật tất yếu, và cũng là khi ta cần quan tâm đến một khái niệm cơ bản trong quản trị rủi ro, đó là: làm thế nào để giảm rủi ro đến mức thấp nhất. Hay nói cách khác, ta cần biết ưu tiên test cái gì trước, và cái gì có thể suy ra từ các kết quả test liên quan.

Khi đã có kinh nghiệm, bạn sẽ biết được những phần nào của sản phẩm thường có nhiều rủi ro, phần nào luôn có cả đống lỗi xếp hàng và phần nào luôn công việc của cả team bị delayed. Việc trao đổi với team về những “cục tạ” này cũng là một phần công việc của QA Engineer. Bởi từ đó, cả team có thể cùng nhau đưa ra những giải pháp thực tiễn, giúp tăng hiệu quả làm việc, tiết kiệm thời gian và công sức cho tất cả mọi người.

6. Mình không cần thường xuyên liệt kê và cải thiện kỹ năng

Ngoài những đợt performance review, đã bao giờ bạn tự ngồi lại và liệt kê những kỹ năng mình đang có, những điều mình cần cải thiện không?

Hãy tưởng tượng mỗi chúng ta giống như một người thợ điện vậy. Mỗi khi làm việc, anh ta luôn mang theo hộp dụng cụ quen tay, dễ dùng nhất. Sẽ ra sao nếu anh chàng này, hay chính chúng ta, không biết trong hộp của mình có gì, không biết cái nào còn tốt, cái nào đã hỏng, cái nào cần thay thế, và cái gì cần bổ sung thêm? Mới nghe thôi đã thấy khó làm việc rồi đúng không nào?

Đừng để đến performance review mới ngỡ ngàng nhận ra điều mình còn thiếu. Hãy làm điều đó ngay hôm nay, và bạn sẽ thấy mình tiến nhanh hơn rất nhiều, để mỗi lần tham gia performance review cũng sẽ tự tin hơn đấy!

7. QA không gắt không được!

Người ta nói dev-với-test giống như nước-với-lửa. QA là “nghề bắt lỗi”, còn dev thì hay khăng khăng “Trên môi trường của tôi nó vẫn chạy cơ mà!”. Dường như chuyện “QA phải gắt” đã được nhiều người coi là đương nhiên, nhưng với Got It, một QA biết kiềm chế ego (cái tôi) của mình khi làm việc lại đáng quý hơn cả.

Một QA chuyên nghiệp cần biết giữ bình tĩnh khi đưa ra ý kiến của mình và khi tiếp thu ý kiến từ người khác. Không phải tự nhiên mà các QA Engineer được coi là ứng cử viên sáng giá để trở thành BA (hay thậm chí là PM) — những vị trí luôn đòi hỏi kỹ năng giao tiếp tốt với nhiều team khác nhau.

Có một quy tắc luôn được tuân thủ ở Got It, đó là “Không tấn công cá nhân”. Chúng mình luôn cố gắng đưa ra feedback của mình một cách tích cực, đón nhận cả những chỉ trích nếu chúng mang tính xây dựng chứ không phải công kích cá nhân. Bạn không cần phải hoàn hảo, nhưng cần biết lắng nghe, học hỏi, và nhất là tôn trọng những đồng nghiệp của mình.

8. QA là nghề không bền, sớm muộn mình cũng nhảy sang làm BA!

Nếu đã đọc hết những phần trên, hẳn bạn cũng phần nào hiểu được con đường kiểm thử rộng và linh hoạt đến thế nào. Thế nhưng, đáng tiếc là nhiều bạn fresher, junior QA thường chỉ coi đây là bước đệm để trở thành quản lý trong các công ty công nghệ, chứ không một nghề để theo đuổi lâu dài.

Got It đã phỏng vấn rất nhiều ứng viên QA với định hướng “2–3 năm sau em muốn trở thành BA”, dù chính các bạn cũng chưa thực sự tưởng tượng ra công việc của BA là gì. Bạn nghĩ sao nếu chúng ta cùng thử “chiến thuật data-driven” của Got It, nghĩa là chỉ đưa ra quyết định khi đã có đủ dữ liệu trong tay?

Bởi có một sự thật rằng, bạn sẽ không thể trở thành một QA Engineer giỏi nếu không đầu tư cho nó. Hãy xây móng trước khi làm nhà, hãy trở thành QA với tất cả sự nghiêm túc của bạn, học hỏi từ nó, và suy nghĩ xem mình có nên theo đuổi nó lâu dài hay không. BA không nên là hướng đi duy nhất, bởi bạn hoàn toàn có thể trở thành Senior QA Engineer, Test Manager, Test Automation Engineer, Security Testing Engineer, Bridge System Engineer (BrSE) hay thậm chí là Software Engineer cơ mà!

Nếu bạn quan tâm, hãy xem các vị trí đang tuyển dụng của Got It và đọc thêm về quy trình tuyển dụng tại đây.

Tìm hiểu thêm về Got It tại: