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

Tester là người kiểm thử ứng dụng để tìm kiếm những lỗi, sai sót, hay bất kể yếu tố nào mà hoàn toàn có thể tác động ảnh hưởng đến chất lượng ứng dụng .
Tùy từng công ty, từng vị trí việc làm đơn cử mà nghề Tester hoàn toàn có thể chia thành nhiều nhánh như QA, QC, Manual Tester, Automation Tester … Tuy nhiên, toàn bộ đều hoàn toàn 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

Tiểu sử : Sau khi tốt nghiệp trường NIIT năm 2006, anh An làm cho MMSoft trong khoảng chừng 1 năm. Đến cuối năm 2007 anh về TMA Solutions khởi đầ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 tiên phong ở MMSoft, anh là Developer, sau đó, do nhu yếu việc làm, 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ổ cập. Điều suôn sẻ là anh làm trong MMSoft, một công ty nhỏ, nên anh có thời cơ thưởng thức nhiều vị trí khác nhau .
Đó là một dịp vô tình 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 trị 3 team Test nhỏ cả về Manual lẫn Automation cho một người mua 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 giải trí thông thường trên máy người Developer kia. Nhưng khi đẩy lên môi trường tự nhiên 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 thiên nhiên và môi trường test. Anh ta không chịu .
Cuối cùng, anh phải xử lý bằng cách nói là “ tất cả chúng ta giao ứng dụng cho người mua, tất cả chúng ta không giao PC của anh, nên anh làm ơn ngồi xuống cùng khám phá yếu tố để hoàn toàn có thể giao loại sản phẩm tốt nhất cho người mua. ”

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ụ người mua muốn ứng dụng cho business domain A. Với cương vị là một Tester của ứng dụng này, anh phải hiểu business domain A và hiểu ứng dụng của mình xử lý được yếu tố nào của người mua, xử lý như thế nào, chứ không chỉ xoay quanh ứng dụng này có bao nhiêu tính năng và những tính năng này làm gì, input là gì, output là gì .
Đồng thời, Tester có thời cơ hiểu và thấy ứng dụng để xử lý bài toán của business domain A kia thì cần được phong cách thiết kế như thế nào, cần bao nhiêu database, phải kiến thiết xây dựng tính 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 hy 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 loại sản phẩm ra trong thực tiễn thì bất kể điều gì cũng hoàn toàn có thể xảy ra và bất kể ai cũng hoàn toàn có thể làm bất kỳ điều gì trên ứng dụng .
Một function luôn được test / nhìn ở 2 góc nhìn hành vi tiêu biểu vượt trội : hành vi đúng ( positive case ) và hành vi chưa đúng ( negative case ) thì nó hoạt động giải trí ra làm sao .
Ví dụ khi anh test một function mang đặc thù báo cáo giải trình. Nghe có vẻ như đơn thuần chỉ là bấm một nút cho nó chạy ra file rồi xem những thống kê giám sát tài liệu trên file có đúng và đủ không, định dạng có đúng theo nhu yếu khách hàng không. Thì đây là những cái nhìn tiêu biểu vượt trội 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ó tài liệu thì nó ra file như vầy, không có tài liệu mà bấm nút xuất báo cáo giải trình thì nó như thế nào ? Phần mềm chạy thế nào ? Hiện ra câu thông tin gì ? Câu thông tin 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 tin 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ó trường hợp, anh thấy là hiệu quả test function nó hoạt động giải trí như A, B, C. Nó không thật sự là tác dụng tốt nhất. Khi anh trò 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 quy đổi architect, và nhờ BA trò chuyện lại với người mua là ứng dụng hoạt động giải trí như X, Y, Z sẽ tốt hơn, thế cho nên cần tính thêm tiền + thời hạn để 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 ý chấp thuận quan điểm này vì : đưa ra 2 dự án Bất Động Sản làm ví dụ. 1 dự án Bất Động Sản có Developer giỏi nhưng Tester dở ( nên sẽ mở ít bug, toàn bug nhỏ, không nhận ra yếu tố của ứng dụng từ góc nhìn người dùng ứng dụng hoặc không nhìn ra yếu tố về tính thích hợp / đồng điệu tài liệu / performance của nhiều công dụng trong cùng 1 ứng dụng … ). Nên khi người mua sử dụng, có năng lực họ sẽ siêu tuyệt vọng, hậu quả là công ty mất uy tín .
Nhưng trong 1 dự án Bất Động Sản khác, Developer dở nhưng Tester giỏi, thì hiệu quả sau cuối tệ nhất hoàn toàn có thể là tất cả chúng ta có rất nhiều bug cần fix vào những ngày cuối của dự án Bất Động Sản, người mua nhận ứng dụng 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 ước. ”

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 đã san sẻ ở trên là “ luyện được cách nhìn yếu tố từ nhiều góc nhìn. ” Để có góc nhìn này, bạn cần nghiên cứu và phân tích trong từng function nhỏ bạn đang test, và nghiên cứu 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 ứng dụng, thị trường Nước Ta là thị trường outsourcing. Business domain base của tất cả chúng ta không có cái nào đơn cử. Bạn phải chuẩn bị sẵn sàng quy đổi, học domain khác và nhìn những domain ở nhiều góc nhìn 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 hề tiến xa trong nghề testing nói riêng và nghề ứng dụng nói chung .

