Tester là gì? Kỹ năng nào cần để trở thành Tester giỏi?
Tùy từng tổ chức, từng vị trí việc làm đơn cử mà nghề Tester hoàn toàn mang thể chia thành nhiều nhánh như QA, QC, Manual Tester, Automation Tester … Tuy nhiên, tổng thể đều hoàn toàn mang 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 san sẻ về:
- Những trở ngại thử thách của nghề, và những kỹ năng cần thiết để bạn mang thể trở thành Tester giỏi.
- Những thời cơ nghề nghiệp tiếp theo của Tester.
- Lời khuyên anh dành cho những bạn muốn trở thành Tester trong tương lai.
Xem thêm việc làm Tester trên ITviec
Bạn đang đọc: Tester là gì? Kỹ năng nào cần để trở thành Tester giỏi?
Tiểu truyện : Sau lúc tốt nghiệp trường NIIT năm 2006, anh An làm cho MMSoft từ chừng 1 năm. Tới cuối năm 2007 anh về TMA Solutions mở màn từ vựng 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 tới giờ .
Vì sao anh lại chọn trở thành Tester?
Thật ra thì nghề này chọn anh, ko phải anh chọn nó .
Thời khắc anh tốt nghiệp, khái niệm Tester ko thông dụng. Điều như mong muốn là anh làm trong MMSoft, một tổ chức nhỏ, nên anh mang thời cơ thưởng thức nhiều vị trí khác nhau .
Đó là một dịp vô tình lúc tổ chức đang cần Tester, nên tổ chức cử anh sang phụ team test, và anh dính với nghề này từ đó tới giờ. Anh cảm thấy mang hứng thú với nghề test hơn development .
Anh mang thể san sẻ công việc thường ngày của mình ko ạ?
Hiện tại anh đang quản trị 3 team Test nhỏ cả về Manual lẫn Automation cho một người tậu của TMA .
Công việc chính của anh, về kỹ thuật là tư vấn những bạn trong team nên xử lý những tình huống test như thế nào.
Về công việc quản lý, anh theo dõi tiến độ công việc và chất lượng của những test release cho những 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, ko thể nào mang bug được, ko tin thì qua máy tôi, tôi demo cho xem. ” Function đó hoạt động tiêu khiển thông thường trên máy người Developer kia. Nhưng lúc đẩy lên thiên nhiên và 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 thiên nhiên và môi trường test. Anh ta ko 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 tậu, tất cả chúng ta ko 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 mang thể giao loại sản phẩm tốt nhất cho người tậu. ”
Anh thấy nghề Tester mang đ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 tậu 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 tậu, xử lý như thế nào, chứ ko chỉ xoay quanh ứng dụng này mang bao nhiêu công dụng và những công dụng này làm gì, input là gì, output là gì .
Đồng thời, Tester mang 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 nhà cung cấp 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.
Sở hữu một châm ngôn mà anh luôn khuyên những bạn Tester để mang khả năng nhìn từ nhiều góc độ khác nhau, đó là “be stupid”.
Đừng kỳ vọng rằng người tiêu dùng biết phải gõ loại gì, phải làm loại gì. Lúc đã đư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 mang thể xảy ra và bất kể người nào cũng hoàn toàn mang 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 tiêu khiển thế nào .
Ví dụ lúc anh test một function mang đặc thù báo cáo giải trình. Nghe mang 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 mang đúng và đủ ko, định dạng mang đúng theo nhu yếu khách hàng ko. Thì đây là những loạ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 : “ Sở hữu tài liệu thì nó ra file như vầy, ko mang 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 ra làm sao ? Hiện ra câu thông tin gì ? Câu thông tin mang thân thiện với người tiêu dùng ko ? Hoặc là một function nào đó báo lỗi, thì nội dung thông tin mang thân thiện ko ? ”
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 mang phương pháp nào giúp việc giao tiếp và thuyết phục những bạn Developer tiện dụng hơn ko ạ?
Ok, anh mang một kinh nghiệm duy nhất là lúc 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, ko phải giao PC của người Developer cho khách hàng.
Nỗ lực đừng thỏa hiệp với kỹ thuật của Developer .
Từng mang trường hợp, anh thấy là tác dụng test function nó hoạt động tiêu khiển như A, B, C. Nó ko thật sự là hiệu quả tốt nhất. Lúc anh nói chuyện với Developer, anh ta nói là kỹ thuật của mình chỉ làm được tới thế thôi .
Nếu anh cho qua, tức là anh đã thỏa hiệp với Developer. Nhưng anh ko cho qua .
Lần đó, anh nhờ Technical Architect quy đổi architect, và nhờ BA nói chuyện lại với người tậu là ứng dụng hoạt động tiêu khiển như X, Y, Z sẽ tốt hơn, vì thế cần tính thêm tiền + thời hạn để sửa function này lại .
Vậy nghề Tester mang điểm trừ gì ko anh?
Điểm trừ to nhất là nhiều tổ chức ở 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 thuầ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 ko chấp thuận đồng ý quan niệ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 mang Developer giỏi nhưng Tester dở ( nên sẽ mở ít bug, toàn bug nhỏ, ko trông thấy yếu tố của ứng dụng từ góc nhìn người tiêu dùng ứng dụng hoặc ko 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 tính năng trong cùng 1 ứng dụng … ). Nên lúc người tậu sử dụng, mang năng lực họ sẽ siêu vô vọng, hậu quả là tổ chức 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ì tác dụng sau cuối tệ nhất hoàn toàn mang thể là tất cả chúng ta mang 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 tậu 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 loại họ mong ước. ”
Theo anh những tố chất nào thì quan yếu nhất với một Tester?
Theo anh, ở thị trường Việt Nam, kỹ năng quan yếu 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. ” Để mang 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 ko mang loạ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ẽ ko 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 tới từng dấu chấm, dấu phẩy trong từng thông điệp, độ logic của thông điệp mang tốt hay ko và những icon dù nhỏ nhất mang tương thích với thông điệp đưa tới người tiêu dùng ko .
Thứ 4 là kỹ năng giao tiếp. Hay còn gọi là kỹ năng khắc phục tranh chấp.
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 lực Trung Quốc rẻ, nhưng giờ đây chất lượng kinh nghiệm tay nghề nhân lực của họ lên thì họ nâng giá. Vì vậy người tậu giờ đây mang thiên hướng quy đổi thị trường vào Nước Ta, Myanmar .
Cuối cùng là những bạn nên mang tính “support”.
Người Tester ko 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 to cho nghề Tester .
Nói ví dụ đơn cử, trong thứ tự 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ì tới em. Nhưng lúc em mang 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 kế bên .
Nghề Tester mang thử thách nào mà người nào lúc đi con đường này cũng phải trải qua ko anh?
Lúc 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.
Lúc người tậu tìm thấy lỗi A, B, C, thắc mắc tiên phong lúc nào cũng là “ vì sao Tester ko 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. Người nào là Tester của function này ? Vì sao ko 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 mang 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 ko nhất thiết phải tìm hết toàn bộ document cũ để bảo vệ cho mình. Dòng đó chỉ làm cho em càng thêm stress .
Sau lúc trải qua toàn bộ, em cần ngồi lại để suy ngẫm rằng vì sao loại này nó dễ vậy mà lúc trước mình lại bỏ sót nó ? Đặt loại đó là loại quan yếu, 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 loạ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 trái nào? Anh đã vượt qua như thế nào và anh học được gì từ nó?
Thời kì đầu anh làm Tester, anh bị một loạ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 đã mang 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à thiên nhiên và môi trường thao tác của mình .
Anh học được rằng, ko đáng để làm tương tự, vì tiềm năng nghề nghiệp của mình ko 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õm 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 trông thấy rằng thật ra Developer cùng team với mình. Trong project ko nên mang khái niệm team Developer và team Tester .
Lúc đã định hướng trở thành Tester thì những bạn sẽ mang những bước thăng tiến nào tiếp theo?
Sở hữu 3 hướng thăng quan tiến chức mà những bạn hoàn toàn mang thể hướng tới .
Nếu bạn đi theo hướng technical (testing technical), thì mang thể đặt mục tiêu trở thành BA (Business Analyst). Vì trong quá trình làm Tester, những bạn đã rèn luyện được tri thức và kỹ năng của BA. Kỹ năng phân tích, kỹ năng giao tiếp và mang tri thức trên nhiều domain knowledge khác nhau.
Con đường thứ 2, nếu những bạn thấy mình mang cách tư duy và kỹ năng thiêng về quản lý thì mang thể nghĩ tới hướng Test Manager.
Hướng đi thứ 3 là những bạn cứ làm Tester thôi. Bạn ko nhất thiết phải làm sếp của người nào hết. Ở Việt Nam mang tư tưởng “làm 8 năm mà ko lên Manager là mang vấn đề”. Ko phải vậy. Những bạn thật sự ham với nghề thì hãy đặt hết ham và sự quan tâm của những bạn vào từng phần mềm bạn test.
Nhưng lúc xác lập đi theo con đường này, bạn phải nghĩ tới một chuyện : lúc mới ra trường, một ngày bạn chạy được 15-20 test case, tới 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. Ko thể nào lên tới 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 mang 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 mang lời khuyên nào cho những bạn Tester hiện tại?
Anh mang 3 lời khuyên .
Thứ nhất là những 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 người nào 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 ko hề sai, ko cần test, từ đó em ko hề tìm ra hết lỗi, ko hề đào hết ngóc ngỏng của function .
Lúc trước team anh mang 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 tiêu khiển thông thường thì vẫn mang 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 ko hề tiêu dùng được website này ” .
Lời khuyên thứ 2 là những bạn đừng giới hạn sự thông minh bằng requirement của khách hàng. Những 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”, ko 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à lúc phòng ban 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 mang chắc là muốn liên tục triển khai thao tác ? Lúc xác nhận thì tiến trình ko hề hủy bỏ. ”
Nhưng trong thứ tự test, một bạn Tester thấy véc tơ vận tốc tức thời thứ tự truyền file chậm do dung tích tài liệu quá to. Bạn đó ý kiến đề nghị : “ Dựa vào véc tơ vận tốc tức thời trung bình hoàn toàn mang thể khắc phục và xử lý 1 line lúc đăng tải file rồi Developer đếm số line trên ứng dụng và đưa thời hạn estimate để khắc phục 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 mang thể mất x giờ để mà hoàn thành xong, bạn mang muốn liên tục ? Nếu chọn liên tục thì bạn ko hề hủy thứ tự tải file ” .
Cuối cùng, anh khuyên những bạn tự tập tành những 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. Những bạn mang thể tự tập tành 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 người nào biết được năng lực của nó hoàn toàn mang thể tiêu 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 tới chuyện những bạn phải báo cáo giải trình như thế nào .
—
Bạn ko học chuyên ngành Kỹ thuật Thông tin nhưng muốn xin làm mướn 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ì?
- Vì sao anh quyết định theo nghề Tester mặc dù ko mang background IT?
- Khó khăn của người trái ngành lúc làm Tester
Chào anh Phước! Anh mang 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 nghiệp của Cao đẳng Hoa Sen năm 2008 .
Công việc tiên phong của mình sau lúc ra trường là làm viên chức cấp dưới kinh doanh thương nghiệp cho một tổ chức 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 ko tương thích với tính cách của mình .
Tháng 3/2009, mình khởi đầu làm Mobile Game Tester ở Gameloft. Trước đó, mình ko mang tri thức và kỹ năng gì về ngành IT hết. Mình chỉ được loại là mang 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 lúc chuyên ngành học ko 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 lúc rời tổ chức 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 .
Tới lúc 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 khởi đầu công việc Tester như thế nào?
Trong 2 tuần tiên phong ở Gameloft, mình được training về thứ tự 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 .
Lúc bắt tay vào việc làm, mình ko 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 .
Tới tháng 8/2012, do muốn học thêm tri thức và kỹ năng mới và mang thu nhập tốt hơn, mình chuyển tới Vinasource với vị trí QC Engineer .
Vinasource là tổ chức 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 mang lúc 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ì ko mang background IT .
Khó khăn to nhất anh gặp phải vì ko mang tri thức chuyên ngành IT là gì?
Mình ko mang kỹ năng và tri thức chuyên ngành IT, nên lúc tìm được bug, mình chỉ biết miêu tả nó chứ ko biết nguyên do gốc ( root cause ) của bug đó là do đâu .
Vì vậy lúc mình báo bug cho Developer, họ ko mang đủ thông tin để sửa. Kết quả là họ phải bỏ thêm thời hạn để tái tạo 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 mang kỹ năng và tri thức về IT, mình hoàn toàn mang thể suy đoán và đưa ra Dự kiến đúng hoặc sắp đúng của root cause. Từ đó, Developer sẽ dễ sửa lỗi hơn, giúp tiết kiệm giá bán thời hạn cho toàn dự án Bất Động Sản .
Ví dụ, mang lần mình làm một thao tác lỗi nhưng website mình đang test ko hiện pop-up thông tin lỗi .
Mình báo bug này với Developer. Nhưng lúc bạn đó làm theo những bước mình miêu tả thì lại ko reproduce được bug .
Mình thử làm trên máy của bạn Developer, vẫn ko 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 đó 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 loại pop-up thông tin lỗi ko hiển thị .
Thực sự thì mình ko hề ý thức được là mình đã tắt tính năng được cho phép browser hiện pop-up từ trước. Nếu mang tri thức và kỹ năng về IT, mình đã tự rà soát trong Settings lúc ko reproduce được bug trên máy của bạn Developer .
Anh học được gì từ những vấn đề trong công việc Tester?
Mình ko mang 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 rà soát kỹ xem mình mang đang allow pop-up ko, rồi mới chạy trường hợp rà soát pop-up .
Anh mang 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 khởi đầu 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 xúc tiếp tiếng Anh với đồng nghiệp và người tậu, 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à tri thức tiếng Anh .
Tới 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 tới 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 tẹo í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 tổ chức mẹ ( tổ chức bảo hiểm Employers Mutual Limited ở Úc ), và một số ít người tậu ở Úc .
Chẳng hạn như mang lần một phòng ban của tổ chức mẹ nhu yếu team mình khắc phục và xử lý tài liệu về những người lao động 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à khắc phục 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 tiến trình việc làm và đưa ra những thắc mắc 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 đó phân phối ( trên file excel ) .
Nếu những số liệu ko 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 mang đúng theo file data mà những phòng ban cung ứng hay ko, công thức tính mà Developer làm trên report mang giống với công thức mà những phòng ban cung ứng hay ko .
Mình cũng sẽ rà soát sắc tố và template của report mang giống với nhu yếu hay chưa, và nhiều thứ khác nữa .
Buổi chiều sau lúc xong việc, lúc tổ chức vắng người, đôi lúc mình sẽ ngồi chơi guitar để relax ( cười ) .
Anh bổ sung tri 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 xúc tiếp tiếng Anh hằng ngày nên việc trau dồi tiếng Anh là điều đề nghị .
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 mang phụ đề tiếng Anh để học cách nói chuyện, xúc tiếp thường thì của người Mỹ .
Tuy nhiên, mình học SQL trên trang w3schools.com để mang 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 mang đúng ko, và mang thể thực hiện White box testing (rà soát code để tìm lỗi logic).
Nếu bạn nghĩ những san sẻ này mang 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://bloghong.com
Category: Là Gì