Người thật

Nếu làm được cả Manual và Automated testing thì thiệt là dzuiiii

Phỏng vấn tester
Phỏng vấn tester

Đây là bài viết do mình (Hoàng Liên Sơn) phỏng vấn một bạn có bí danh là Anh Anh đang học một lớp tại Testing VN (TVN). Trong bài phỏng vấn này, bạn ấy chia sẻ những khó khăn mà một tester trái ngành sẽ phải đối mặt, cũng như một số chuyện vui buồn trong công việc kiểm thử phần mềm. Mời các bạn xem chi tiết bên dưới nhé.

Xin giới thiệu sơ lược về bản thân em

Em hiện đang là một tester làm việc cho một Công ty Startup phần mềm. Tính tới nay chắc đã được hai năm tròn. Thực sự đến lúc anh hỏi, thì em cũng không ngờ mình dính với nghề kiểm thử được lâu tới vậy luôn, thiệt xứng với câu dòng đời đưa đẩy (❛‿❛✿)

Em đến với nghề tester như thế nào?

Nói tóm gọn trong một câu thì: vô tình công việc tester rơi trúng vào em.

Là một sinh viên ngành tiếng Anh Thương mại, đã kinh qua một vài ngành nghề mưu sinh từ những ngày đầu lên Sài Gòn học. Có oánh chết em cũng không tin có ngày em lại làm tester. Vì em học dở tin học kinh khủng. Riêng món Pascal năm cấp 3 đã thành bóng ma tâm lý ám ảnh thiếu nữ nhỏ bé này rồi (•◡•)

Tua nhanh đến giai đoạn tốt nghiệp nha, như bao người khác em rải CV khắp Sài Thành. Đi phỏng vấn cũng dăm ba chỗ, lấy tiêu chí “vị trí có yêu cầu Tiếng Anh” làm chuẩn. Một ngày đẹp trời thì đọc được bài post trên facebook về một vị trí “tester,” ngoài tiếng Anh ra thì yêu cầu khá đơn giản: ham học hỏi, yêu thích công nghệ, năng động, có khả năng tìm hiểu ứng dụng tốt, lương cũng khá ổn,… thế là em nộp hồ sơ vào.

Phỏng vấn cũng khá đơn giản, nhờ vậy mà một đứa chưa từng tìm hiểu hay học về kiểm thử phần mềm như em đã vượt qua được vòng phỏng vấn. Ngày đầu tiên đi làm là Cá tháng Tư (01-04-2019), ngẫm lại đời đúng là rẽ sang một trang mới, công việc rơi xuống đầu như một trò đùa.

Những tháng ngày đầu tiên trên con đường kiểm thử

Lúc đầu không biết test case là gì, sau đó thì biết được đủ thứ nhưng vẫn chưa đủ.

Khi bước vào công việc kiểm thử phần mềm, với nền tảng (background) như một trang giấy trắng thì em được cho làm quen với mô-đun CMS (một trang web quản lý nội dung) của một hệ thống hiện có của Công ty. 

Công việc ban đầu, anh chị ở đó hướng dẫn và giao cho tạo nhiều người dùng ảo (tạo test data) để anh chị kiểm thử. Sau đó, sếp giao cho kiểm thử ứng dụng trên Android, chỉ đưa cho file .apk rồi chỉ cho cách “adb install” (cú pháp: adb install example.apk) để cài vào điện thoại. Tự vọc vạch theo ý mình, “thấy chỗ nào bất hợp lý hay giao diện xấu thì em note lại em nha.” Sau đó dần dần làm qua các dự án web,  mobile app khác nữa từ lúc nào không biết luôn.

Tới bây giờ vẫn chưa biết mặt mũi code nó ra sao

