Tester là gì? Kỹ năng nào cần để trở thành Tester giỏi?

Tester là người kiểm thử phần mềm để tìm kiếm các lỗi, sai sót, hay bất cứ vấn đề nào mà có thể ảnh hưởng đến chất lượng phần mềm.

Tùy từng công ty, từng vị trí công việc cụ thể mà nghề Tester có thể chia thành nhiều nhánh như QA, QC, Manual Tester, Automation Tester… Tuy nhiên, tất cả đều có thể gọi chung là Tester.

Cùng đọc bài phỏng vấn của ITviec 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 để bạn có thể trở thành Tester giỏi.
• Những cơ hội nghề nghiệp tiếp theo của Tester.
• Lời khuyên anh dành cho các bạn muốn trở thành Tester trong tương lai.

Xem thêm việc làm Tester trên ITviec

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, một công ty nhỏ, nên anh có cơ hội trải nghiệm nhiều vị trí khác nhau.

Đó là một 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 một 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ụ một bạn Tester của anh phát hiện ra một 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ứ nhất 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 phần mềm cho business domain A. Với cương vị là một 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ó một 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 một function mang tính chất báo cáo. Nghe có vẻ đơn giản chỉ là bấm một 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 một 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à một 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ó một 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.”

Xem thêm: Nghề Tester ở Việt Nam khổ vì định kiến

Theo anh những tố chất nào thì quan trọng nhất với một 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ư một 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à một 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ị một 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ụ một 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 một 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 một chuyện: khi mới ra trường, một ngày bạn chạy được 15-20 test case, đến lúc chuẩn bị về hưu, 35-40 tuổi, nhiều lắm là một 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ứ nhất 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 một 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ó một 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 một 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 một 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, một 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.

—

Bạn không học chuyên ngành Công nghệ Thông tin nhưng muốn xin làm công việc Tester?

Đọc bài phỏng vấn của ITviec với anh Võ Minh Phước, Senior QC của AS White Vietnam, để biết:

• Công việc cụ thể của Tester là gì?
• Tại sao anh quyết định theo nghề Tester mặc dù không có background IT?
• Khó khăn của người trái ngành khi làm Tester

Chào anh Phước! Anh có thể kể về nền tảng giáo dục và con đường nghề nghiệp của mình?

Mình tốt nghiệp Ngành Anh văn Thương mại của Cao đẳng Hoa Sen năm 2008.

Công việc đầu tiên của mình sau khi ra trường là làm nhân viên kinh doanh cho một công ty nội thất. Tuy nhiên, sau 2 tháng thì mình xin nghỉ vì nhận thấy công việc không phù hợp với tính cách của mình.

Tháng 3/2009, mình bắt đầu làm Mobile Game Tester ở Gameloft. Trước đó, mình không có kiến thức gì về ngành IT hết. Mình chỉ được cái là có nhiều kinh nghiệm chơi game (cười).

Vì sao anh lại chọn công việc Tester trong khi chuyên ngành học không liên quan?

Thực sự đây là một cơ duyên. Trong lúc mình đang tìm kiếm công việc mới sau khi rời công ty nội thất thì một người bạn “rủ rê” mình xin vào vị trí Tester ở Gameloft vì thấy mình chơi game nhiều.

Đến khi mình bắt đầu làm Tester và trải qua nhiều “sóng gió” với nghề này, mình nhận thấy đây là công việc phù hợp với mình và đem lại thu nhập tốt. Vậy nên mình gắn bó với nghề Tester luôn.

Việc làm Tester tại TP.HCM

Việc làm Tester tại Hà Nội

Anh bắt đầu công việc Tester như thế nào?

Trong 2 tuần đầu tiên ở Gameloft, mình được training về quy trình làm việc, được hướng dẫn cách mô tả lỗi (bug) và báo cáo lỗi.

Khi bắt tay vào công việc, mình không gặp nhiều khó khăn, chắc do mình hay chơi game nên tìm bug cho game cũng dễ.

Mình làm ở Gameloft được 2 năm thì được lên Senior Tester.

Đến tháng 8/2012, do muốn học thêm kiến thức mới và có thu nhập tốt hơn, mình chuyển đến Vinasource với vị trí QC Engineer.

Vinasource là công ty outsourcing, làm nhiều về web và mobile app. Ở đây, mình phải viết test case và cùng một lúc có khi phải làm 4-5 dự án. Đây cũng là khoảng thời gian mình gặp phải nhiều khó khăn vì không có background IT.

Khó khăn lớn nhất anh gặp phải vì không có kiến thức chuyên ngành IT là gì?

Mình không có kiến thức chuyên ngành IT, nên khi tìm được bug, mình chỉ biết mô tả nó chứ không biết nguyên nhân gốc (root cause) của bug đó là do đâu.

Vì vậy khi mình báo bug cho Developer, họ không có đủ thông tin để sửa. Kết quả là họ phải bỏ thêm thời gian để tái hiện lại bug (reproduce bug), làm tốn thêm thời gian của dự án.

Nếu mình có kiến thức về IT, mình có thể phán đoán và đưa ra dự đoán đúng hoặc gần đúng của root cause. Từ đó, Developer sẽ dễ sửa lỗi hơn, giúp tiết kiệm thời gian cho toàn dự án.