Thứ 3 mới là chi tiết, tỉ mỉ.

Để testing, tất cả chúng ta phải chăm sóc đế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à những icon dù nhỏ nhất có tương thích 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ì tất cả 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 giờ đây chất lượng kinh nghiệm tay nghề nhân công của họ lên thì họ nâng giá. Vì vậy người mua giờ đây có xu thế quy đổi thị trường vào Nước Ta, 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 5 cánh sáng nhất cho cả dự án Bất Động Sản, nhưng chuẩn bị sẵn sàng trân mình ra làm nhiều thứ ngoài nghĩa vụ và trách nhiệm của mình để chất lượng của ứng dụng tốt nhất. Đây là năng lực mang lại lợi thế rất lớn cho nghề Tester .
Nói ví dụ đơn cử, trong quy trình em đang test function A, tự nhiên thấy function B kì kì. Tất nhiên về nghĩa vụ và trách nhiệm, B chẳng tương quan gì đến em. Nhưng khi em có tư tưởng “ tư vấn ” thì em sẽ nghiên cứu và phân tích. Vì tiềm năng ở đầu cuối chính là chất lượng của ứng dụng, 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 người mua tìm thấy lỗi A, B, C, câu hỏi tiên phong khi nào 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à vấn đáp email đó là một trong những yếu tố cực khó. Nếu thật sự là do em bỏ sót bug thì cần gan góc thừa nhận. Phải có Developer fix bug đó, và em phải test lại kỹ càng để giao mẫu sản phẩm sớm nhất .
Em không nhất thiết phải tìm hết toàn bộ 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ổng thể, 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 tính 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 yếu tố này là anh phá vỡ mối quan hệ trong team và môi trường tự nhiên thao tác của mình .
Anh học được rằng, không đáng để làm như vậy, vì tiềm năng nghề nghiệp của mình không phải là mở được bao nhiêu bug mà là chất lượng ứng dụng 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 yếu tố 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 quan tiến chức mà những bạn hoàn toà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 lập đ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 sẵn sàng 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 góp sức, truyền thụ lại kinh nghiệm tay nghề cho những thế hệ tiếp theo, gồm có cả những 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 ý chủ quan ép chế, em sẽ nghĩ function login không hề sai, không cần test, từ đó em không hề tìm ra hết lỗi, không hề đào hết ngóc ngách của function .
Lúc trước team anh có làm test cho 1 dự án Bất Động Sản làm website để gây quỹ dành cho người bị mù màu. Với tâm ý “ mặc định test case mà bạn tính test bị lỗi ”, dù mọi function đều hoạt động giải trí thông thường thì vẫn có một bạn nói anh là “ với cách phong cách thiết kế màu như website mình thì người mù màu không hề 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 ứng dụng tích lũy file. Requirement đơn thuầ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 liên tục triển khai thao tác ? Khi xác nhận thì tiến trình không hề hủy bỏ. ”
Nhưng trong quy trình test, một bạn Tester thấy vận tốc quy trình truyền file chậm do dung tích tài liệu quá lớn. Bạn đó ý kiến đề nghị : “ Dựa vào vận tốc trung bình hoàn toàn có thể giải quyết và xử lý 1 line khi đăng tải file rồi Developer đếm số line trên ứng dụng và đưa thời hạn estimate để giải quyết và xử lý xong file ” .
Cuối cùng, sửa câu thông tin lại là “ Quá trình này hoàn toàn có thể mất x giờ để mà hoàn thành xong, bạn có muốn liên tục ? Nếu chọn liên tục thì bạn không hề hủy quy 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 ứng dụng calculator của Window, nhưng mấy ai biết được năng lực của nó hoàn toàn có thể dùng trong lập trình, nghiên cứu và phân tích thống kê, khoa học, quy đổi đơn vị chức năng 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 những 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 những bạn phải báo cáo giải trình 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