Chính vì không có chút kiến thức chuyên ngành nào về Công nghệ Thông tin, nên em hoàn toàn mù tịt với các thuật ngữ như “source code” (tới giờ vẫn chưa biết mặt mũi nó ra sao), “deploy” (gần đây mới hiểu, trước giờ toàn hỏi và nhờ vả mấy anh dev, như: anh ới anh ời anh update cái ticket anh mới done lên chưa? Em test được chưa?), “debug”, “server”, “dính cache”, “app bị crash”,… Được cái là mấy anh dev công ty em cũng dễ thương, thấy em không biết gì cũng hổng có giải thích cho hiểu, tuy nhiên hai bên vẫn cứ hiểu nhau làm chung đến giờ nay ʕ•́ᴥ•̀ʔ

Cũng vì cái mù công nghệ đó mà em test hoàn toàn dựa trên trải nghiệm người dùng, và làm manual 100% chứ không có bất cứ sử dụng một công cụ hỗ trợ nào (tool). Sếp cứ quăng cho 1 mớ tài liệu của project, em phải ráng đọc hiểu yêu cầu của khách về sản phẩm mà test. Cắm cúi test, hôm nào không tìm được con bug nào để post thì cảm thấy vui lắm, có khi khách hàng sắp đóng dự án tới nơi luôn, vì đã test hết lỗi rồi mà :D. Nhưng thường đời không như là mơ, trong sản phẩm còn một đống bug (khách hàng báo về), chẳng qua em không nghĩ tới nó mà thôi ༼☯﹏☯༽

Dần dà, sếp chỉ em cách viết test case, với định nghĩa đơn giản là liệt kê ra các trường hợp có thể xảy ra trong một tính năng, cố gắng nghĩ ra càng nhiều trường hợp (case) càng tốt. Viết ra các bước chạy test, kết quả mong đợi là gì, vv… Từ đó, dựa trên test case để test; rồi biết rằng khi release một version mới, chưa chắc các chức năng trên bản mới ngon thì bản cũ cũng ngon; biết rằng khi dev fix ở đâu đó cũng có thể gây ảnh hưởng tới chỗ khác trong app; biết rằng có những điều rất khó hiểu như: “Lúc em test chắc chắn không có lỗi này mà, sao khách hàng lại report có lỗi đó!!??”

Chuyện vui buồn của một nữ tester

Thời gian gắn bó với nghề không dài cũng không quá ngắn, nhưng đi làm thì dù ở đâu làm gì cũng vui buồn đủ cả. Khi “tuần trăng mật” đã kết thúc (xong thử việc) thì phải quay lại cuộc sống thường nhật, một tester sẽ luôn công việc bù đầu. Nghe trên trang Facebook Testing VN nói tỷ lệ tester : developer là 1:3, thì cũng đã nhiều, nhưng công ty em là 1:n vì chỉ có mình em là tester (⋟﹏⋞)

Team mình rất vui, mọi người luôn hoà đồng

Vui vì cuối cùng một dự án cũng đã kết thúc thành công; Vui vì mình tái hiện (reproduce) được một con bug do khách hàng báo về; Vui vì mình vô tình phát hiện được một con bug thiệt là khó, trong điều kiện tâm trí bình thường rất khó để có thể nghĩ ra những bước thực hiện lắt léo như thế, may mà vọc vạch sao trúng được đường đi qua đoạn code bị lỗi; Vui vì trong Công ty mọi người cũng yêu quý tester, không cãi nhau hay cau có khó chịu gì trong công việc. Không khí trong văn phòng luôn vô cùng thoải mái. Điều làm em vui nhất đó là khi review lương :))))) à mà không, em gọi đó là hạnh phúc. Nhưng muốn giữ được hạnh phúc trong lúc tăng lương thì lại tự nhủ “phải cố gắng nhiều hơn” để không bị đào thải, mà có thể tiếp tục bước lên.

Buồn buồn là những tuần bị deadline dí sút quần; Buồn buồn là khi khách hàng complain (phàn nàn) sao đợt này app đầy lỗi ra thế kia. Lý do thì:

  • Một trong số đó là do khách hàng sử dụng app trên các thiết bị thật – real device – mà mình không có để test;
  • Một số là do không hiểu rõ yêu cầu, do tài liệu SRS mô tả không rõ ràng;
  • Một số là do …xui, khách hàng test đúng lúc server (máy chủ) đang bị tạch, hoặc do khách đổi dữ liệu hay phiên bản API khác nên gây ra lỗi.