Ví dụ, có lần mình làm một thao tác lỗi nhưng website mình đang test không hiện pop-up thông báo lỗi.

Mình báo bug này với Developer. Nhưng khi bạn ấy làm theo các bước mình mô tả thì lại không reproduce được bug.

Mình thử làm trên máy của bạn Developer, vẫn không reproduce được bug.

Tức quá, mình bảo bạn Developer sang máy mình, rồi mình làm lại cho bạn ấy xem, thì ra bug ngay.

Thế là bạn Developer mò mẫm một lúc trong Settings của browser và phát hiện ra mình disable pop-up rồi nên cái pop-up thông báo lỗi không hiển thị.

Thực sự thì mình không hề ý thức được là mình đã tắt chức năng cho phép browser hiện pop-up từ trước. Nếu có kiến thức về IT, mình đã tự kiểm tra trong Settings khi không reproduce được bug trên máy của bạn Developer.

Anh học được gì từ những khó khăn trong công việc Tester?

Mình không có background về IT thì mình phải bù bằng kinh nghiệm. Đối với những trường hợp mình đã gặp, mình sẽ ghi nhớ kỹ để rút kinh nghiệm về sau.

Chẳng hạn như sau vụ pop-up lần đó, những lần sau mình đều kiểm tra kỹ xem mình có đang allow pop-up không, rồi mới chạy trường hợp kiểm tra pop-up.

Anh có thể kể về hành trình nghề nghiệp tiếp theo?

Mình làm ở Vinasource được 10 tháng thì nghỉ. Tháng 7/2013, mình bắt đầu làm việc ở Titan Technology Corp. với vị trí Senior QC Engineer.

Công việc Tester yêu cầu thường xuyên giao tiếp tiếng Anh với đồng nghiệp và khách hàng, nên từ năm 2009, mình theo học Ngành Ngữ Văn Anh – Hệ Tại chức của Đại học Khoa Học Xã Hội và Nhân văn TP. HCM để tăng cường kỹ năng tiếng Anh.

Đến năm 2014, mình tốt nghiệp ngành học này.

Tháng 4/2017, mình đầu quân cho AS White Vietnam, làm vị trí Senior QC cho đến nay.

Anh Phước (hàng ngồi, thứ 2 từ trái qua) cùng các đồng nghiệp ở AS White Vietnam

Thường một ngày làm việc của anh sẽ như thế nào?

Trước hết, mình nói một chút về công việc của team mình – Data Business Intelligence Team.

Team mình chịu trách nhiệm làm những report theo yêu cầu từ các phòng ban của công ty mẹ (công ty bảo hiểm Employers Mutual Limited ở Úc), và một số khách hàng ở Úc.

Chẳng hạn như có lần một phòng ban của công ty mẹ yêu cầu team mình xử lý dữ liệu về các công nhân bị thương quay trở lại làm việc sau thời gian điều trị.

Phòng ban này gửi dữ liệu qua các file excel để team mình đẩy vào kho dữ liệu (data warehouse). Sau đó, team mình thiết kế mẫu report và xử lý dữ liệu thành dashboard.

Công việc hàng ngày của mình: Họp với Product Owner và Business Analyst bên Úc để cập nhật tiến độ công việc và đưa ra những câu hỏi về các công thức tính trên report mà một phòng ban nào đó yêu cầu.

Sau đó, mình sẽ so sánh report mà Developer trong team mình làm (trên web) với report mà phòng ban đó cung cấp (trên file excel).

Nếu các số liệu không trùng khớp với nhau, mình sẽ truy cập vào data warehouse để xem số liệu được đưa vào có đúng theo file data mà các phòng ban cung cấp hay không, công thức tính mà Developer làm trên report có giống với công thức mà các phòng ban cung cấp hay không.

Mình cũng sẽ kiểm tra màu sắc và template của report có giống với yêu cầu hay chưa, và nhiều thứ khác nữa.

Buổi chiều sau khi xong việc, khi công ty vắng người, thỉnh thoảng mình sẽ ngồi chơi guitar để relax (cười).

Anh bổ sung kiến thức cho công việc Tester như thế nào?

Do môi trường làm việc của mình phải giao tiếp tiếng Anh hằng ngày nên việc trau dồi tiếng Anh là điều bắt buộc.

Mình thường xem kênh Ted Talks trên Youtube để luyện nghe. Mình cũng hay xem phim Mỹ lồng tiếng Việt nhưng có phụ đề tiếng Anh để học cách nói chuyện, giao tiếp thông thường của người Mỹ.

Bên cạnh đó, mình học SQL trên trang w3schools.com để có thể đọc được code của Developer, hiểu cách Developer lấy dữ liệu từ database như thế nào, công thức của Developer có đúng không, và có thể thực hiện White box testing (kiểm tra code để tìm lỗi logic).

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ờ.

Nếu bạn nghĩ những chia sẻ này có thể giúp ích cho bạn bè hoặc đồng nghiệp thì đừng ngại nhấn nút Share bên dưới nhé!

Và đừng quên tham khảo việc làm Tester tại ITviec!