• 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?

Đọc bài phỏng vấn của ITviec với anh, Senior QC của AS White Vietnam, để biết :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 tiên phong của mình sau khi ra trường là làm nhân viên cấp dưới kinh doanh thương mại cho một công ty nội thất bên trong. Tuy nhiên, sau 2 tháng thì mình xin nghỉ vì nhận thấy việc làm không tương thích với tính cách của mình .
Tháng 3/2009, mình mở màn làm Mobile Game Tester ở Gameloft. Trước đó, mình không có kỹ năng và kiến thức gì về ngành IT hết. Mình chỉ được cái là có nhiều kinh nghiệm tay nghề 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 việc làm mới sau khi rời công ty nội thất bên trong 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 mở màn 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à việc làm tương thích 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 .

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

Trong 2 tuần tiên phong ở Gameloft, mình được training về quy trình tiến độ thao tác, được hướng dẫn cách diễn đạt lỗi ( bug ) và báo cáo lỗi .
Khi bắt tay vào việc làm, mình không gặp nhiều khó khăn vất vả, 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 kỹ năng và 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 Bất Động Sản. Đây cũng là khoảng chừng thời hạn mình gặp phải nhiều khó khăn vất vả 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ó kỹ năng và kiến thức chuyên ngành IT, nên khi tìm được bug, mình chỉ biết miêu tả nó chứ không biết nguyên do 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 hạn để tái hiện lại bug ( reproduce bug ), làm tốn thêm thời hạn của dự án Bất Động Sản .
Nếu mình có kiến thức và kỹ năng về IT, mình hoàn toàn có thể phán đoán và đưa ra Dự kiế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 chi phí thời hạn cho toàn dự án Bất Động Sả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 tin lỗi .
Mình báo bug này với Developer. Nhưng khi bạn ấy làm theo những bước mình diễn đạ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 tin lỗi không hiển thị .
Thực sự thì mình không hề ý thức được là mình đã tắt công dụng được cho phép browser hiện pop-up từ trước. Nếu có kiến thức và kỹ năng 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 tay nghề. Đối với những trường hợp mình đã gặp, mình sẽ ghi nhớ kỹ để rút kinh nghiệm tay nghề 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 mở màn thao tác ở Titan Technology Corp. với vị trí Senior QC Engineer .
Công việc Tester nhu yếu liên tục tiếp xúc tiếng Anh với đồng nghiệp và người mua, 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. Hồ Chí Minh để tăng cường kỹ năng và kiến thức tiếng Anh .
Đến năm năm trước, 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 những đồ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 ít về việc làm của team mình – Data Business Intelligence Team .
Team mình chịu nghĩa vụ và trách nhiệm làm những report theo nhu yếu từ những phòng ban của công ty mẹ ( công ty bảo hiểm Employers Mutual Limited ở Úc ), và một số ít người mua ở Úc .
Chẳng hạn như có lần một phòng ban của công ty mẹ nhu yếu team mình giải quyết và xử lý tài liệu về những công nhân bị thương quay trở lại thao tác sau thời hạn điều trị .
Phòng ban này gửi tài liệu qua những file excel để team mình đẩy vào kho tài liệu ( data warehouse ). Sau đó, team mình thiết kế mẫu report và giải quyết và xử lý tài 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 để update quy trình tiến độ việc làm và đưa ra những câu hỏi về những công thức tính trên report mà một phòng ban nào đó nhu yế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 ứng ( trên file excel ) .
Nếu những số liệu không trùng khớp với nhau, mình sẽ truy vấn vào data warehouse để xem số liệu được đưa vào có đúng theo file data mà những phòng ban cung ứng 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à những phòng ban phân phối hay không .
Mình cũng sẽ kiểm tra sắc tố và template của report có giống với nhu yế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, đôi lúc 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 thiên nhiên và môi trường thao tác của mình phải tiếp xúc 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 chuyện trò, tiếp xúc thường thì 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).

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!

Source: https://trangdahieuqua.com
Category: Làm đẹp