Tester là gì? Kỹ năng nào cần để trở thành Tester giỏi?
Cùng đọc bài phỏng vấn với anh Lê Việt An – Test Project Manager của TMA Solutions để nghe anh chia sẻ về:
- Những khó khăn thử thách của nghề, và những kỹ năng cần thiết để 1 bạn có thể trở thành Tester giỏi.
- Những cơ hội nghề nghiệp tiếp theo của 1 Tester.
- Lời khuyên anh dành cho các bạn muốn trở thành Tester trong tương lai.
Tiểu sử: Sau khi tốt nghiệp trường NIIT năm 2006, anh An làm cho MMSoft trong khoảng 1 năm. Đến cuối năm 2007 anh về TMA Solutions bắt đầu từ vị trí Tester và lên dần thành Senior Tester, Test Leader, hiện tại anh đang làm Test Project Manager. 6 tháng đầu tiên ở MMSoft, anh là Developer, sau đó, do nhu cầu công việc, anh chuyển qua team test và anh làm testing đến giờ.
Vì sao anh lại chọn trở thành Tester?
Thật ra thì nghề này chọn anh, không phải anh chọn nó. Thời điểm anh tốt nghiệp, khái niệm Tester không phổ biến. Điều may mắn là anh làm trong MMSoft, 1 công ty nhỏ, nên anh có cơ hội trải nghiệm nhiều vị trí khác nhau. Đó là 1 dịp tình cờ khi công ty đang cần Tester, nên công ty cử anh sang phụ team test, và anh dính với nghề này từ đó đến giờ. Anh cảm thấy có hứng thú với nghề test hơn development.
Anh có thể chia sẻ công việc thường ngày của mình không ạ?
Hiện tại anh đang quản lý 3 team Test nhỏ cả về Manual lẫn Automation cho 1 khách hàng của TMA.
Công việc chính của anh, về kỹ thuật là tư vấn các bạn trong team nên xử lý các tình huống test như thế nào?
Về công tác quản lý, anh theo dõi tiến độ công việc và chất lượng của các test release cho các dự án của mình và xử lý tình huống.
Ví dụ 1 bạn Tester của anh phát hiện ra 1 bug, mà người Developer code ra function đó bảo là ‘tôi đã test kỹ lắm rồi, không thể nào có bug được, không tin thì qua máy tôi, tôi demo cho xem.’ Function đó hoạt động bình thường trên máy người Developer kia. Nhưng khi đẩy lên môi trường test thì 100% lại bị lỗi.
Anh thuyết phục người Developer đó cùng ngồi lại để khảo sát function trên môi trường test. Anh ta không chịu. Cuối cùng, anh phải giải quyết bằng cách nói là ‘chúng ta giao phần mềm cho khách hàng, chúng ta không giao PC của anh, nên anh làm ơn ngồi xuống cùng tìm hiểu vấn đề để có thể giao sản phẩm tốt nhất cho khách hàng.’
Anh thấy nghề Tester có điểm cộng nào ạ?
Điểm cộng thứ 1 là anh được biết nhiều business domain khác nhau và được nhìn sâu xuống toàn bộ hệ thống. Ví dụ khách hàng muốn 1 phần mềm cho business domain A. Với cương vị là 1 Tester của phần mềm này, anh phải hiểu business domain A và hiểu phần mềm của mình giải quyết được vấn đề nào của khách hàng, giải quyết như thế nào, chứ không chỉ xoay quanh phần mềm này có bao nhiêu chức năng và những chức năng này làm gì, input là gì, output là gì. Đồng thời, Tester có cơ hội hiểu và thấy phần mềm để giải quyết bài toán của business domain A kia thì cần được thiết kế như thế nào, cần bao nhiêu database, phải xây dựng chức năng nào cho dịch vụ nào…
Điểm cộng thứ 2 là nghề này giúp anh nhìn vấn đề ở nhiều góc độ khác nhau. Có 1 châm ngôn mà anh luôn khuyên các bạn Tester để có khả năng nhìn từ nhiều góc độ khác nhau, đó là ‘be stupid.’ Đừng hi vọng rằng người dùng biết phải gõ cái gì, phải làm cái gì. Khi đã đưa sản phẩm ra thực tế thì bất cứ điều gì cũng có thể xảy ra và bất cứ ai cũng có thể làm bất cứ điều gì trên phần mềm.
Một function luôn được test/nhìn ở 2 góc độ hành vi tiêu biểu: hành vi đúng (positive case) và hành vi chưa đúng (negative case) thì nó hoạt động ra sao.
Ví dụ khi anh test 1 function mang tính chất báo cáo. Nghe có vẻ đơn giản chỉ là bấm 1 nút cho nó chạy ra file rồi xem các tính toán dữ liệu trên file có đúng và đủ không, định dạng có đúng theo yêu cầu khách hàng không. Thì đây là những cái nhìn tiêu biểu mà Tester nào cũng phải nhìn được.
Nhưng 1 Tester giỏi cần phải nhìn: ‘có dữ liệu thì nó ra file như vầy, không có dữ liệu mà bấm nút xuất báo cáo thì nó như thế nào? Phần mềm chạy ra sao? Hiện ra câu thông báo gì? Câu thông báo có thân thiện với người dùng không? Hoặc là 1 function nào đó báo lỗi, thì nội dung thông báo có thân thiện không?’
Lúc nói ra vấn đề mà anh cho rằng là vấn đề thì anh phải nói để người nhận bug vẫn vui vẻ fix bug đó. Vì vậy, điểm cộng thứ 3 là nghề này luyện cho anh khả năng xử lý tình huống. Ngoài ra còn gián tiếp cải thiện khả năng giao tiếp của anh.
Anh có bí quyết nào giúp việc giao tiếp và thuyết phục các bạn Developer dễ dàng hơn không ạ?
Ok, anh có 1 kinh nghiệm duy nhất là khi nói chuyện với Developer phải đặt mục tiêu là ‘lợi ích mang lại cho khách hàng/ người sử dụng.’ Ví dụ như câu chuyện ở trên: mình giao phần mềm, không phải giao PC của người Developer cho khách hàng.
Cố gắng đừng thỏa hiệp với kỹ thuật của Developer. Từng có tình huống, anh thấy là kết quả test function nó hoạt động như A, B, C. Nó không thật sự là kết quả tốt nhất. Khi anh nói chuyện với Developer, anh ta nói là kỹ thuật của mình chỉ làm được đến thế thôi. Nếu anh cho qua, tức là anh đã thỏa hiệp với Developer. Nhưng anh không cho qua. Lần đó, anh nhờ Technical Architect chuyển đổi architect, và nhờ BA nói chuyện lại với khách hàng là phần mềm hoạt động như X, Y, Z sẽ tốt hơn, vì vậy cần tính thêm tiền + thời gian để sửa function này lại.
Vậy nghề Tester có điểm trừ gì không anh?
Điểm trừ lớn nhất là nhiều công ty ở Việt Nam xem nhẹ vai trò Tester và cho rằng chuyện chịu trách nhiệm chất lượng phần mềm là chuyện đơn giản, nên họ đưa ra chính sách về lương cho Tester thấp hơn Developer 1 bậc mặc dù 2 thằng cùng cấp.
Anh không đồng ý quan điểm này vì: đưa ra 2 dự án làm ví dụ. 1 dự án có Developer giỏi nhưng Tester dở (nên sẽ mở ít bug, toàn bug nhỏ, không nhận ra vấn đề của phần mềm từ góc nhìn người dùng phần mềm hoặc không nhìn ra vấn đề về tính tương thích/đồng bộ dữ liệu/performance của nhiều chức năng trong cùng 1 phần mềm…). Nên khi khách hàng sử dụng, có khả năng họ sẽ siêu thất vọng, hậu quả là công ty mất uy tín. Nhưng trong 1 dự án khác, Developer dở nhưng Tester giỏi, thì kết quả cuối cùng tệ nhất có thể là chúng ta có rất nhiều bug cần fix vào những ngày cuối của dự án, khách hàng nhận phần mềm trễ 1 chút nhưng nhìn chung vẫn hài lòng vì họ nhận được đúng cái họ mong muốn.”
Theo anh những tố chất nào thì quan trọng nhất với 1 Tester?
Theo anh, ở thị trường Việt Nam, kỹ năng quan trọng nhất đối với Tester là kỹ năng phân tích. Như 1 trong những điểm cộng của nghề mà anh đã chia sẻ ở trên là ‘luyện được cách nhìn vấn đề từ nhiều góc độ.’ Để có góc nhìn này, bạn cần phân tích trong từng function nhỏ bạn đang test, và phân tích luôn những function liền kề với nó.
Kỹ năng thứ 2 là học hỏi nhanh. Trong ngành phần mềm, thị trường Việt Nam là thị trường outsourcing. Business domain base của chúng ta không có cái nào cụ thể. Bạn phải sẵn sàng chuyển đổi, học domain khác và nhìn các domain ở nhiều góc độ khác nhau. Nên nếu bạn cảm thấy chật vật trong việc học domain mới, bạn sẽ không thể tiến xa trong nghề testing nói riêng và nghề phần mềm nói chung.
Thứ 3 mới là chi tiết, tỉ mỉ. Để testing, chúng ta phải quan tâm đến từng dấu chấm, dấu phẩy trong từng thông điệp, độ logic của thông điệp có tốt hay không và các icon dù nhỏ nhất có phù hợp với thông điệp đưa tới người dùng không.
Thứ 4 là kỹ năng giao tiếp. Hay còn gọi là kỹ năng giải quyết mâu thuẫn.
Thứ 5 là tiếng Anh. Tiếng Anh là điều hiển nhiên, vì chúng ta làm trong thị trường outsourcing. Trước đây giá thành nhân công Trung Quốc rẻ, nhưng bây giờ chất lượng tay nghề nhân công của họ lên thì họ nâng giá. Vì vậy khách hàng bây giờ có xu hướng chuyển đổi thị trường vào Việt Nam, Myanmar.
Cuối cùng là các bạn nên có tính ‘support.’ Người Tester không cần phải là ngôi sao sáng nhất cho cả dự án, nhưng sẵn sàng trân mình ra làm nhiều thứ ngoài trách nhiệm của mình để chất lượng của phần mềm tốt nhất. Đây là tố chất mang lại lợi thế rất lớn cho nghề Tester.
Nói ví dụ cụ thể, trong quá trình em đang test function A, tự nhiên thấy function B kì kì. Tất nhiên về trách nhiệm, B chẳng liên quan gì đến em. Nhưng khi em có tư tưởng ‘support’ thì em sẽ phân tích. Vì mục tiêu cuối cùng chính là chất lượng của phần mềm, nên em mở bug function B luôn cho thằng bên cạnh.
Nghề Tester có thử thách nào mà ai khi đi con đường này cũng phải trải qua không anh?
Khi theo đuổi con đường testing, công việc của em khá stress. Vì team test là chiến tuyến cuối cùng, đảm bảo chất lượng cho cả dự án trong vòng 8 tháng – 1 năm rưỡi – 2 năm.
Khi khách hàng tìm thấy lỗi A, B, C, câu hỏi đầu tiên bao giờ cũng là ‘vì sao Tester không phát hiện ra bug này?’
Điều đáng sợ nhất của nghề Tester là nhận được email từ sếp rằng: “Khách hàng mở 4 bug A, B, C, D. Ai là Tester của function này? Tại sao không phát hiện ra nó?”
Xem lại document, tìm lí do và trả lời email đó là 1 trong những vấn đề cực khó. Nếu thật sự là do em bỏ sót bug thì cần dũng cảm thừa nhận. Phải có Developer fix bug đó, và em phải test lại kỹ càng để giao sản phẩm sớm nhất.
Em không nhất thiết phải tìm hết tất cả document cũ để bảo vệ cho mình. Cái đó chỉ làm cho em càng thêm stress.
Sau khi trải qua tất cả, em cần ngồi lại để suy ngẫm rằng vì sao cái này nó dễ vậy mà lúc trước mình lại bỏ sót nó? Đặt cái đó là cái quan trọng, chứ đừng tự bảo vệ bằng cách, ví dụ như nói là ‘tại thằng Developer khác nó fix cái khác nên nó đè lên chức năng này của mình.’
Anh từng trải qua sai lầm nào? Anh đã vượt qua như thế nào và anh học được gì từ nó?
Thời gian đầu anh làm Tester, anh bị 1 cái gọi là lỗi tâm lý. Anh cứ chăm chăm vào chuyện là mình mở bao nhiêu bug và anh muốn rằng mình là người mở bug nhiều nhất.
Anh đã có nhiều tranh cãi với Developer. Ví dụ 1 lần, anh làm 2 thao tác khác nhau trên function và thấy 2 bug khác nhau, mà Developer investigate và nói rằng ‘nó cùng 1 root cause trong code’ nên Developer đặt trạng thái bug anh mở là ‘bug trùng nhau.’
Anh đã tranh cãi rất nhiều. Hệ quả của vấn đề này là anh phá vỡ mối quan hệ trong team và môi trường làm việc của mình.
Anh học được rằng, không đáng để làm như vậy, vì mục tiêu nghề nghiệp của mình không phải là mở được bao nhiêu bug mà là chất lượng phần mềm của mình tốt tới đâu. Sau này anh rất nhẹ nhàng với những chuyện này. Thậm chí là anh khều khều kế bên bảo là ‘anh fix bug này đi, tôi khỏi mở bug.’ Hoặc 3 – 4 vấn đề nhỏ, anh gom lại mở chung trong 1 bug. Anh nhận ra rằng thật ra Developer cùng team với mình. Trong project không nên có khái niệm team Developer và team Tester.
Khi đã định hướng trở thành Tester thì các bạn sẽ có những bước thăng tiến nào tiếp theo?
Có 3 hướng thăng tiến mà các bạn có thể hướng tới.
Nếu bạn đi theo hướng technical (testing technical), thì có thể đặt mục tiêu trở thành BA (Business Analyst). Vì trong quá trình làm Tester, các bạn đã rèn luyện được kiến thức và kỹ năng của BA. Kỹ năng phân tích, kỹ năng giao tiếp và có kiến thức trên nhiều domain knowledge khác nhau.
Con đường thứ 2, nếu các bạn thấy mình có cách tư duy và kỹ năng thiêng về quản lý thì có thể nghĩ đến hướng Test Manager.
Hướng đi thứ 3 là các bạn cứ làm Tester thôi. Bạn không nhất thiết phải làm sếp của ai hết. Ở Việt Nam có tư tưởng ‘làm 8 năm mà không lên Manager là có vấn đề.’ Không phải vậy. Các bạn thật sự đam mê với nghề thì hãy đặt hết đam mê và sự quan tâm của các bạn vào từng phần mềm bạn test.
Nhưng khi xác định đi theo con đường này, bạn phải nghĩ đến 1 chuyện: khi mới ra trường, 1 ngày bạn chạy được 15-20 test case, đến lúc chuẩn bị về hưu, 35-40 tuổi, quá lắm là 1 ngày bạn chạy được 30-40 test case. Không thể nào lên đến 100 test case được. Vì vậy bạn cần truyền cảm hứng cho bản thân và cho người khác bằng cách cống hiến, truyền thụ lại kinh nghiệm cho các thế hệ tiếp theo, bao gồm cả các bạn trẻ mới ra trường và những bạn Tester ngồi kế bên mình.
Anh có lời khuyên nào cho các bạn Tester hiện tại?
Anh có 3 lời khuyên.
Thứ 1 là các bạn nên mang tâm lý ‘mặc định test case mà bạn tính test là bị lỗi.’ Việc này giúp bạn tránh tâm lý chủ quan.
Chẳng ai nghĩ được rằng 1 Developer lại code function login mà bị lỗi. Nếu em bị tâm lý chủ quan lấn át, em sẽ nghĩ function login không thể sai, không cần test, từ đó em không thể tìm ra hết lỗi, không thể đào hết ngóc ngách của function.
Lúc trước team anh có làm test cho 1 dự án làm website để gây quỹ dành cho người bị mù màu. Với tâm lý ‘mặc định test case mà bạn tính test bị lỗi,’ dù mọi function đều hoạt động bình thường thì vẫn có 1 bạn nói anh là ‘với cách thiết kế màu như website mình thì người mù màu không thể dùng được website này.’
Lời khuyên thứ 2 là các bạn đừng giới hạn sự sáng tạo bằng requirement của khách hàng. Các bạn test 1 test case, nó phải đạt được những yêu cầu requirement đặt ra. Đó là điều ‘tối thiểu,’ không phải ‘tối đa’ mà bạn phải làm.
Ví dụ như hồi xưa anh test 1 phần mềm thu thập file. Requirement đơn giản là khi bộ phận IT sử dụng chương trình đó để nhập file vào database thì hiện ra câu xác nhận: “Bạn có chắc là muốn tiếp tục thực hiện thao tác? Khi xác nhận thì tiến trình không thể hủy bỏ.” Nhưng trong quá trình test, 1 bạn Tester thấy tốc độ quá trình truyền file chậm do dung lượng dữ liệu quá lớn. Bạn đó đề nghị: ‘Dựa vào tốc độ trung bình có thể xử lý 1 line khi đăng tải file rồi Developer đếm số line trên phần mềm và đưa thời gian estimate để xử lý xong file. Cuối cùng, sửa câu thông báo lại là “Quá trình này có thể mất x giờ để mà hoàn thành, bạn có muốn tiếp tục? Nếu chọn tiếp tục thì bạn không thể hủy quá trình tải file.’”
Cuối cùng, anh khuyên các bạn tự luyện tập các kỹ năng cần thiết. Ví dụ kỹ năng mấu chốt của Tester là phân tích function. Các bạn có thể tự luyện tập bằng cách mở bất kỳ function nào, vọc nó, chơi với nó, chơi xong rồi thì phân tích ‘chức năng của function này là gì, configuration như thế nào…’
Tất cả mọi người đều biết phần mềm calculator của Window, nhưng mấy ai biết được khả năng của nó có thể dùng trong lập trình, phân tích thống kê, khoa học, chuyển đổi đơn vị tính…
Anh thường tham khảo những quyển sách/ resources nào trong suốt sự nghiệp của mình?
Về sách thì anh chỉ khuyên các bạn 1 cuốn là ISTQB Foundation. Sách này nói mọi thứ về testing từ test type, test technique mà 1 Tester phải sử dụng để test 1 version, cho đến chuyện các bạn phải báo cáo như thế nào.
BTV.Trần Thị Thu Huyền
Phòng Truyền Thông IMicroSoft Việt Nam
Hotline: 0916 878 224
Email: huyenttt@imicrosoft.edu.vn
LÝ DO THỰC TẾ TẠI SAO TESTER/QA LÀ MỘT LỰA CHỌN NGHỀ NGHIỆP TỐT HIỆN NAY!!!
👉👉 Khóa đào tạo nhân sự Kiểm thử phần mềm chuyên nghiệp?
Chương trình đào tạo Kiểm Thử Phần Mềm Chuyên Nghiệp được thiết kế dựa trên nhu cầu thực tế kiểm thử tại các doanh nghiệp phần mềm lớn đang hoạt động tại Việt Nam hiện nay như: FPT Software, KMS, BOSCH, DXC etc. Gồm có:
1) Định hướng phát triển nghề nghiệp Kiểm Thử Phần Mềm theo lộ trình phát triển chuyên nghiệp Manual, Automation, Performance, Securrity.
2) Lập trình C#/Java cơ bản dành cho kiểm thử viên.
3) Kỹ năng làm việc và phân tích lỗi.
4) Tổng quan kiểm thử phần mềm.
5) Quy trình phát triển và kiểm thử phần mềm hiện đại.
6) Thực hành các công cụ thực tế hiện đang sử dụng tại các doanh nghiệp phần mềm tại Việt Nam (Github, DevOps, SVN etc).
7) Kiểm thử cơ bản và chuyên sâu Manual Software Testing.
8) Kiến thức nghiệp vụ chuyên ngành: y tế (healthcare)/bảo hiểm (insurance)/ngân hàng (banking) etc.
9) Tiếng anh chuyên ngành kiểm thử phần mềm.
10) Kinh nghiệm viết CV và phỏng vấn bằng tiếng anh tại các công ty lớn.
👉👉 Lời cam kết của khóa đào tạo nhân sự này?
🎁 Đây là khóa đào tạo đầy đủ và chi tiết nhất về Kiểm thử phần mềm từ trước đến nay.
🎁 Cam kết chất lượng đào tạo, các bài thực hành trong khóa đào tạo là các "Case Study" rất thực tế mà Chuyên gia IMIC đã dành nhiều tâm huyết biên soạn và đã đưa vào khóa đào tạo này.
🎁 Tất cả các phần trong khóa đào tạo được diễn đạt một cách trực quan nhất, dễ hiểu nhất, bạn dễ dàng vận dụng được các kiến thức chuyên môn vào công việc dự án web thực tế tại Doanh nghiệp.
🎁 Cam kết hỗ trợ học viên sau khóa học nhiệt tình qua: Group Zalo, Facebook, Website, Email.
⚠️ Đặc biệt! Cam kết chắc chắn bạn sẽ hoàn toàn tự tin đi làm ngay về Kiểm thử phần mềm khi tốt nghiệp khóa đào tạo này.
Nhưng với điều kiện bạn phải nghiêm túc, chăm chỉ học tập, nỗ lực xem bài làm bài cũng như chủ động thảo luận với
Chuyên gia khi gặp vướng mắc. Ngược lại "lười học" thì không nhé!