Những lúc này, thì khách chửi sếp >> sếp chửi team mình >> mình cũng phải im lặng thôi.

Khi khách hàng phàn nàn, và sếp “tâm sự” với team.

Những khó khăn của em khi là một tester trái ngành và chưa từng học kiểm thử là gì?

Dạ bản thân em thấy có một số khó khăn trong công việc kiểm thử bao gồm:

  • Testing mindset (tư duy kiểm thử) chưa đủ tốt
  • Không biết sử dụng các công cụ hỗ trợ trong quá trình kiểm thử
  • Khi yêu cầu thay đổi, không biết nên phải đi cập nhật test case của những chức năng nào, vì không biết mối liên quan của module đó trong code. Lại phải xách máy qua ngồi gần dev để trao đổi và hỏi thêm.
  • Tần suất thay đổi yêu cầu rất cao. Khách cứ đổi lúc nào khách thích >> mình không theo kịp, hay không kịp cập nhật test case, không đủ thời gian để viết test case cho phần yêu cầu mới, và cập nhật test case cho chức năng cũ có liên quan
  • Test case có độ bao phủ chưa cao, do em chưa “mò” được các case có thể giúp mình tìm ra bug, ít nghĩ đến negative test cases.
  • Không hiểu lỗi nào là thuộc về front end hay back end, hay là lỗi do server hay sao đó, (em chỉ post bug khi em thấy và dev sẽ tự debug)
  • Góc nhìn và góc hiểu của em đôi khi lại khác với khách hàng, PM, và GM nên có chỗ em thấy hợp lý thì mọi người KHÔNG đồng ý, và ngược lại 😀
  • Vì cùng lúc em phải tham gia kiểm thử cho nhiều dự án khác nhau, nên hay bị rối, và sót bugs. (Công ty hiện có mình em là tester, nên dự án nào cũng chỉ có mình em test, thường thường là test 2-3 dự án cùng lúc)
  • Và còn nhiều lắm anh, hôm nào đi học, gặp em kể tiếp 😀 

Cám ơn em đã trả lời rất thẳng thắn.

Động lực nào đã đưa em đến với lớp ISTQB CTFL tại TVN?

Dạ, do em làm cũng được 2 năm ở vị trí tester, nhưng như những điều em vừa kể ở trên, và cuối năm 2020, dù tình hình Covid khó khăn nhưng em cũng được tăng lương. Nên em cảm thấy mình cần phải “đi học” kiểm thử phần mềm. Lang trang trên mạng, thì vô tình tìm thấy TVN sắp khai giảng khoá ISTQB vào tháng 03-2021 nè, nên đã quyết định tham gia ngay. Hiện tại (Sơn: thời điểm phỏng vấn) thì chỉ mới học đến chương 3, chưa học được các kỹ thuật thiết kế test case (Sơn: chương 4 sẽ học) nhưng em rất hào hứng phần anh giảng kỹ về 7 nguyên tắc kiểm thử phần mềm ah. Sau khi học xong khoá này, em mong em có thể:

  • Thi đỗ chứng chỉ ISTQB Quốc tế (cho sếp vui lòng)
  • Nâng cấp kiến thức và kỹ năng kiểm thử phần mềm (cho bản thân em)

Cuối cùng, trên nhóm Facebook Testing VN, em thấy các anh chị bạn làm Test Automation thiệt là ngầu, có thể tự lập trình 1 cái gì đó giúp quá trình kiểm thử nhanh gọn hơn, hoặc sử dụng các tool kiểm thử hiệu năng, security,… quá trời thứ em mù tịt. Nếu tương lai, em có thể làm được cả Manual và Automated testing thì thiệt là dzuiiii 😀

Cám ơn em đã chia sẻ khá chi tiết góc nhìn của một người tester học trái ngành.

p/s: Bạn nào có nhã ý tham gia chương trình phỏng vấn này, vui lòng liên hệ qua Skype: hoangliensonmt. Cám ơn.

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *