Team mình thiếu 1 bạn, mình thay mặt cho team đứng ra phỏng vấn vòng 1, mình thảo luận với team và đưa ra 1 số tiêu chí tuyển người và bộ câu hỏi phục vụ cho các tiêu chí trên.
Do là tuyển đồng đội, nên với mình tìm người càng “khỏe” càng tốt, để bạn ấy tự lo được việc, bọn mình không phải “cõng” và “cõng” được mình thì càng tốt. 😀
Nội dung bài viết
I. Tiêu chí
- has some experience in a software team before (> 2 years)
- self-study and work independently
- address a testing problem
- not being afraid of coding/scripting
- making suggestions and taking action for product and process improvement
II. Các câu hỏi
- Bạn đánh giá khả năng tiếng anh của bạn thế nào? –> cái này là điều kiện cần, vì dự án dùng tiếng anh hàng ngày.
- Bug thú vị nhất mà bạn từng gặp? –> thể hiện niềm yêu thích của bạn với nghề tester, bạn ko thấy bug nào thú vị thì có vẻ bạn ko thật sự thích việc tìm bug. (mình nghĩ vậy)
- Những vấn đề mà team bạn từng gặp phải? Bạn đã bao giờ đóng góp để improve process chưa? –> cái này để xem bạn có thực sự chú ý đến team không, bạn có nhận ra vấn đề team bạn đang gặp phải. Nếu bạn trả lời là không thì mình thấy bạn chưa thực sự quan tâm đến team work và chưa hiểu mức độ quan trọng của team.
- Bạn đã bao giờ tự setup test environment (test tool ở máy mình, cài đặt DB hoặc server…) chưa? –> phần nào đánh giá khả năng làm việc độc lập được, không phải mọi thứ phải nhờ dev hay nhờ người khác.
- Dự án gần đây của bạn là gì, bạn có thể mô tả được không? Project của bạn đang giải quyết vấn đề gì? end-user là ai? –> thể hiện mức độ hiểu biết dự án của bạn từ high-level, bạn không trả lời đc thì ko có gì để nói.
- Bạn có biết về kiến trúc hệ thống và các technology dùng trong project của bạn ko? –> để xem bạn có chịu tìm hiểu về dự án mặt kỹ thuật không, nếu câu trả lời là không thì mặc định bạn không phải là “test engineer”, bạn đang là “end-user tester”. Và nếu bạn còn chẳng hiểu “end-user” của dự án là ai nữa thì bạn quá tệ.
- Goal của bạn là gì? bạn đã làm gì để thực hiện các goals đó? –> thể hiện bạn là 1 người có plan rõ ràng, có suy nghĩ trước sau.
- Bạn có conflict với dev ko? bạn làm cách nào để giải quyết conflict đó? –> với cá nhân mình, mình chưa bao giờ phải cãi nhau với dev vì tester và dev là 2 người làm công ăn lương, nếu có hiểu sai, không thống nhất cách giải quyết thì đẩy thông tin lên người có quyền quyết định.
Thêm 1 vài câu hỏi về tech dạng basic, nếu bạn trả lời được, mình sẽ hỏi sâu thêm:
- Bạn có biết về sql không? –> em chỉ biết basic, select * from… Mình sẽ không ko thêm nữa vì bạn biết quá ít.
- Bạn có biết api test không? –> ah, có phải cái dùng postman ko anh? … Mình không hỏi tiếp vì bạn chẳng biết gì cả. Postman chỉ là 1 tool đóng vai trò là HTTP client, bạn có thể dùng vô số tools khác. Bạn phải hiểu API trong lập trình là gì, api test là test cái gì, chứ ko phải là nó dùng tool gì. Tool ko quan trọng.
- Bạn đã code bao giờ chưa? có sợ code không? –> chưa, em ko sợ code. … Mình sẽ hỏi tiếp “Thế vì sao bạn lại làm tester?” Nếu bạn trả lời là “làm tester để không phải code” thì … thôi.
- Bạn có làm performance test không? bạn làm như thế nào?
- Bạn có biết command line ko?
- Bạn có học thêm các kỹ thuật test hay kiến thức phục vụ cho công việc ko? thông qua nguồn nào?
III. Tổng kết
Trên đây chỉ là 1 số câu hỏi của bọn mình soạn ra để tìm người phù hợp cho team theo các tiêu chí đã thống nhất. Mình share các câu hỏi chỉ để remind các bạn tester mới và kể cả các bạn đã có kinh nghiệm “luôn luôn học tập, nâng cao trình độ của bản thân”, đừng chỉ chờ người khác nhắc. Các bạn đừng để số năm kinh nghiệm là con số vô nghĩa, số năm phải tương ứng với kiến thức, kỹ năng của bạn.
Anh Giang cho em hỏi 1 chút ngoài lề là thường trong Scrum, việc viết Unit test có coi là 1 task bắt buộc ko anh (theo đánh giá và kinh nghiệm) của anh?
em hỏi với tình huống là team hiện tại của em, tỉ lệ dev:qc khoảng 1.5, nghe thì tương đối nhàn với team qc, nhưng thực sự bugs nhiều tới mức team qc ngày nào cũng phải OT tới 10 giờ tối, bug thì fix chỗ này lòi chỗ khác, 1 feature nhỏ đôi khi chục bugs blocker.
Em có dò hỏi thì biết là dev ko có unit test, và cũng ko có người review nên mạnh ai nấy commit, và dev code cực nhanh (1 feature lớn đôi khi code 1 buổi là xong, nhưng đưa build thì basic flow ko work phải trả liên tục). Em có raise lên TechLead nhưng trả lời chỉ là: “code ko có unit test mới nhanh chứ, giờ ai đi làm unit test nữa, 20% effort để code, 80% để fix bugs…” -> em cảm giác ko đúng với những gì em học từ shift left testing, test pyramid , nên em muốn hỏi ý anh.
Thực thì thì ko có mô hình nào nói đến việc Unit test là bắt buộc, theo trí nhớ (cá vàng) của anh. 😀
Anh thực sự rất ghét khi phải làm việc với dev làm 1 tính năng ra 5-7 bugs. Để hạn chế tình trạng đó thì, anh có mấy gợi ý sau:
+ smoke test: 1 bộ test cases cover những tính năng chính (run auto trong thời gian ngắn thì tốt), nếu bản build mới ko pass hết các TC thì return lại luôn.
+ Viết checklist testcase cho từng feature (viết thẳng vào nội dung của jira ticket), yêu cầu dev phải check vào từng checklist đó khi hoàn thành code, trước khi chuyển sang cho tester.
+ Đuổi mẹ thằng tech lead đó đi, nó chính là nguồn năng lượng xấu và là nguyên nhân chính khiến cả team mệt mỏi.
+ tester không phải là người đảm bảo quality của dự án, mà là tất cả mọi người, team tester có OT đến 1h sáng, tìm ra thêm 100 bugs thì cũng ko giúp cho dự án tốt lên nếu dev ko fix những bug đó.
Những gợi ý trên, bọn em có thể đề xuất, nếu ko đc phản hồi thì raise tiếp là QC manager, rồi tiếp tục đến Manager cao hơn nữa.
Cuối cùng, còn cả ngàn công ty khác cho em chọn lựa, nâng cao skill của em rồi bay thôi, ở nơi toxic như vậy làm gì nữa.
Dạ thanks a, công ty em kiểu công ty “gia đình” vậy, có 2-3 projects nhỏ, ko có roles QC manager luôn, QC phải tự bơi tự negotiate hết (em mới có 2 tháng kinh nghiệm auto selenium mà vào cty em phải guide cho cả team viết auto luôn), bị ép cũng ko biết escalate lên ai.
Techlead thì kiêm luôn Scrum master, nêu hầu như quyết định hay giải quyết vấn đề là theo tư duy của devs. Chắc em sẽ kiếm 1 cty khác.
Với kinh nghiệm của anh thì ratio dev:qc ở mức nào là phù hợp vậy a, hiện tại bên e mới 1.5:1 mà QC chạy OT ná thở, hôm tuần trước em phỏng vấn 1 cty kia, họ nói ratio là 10:1 là em choáng ván, mình có tips nào nhận biết qua ratio này là cty nào sẽ nhàn hơn ko a? chứ em thường thấy tỉ lệ này càng cao thì việc của tester càng nhiều
Team anh thì tỉ lệ đang là 2:1 mà qc cũng có nhiều thời gian để học và làm những thứ mong muốn.
Anh thường ko quan tâm đến tỷ lệ đó, em cứ join vào các cty product mà lâu năm 1 tí, đừng join startup hay outsource là ko phải OT. Anh đi làm hơn 5 năm, chưa bị OT 1 ngày nào. Nếu sợ OT thì em cứ hỏi thẳng là cty có OT ko? có thì thôi, khỏi join. 😀
Hi a Giang, hôm qua em có vòng phỏng vấn với PM, có 1 số câu hỏi em ko biết trả lời sao, anh review thử và cho em chút đóng góp nha, keyword để em search google cũng được ạ:
1/ As a QC, bạn cần làm gì để đảm bảo là tất cả items done trong sprint?
2/ As a only QC trong 1 team có 10 Devs, làm thế nào để sắp xếp công việc của bạn để đảm bảo Done tất cả item trong sprint?
-> em nói là dùng Gantt chart để sắp xếp task, thứ tự, priority… nhưng interviewer nói là giờ ko ai dùng Gantt chart nữa đâu em
3/ Dev hẹn thứ 3 sẽ đưa build cho em test, nhưng giờ là thứ 4 vẫn chưa có build, em cần chủ động làm gì để đảm bảo tiến độ? -> em reply là raise trong daily meeting, interviewer nói là chuyện đó là dĩ nhiên rồi, giả sử có khó khăn gì đó bên dev thì chủ đích câu hỏi này là làm sao đảm bảo tiến độ.
4/ Thứ 6 deadline mà thứ 5 dev mới giao deliver build cho em để test mà item này test phải mất 2-3 ngày, thì em làm thế nào để đảm bảo tiến độ?
5/ As a QC, em dùng matrix gì? hay tiêu chuẩn gì để đánh giá 1 build là good quality?
6/ Đầu sprint dev bắt đầu code, lúc đó QC có khá nhiều time free, cuối sprint dev code xong và deliver build cho QC hàng loạt dẫn đến overloaded ở cuối sprint, em cần làm gì để cải thiện?
7/ As a only QC trong 1 team có 10 Devs, sẽ có rất nhiều thứ disturb em, ví dụ: đang test theo task thì có người hỏi kiến thức hệ thống, có người hỏi cách reproduce bug, có người raise concern về unclear user story cần QC involve để adjust testing… -> tổng lại nó sẽ take nhiều time của em -> dẫn đến khả năng test task ko kịp -> làm sao để cải thiện?
Thanks anh Giang nhiều ạ!
Ngoài câu số 5 là 1 câu hỏi khá liên quan đến công việc của QC, thì tất cả các câu còn lại đều là: “Việc nhiều, dồn về cuối, test ko kịp, ảnh hưởng đến sprint và PM vẫn muốn sprint done”. Anh sẽ nghĩ anh sẽ trả lời chung như sau:
– Chất lượng 1 project phụ thuộc vào tất cả mọi người trong team, ko phải chỉ có qc, nên đổ cho sản phẩm tốt hay ko vào đầu qc là 1 suy nghĩ độc hại. Mọi người cùng nhau làm, hỗ trợ nhau để sản phẩm được tốt nhất.
– Team dùng sprint có nghĩa là dùng scrum, nếu scrum như 1 loại short waterfall nửa mùa thì mới xuất hiện hiện tượng dồn vào cuối như trên. Đầu sprint phải có sprint plan và cái plan này phải hợp lý cho cả team (tính toán đủ thời gian dev, test, fixbug và ko OT). Nếu vì 1 nguyên nhân nào đó mà sprint ko đạt sprint goal (bị OT, việc ko xong) thì chúng ta phải thừa nhận với nhau sprint đó fail và có điều chỉnh vào sprint sau.
– Việc của PM là đảm bảo tiến độ của dự án, team làm việc hiệu quả, nên những câu hỏi trên là câu hỏi dành cho PM, ko phải của qc. Ko có cái job description nào của qc nói đến chuyện đảm bảo tiến độ của dự án thay cho PM. Tất nhiên qc phải làm tốt việc của mình, đánh giá độ phức tạp đúng cho feature, chuẩn bị testcase, test data và cố gắng giảm thời gian execute test nhiều nhất có thể, dùng thêm tool A, B, C, code thêm gì đó… Nếu PM ko có giải pháp gì mà đẩy cho qc thì 1 là team đuổi mẹ PM đó vì có làm đc việc đâu, 2 là nghỉ việc.
– Vd: câu 1 item done hay ko phải việc của em, nếu em tìm ra bug và ko thể fix nổi trong print thì sao? OT làm cho xong ah? Never, em work for food chứ ko phải bán máu. Em làm việc professional nhưng ko vì thế mà em dành toàn bộ thời gian nghỉ ngơi của em cho công ty.
– Vd: Câu 6, em ko có ngồi chơi vào đầu sprint, em cũng phải đọc task, chuẩn bị test case, test data, nghĩ sao để test được và làm thế nào thì execute nhanh hơn.
– Nếu đáp án của anh PM mong chờ là team OT thì đó là cty độc hại, em nên tìm công ty khác.
Câu 5: Anh nghĩ là build nào pass smoke test là build tốt rồi, sẵn sàng cho các bước test tiếp theo. Vậy thôi
Thank đồng chí Giang share nhiều cái nhiệt tình quá.
Tiện hỏi đồng chí chút là có cách nào thuyết phục dev làm unit test không đồng chí? dev code nhanh ẩu mà chất lượng kém quá. Chưa kể mình tui làm QA trong project 8 ông dev, feature nào cũng 15 phút là code xong, chưa viết xong test cases là đã ready for testing rồi, thở không nổi.
Tôi đang tính nói chuyện với manager về cái này cho rõ ràng, nếu không thì tôi leave. Mà chưa biết phải thuyết phục dev review code, unit test thế nào
Trước đây em cũng gặp ko ít tình trạng như trên, có mấy ý như sau để anh/chị tham khảo:
– Báo manager dev code ẩu quá –> suggest yêu cầu dev viết checklist hoặc Testcase vào trong task, đảm bảo phải hoàn thành checklist trước khi chuyển sang Ready for Test.
– Mặc kệ các task Ready for test nhiều hay ít –> anh/chị cứ làm theo trình tự, ko cần phải OT hay hùng hục, vì mình cố làm cho nhanh thì PM ko nhìn ra được vấn đề của team.
– Mình ko phải bố mẹ của dev, mình cũng ko cần phải lạy lục van xin, mắng mỏ dọa nạt gì cả. Việc của mình là test, có bug thì report, đơn giản hóa thôi, đừng cố nghĩ phức tạp.
Automation tester có bị hỏi về giải thuật giống như developer không bạn? Thanks
Nếu mình phỏng vấn auto tester thì mình có các bài code:
– thuật toán đơn giản
– 1 flow test web viết selenium theo pattern page object hoặc screenplay
– hoặc 1 code test api.
Và sẽ có các câu hỏi về độ hiểu biết ngôn ngữ. Ví dụ: java thì mình sẽ hỏi về immutable class, String, generics, collection…
em hỏi 1 tình huống này ạ: em cũng có 5 năm kinh nghiệm làm automation = selenium, Java, công việc hằng ngày vẫn cứ findElement, sendKey, click, assert… em cũng nắm hầu hết ngóc ngách trong cái framework em đang làm nên hầu hết mọi scenario trong app em đều auto được hết và em cứ đủng đỉnh 8 tiếng 1 ngày, cho đến tháng trước thì dự án ko kí đc contract nên em bị đào thải.
Em bắt đầu đi kiếm việc, nhưng lúc này em mới ngỡ ra là với những thứ em làm suốt 5 năm qua chỉ ở mức basic nên pv chỗ nào role senior cũng failed. nó làm em cũng suy nghĩ nhiều về giá trị của bản thân (mình luôn rẻ tiền hơn mình nghĩ, vì trước giờ mình ở trong giếng quá lâu). Nên em muốn nhờ anh tư vấn 1 chút:
Nhiều công ty đang chuyển qua framework xài Javascript, em muốn chuyển hướng qua language, framework đó, thì mình cần làm gì để tăng giá trị bản thân? mình nên học hỏi. research ở đâu để giá trị bản thân mình ở mức tốt với standard ở ngoài?
cảm ơn anh
Giá trị bản thân thì có nhiều nghĩa, ở đây anh đoán em hiểu theo nghĩa hẹp “mình cần học skill gì để có thể làm việc tốt, pass phỏng vấn và không lo tụt hậu”.
Nhìn chung, các cty đều muốn 1 người có kỹ năng xử lý vấn đề tốt, biết nhiều thứ, và không ngừng học tập.
– Xử lý vấn đề hay còn gọi là problem-solving là cách em nhìn nhận vấn đề, chia nhỏ nó ra và solve từng phần một.
– Biết nhiều thứ: biết rõ, hiểu rõ language, fw ở mức senior. Ví dụ với Java: basic + advance feature phải nắm trong lòng bàn tay. FW thì đừng chỉ nhìn vào cái fw mà em đang sử dụng ở cty cũ (ai đó trong công ty build), hãy nhìn cái fw mà thế giới build: cypress, serenity bdd, robot framework. Ngoài ra em cần phải luôn mở rộng kiến thức về tech nói chung, anh có nhắc đến 1 số ở đây https://giangtester.com/hanh-trinh-1-tester-trai-nganh/
– Không ngừng học tập: kỹ năng mềm, ngoại ngữ, kiến thức về testing.
Anh đang đi theo hướng đó và anh nghĩ là đó cũng là cái em mong muốn anh tư vấn. Còn việc có pass phỏng vấn hay không thì nó là câu chuyện khác nhé. Anh cũng fail cả đống.
Bài viết bổ ích, thú vị. Em đi phỏng vấn cũng từng được hỏi là test API mà chỉ dùng Chrome Dev Tools được ko, để kiểm tra mức hiểu biết của mình đến đâu.
Nice idea, nhưng anh nghĩ là Dev tools chỉ giúp xem 1 số thông tin thôi, chứ ko test được hết các case.
Chào anh. Trong số nội dung trên anh đề cập, em thấy có nội dung về sql.
Em cũng chỉ biết sql cơ bản và muốn tìm hiểu nâng cao nhưng không biết nên tìm hiểu phần nào. Anh có thể tư vấn cho em nên tìm hiểu những phần nào anh nghĩ cần thiết đối với tester ạ.
Anh có dự định ra serie về sql không ạ?
Đây là những thứ anh phải làm hàng ngày, cũng chẳng có gì là cao siêu:
– Create, Delete, Backup, Restore DB
– Create user and privileges
– SQL: Select, Update, tất nhiên là gồm cả where, order by, group by, join, alias ….
– Index, view
Anh nghĩ với tester, không cần học SQL nâng cao, hãy cứ học cơ bản nhưng thành thục, thật hiểu các câu lệnh, cách DB hoạt động. Vậy thôi
Về series SQL: anh có 1 vài bài ở đây https://giangtester.com/category/sql/