Chào các fen, em thấy các topic về QC khá ít/dead nên tạo 1 cái thử, biết đâu ace thảo luận rôm rả hơn.
Dưới đây là một số kinh nghiệm của em, tuy cũng mới chỉ 3 năm thôi nhưng biết đâu sẽ bổ ích cho lứa sau.
Về em, background UIT - HTTT, vì không thích data (lười validate hàng ngàn cột dữ liệu, sau chọn QC, còn chán hơn
ngu thật) và coding nên apply thực tập Automation QC, theo nghề cho tới giờ.
Lương bổng thì em cũng tầm 1k5 cho 3yoe, tuy không bằng các dev nhưng em thấy khá hài lòng.
Sau đây là một số chia sẻ của em:
- Về Manual sẽ có 2 loại (em sẽ định nghĩa theo các công ty em thường làm):
+ Tester: Đọc requirement và test, không hơn không kém. Role này thì các stakeholders khá khinh thường, coi như là 1 con robot chỉ gì làm đó. Em từng là một người bị vậy, thời gian đó khá stress, vì ngta cũng không cho mình tham gia discussion trong các buổi technical review/approach...Vậy thì mình đành đọc và làm, biết sao giờ
=> Khuyên các bạn muốn vào nghề, nên chọn Project theo Agile Methodology làm để hành nghề như 1 Agile Tester (mô tả trong cuốn ISTQB)
+ QC (Quality Control): Nghe fancy hơn tí, khác với Tester, QC tham gia vào discuss từ thời kì define User Story => Acceptance Criteria. Có thể đưa ra feedback, suggest technical approach, làm sao đó có thể đáp ứng nhu cầu của End User, cũng như thoả mãn được giới hạn Technical của Developer. Theo em thấy, QC - Agile Tester cần có rất rất nhiều kiến thức, từ Front-end, Back-end (DB, API), UX UI, Agile Process, etc. Tuy có thể nông hơn các role tương ứng, nhưng vẫn phải nắm được để discuss/debate.
Về thị trường, em cảm thấy phần lớn các công ty ít khi cho QC hành nghề theo Agile Tester, bởi vì deadline, commit release với Client. Người ta chỉ dành thời gian cho BA lấy req từ Client, phổ biến lại, developing và testing, vậy thôi. Vô hình chung làm dự án sẽ có rất nhiều vấn đề, từ misunderstanding với Client, technical không đáp ứng được req, nhiều production issues, etc. Làm cho nhiều ace Tester cực kì khó ở vì phải OT nhiều, bởi vì thường các dev sẽ deploy, build rất trễ vào cuối sprint, làm không kịp. Vì vậy, thường dev và test có mqh không tốt đẹp. Mong mọi người đọc được bài này thì có thể nhẹ nhàng hơn với đồng nghiệp của mình chăng
Về lương bổng, em đánh giá rằng, Manual Tester < Front-end dev < Automation Test < Back-end dev,... Có thể có trường hợp đếm cua trong lỗ, nhưng mà nhìn chung em thấy vậy.
Em sẽ nợ topic Automation Test viết sau, bài viết cũng dài rồi, mong là nó không flop)))))
Chúc ace cuối tuần vui vẻ, happy testing!
Tiếp tục câu chuyện, em xin nói về Automation Test.
Bắt đầu từ khi em đi thực tập - Rookies NashTech, may mắn là em được train rất tốt, bởi vì em rất try hard học cái framework người ta dạy (build from scratch), em cày 10-12 tiếng 1 ngày kể cả t7, CN, ngồi đặt 100 câu hỏi tại sao người ta lại tổ chức folder, phải init driver như vậy,...Actively hỏi mentor, chị ấy tuy khó tính nhưng nhờ vậy em đã phát triển hơn rất nhiều. Có thể nói 3 tháng thực tập của em hơn cả 1 năm làm việc dự án
Sau này đi làm vài công ty, em thấy mình chả học hỏi được gì nhiều nếu ko có cái nền ở Nash, vì vậy em cực kì biết ơn. Nên, nếu những lứa sau muốn chọn theo Automation thì nên kiếm công ty training tốt hoặc đc involve implement framework. Vì phần lớn các prj hiện giờ đều có framework sẵn, chỉ cần viết test case từ cái core có sẵn.
Sau đó, em làm B*sch, ở B em học được về chính trị, cách negociate, chấp nhận những khúc mắc trong môi trường công sở. Cũng có một số technical nhưng mà cũng không đáng kể, ví dụ như working với một team size to, có những conflict với nhau,...
Còn về Automation technical, có quá nhiều source trên mạng rồi, ae tham khảo thôi)
Dưới đây là một số kinh nghiệm của em, tuy cũng mới chỉ 3 năm thôi nhưng biết đâu sẽ bổ ích cho lứa sau.
Về em, background UIT - HTTT, vì không thích data (lười validate hàng ngàn cột dữ liệu, sau chọn QC, còn chán hơn
ngu thật) và coding nên apply thực tập Automation QC, theo nghề cho tới giờ.Lương bổng thì em cũng tầm 1k5 cho 3yoe, tuy không bằng các dev nhưng em thấy khá hài lòng.
Sau đây là một số chia sẻ của em:
- Về Manual sẽ có 2 loại (em sẽ định nghĩa theo các công ty em thường làm):
+ Tester: Đọc requirement và test, không hơn không kém. Role này thì các stakeholders khá khinh thường, coi như là 1 con robot chỉ gì làm đó. Em từng là một người bị vậy, thời gian đó khá stress, vì ngta cũng không cho mình tham gia discussion trong các buổi technical review/approach...Vậy thì mình đành đọc và làm, biết sao giờ
=> Khuyên các bạn muốn vào nghề, nên chọn Project theo Agile Methodology làm để hành nghề như 1 Agile Tester (mô tả trong cuốn ISTQB)
+ QC (Quality Control): Nghe fancy hơn tí, khác với Tester, QC tham gia vào discuss từ thời kì define User Story => Acceptance Criteria. Có thể đưa ra feedback, suggest technical approach, làm sao đó có thể đáp ứng nhu cầu của End User, cũng như thoả mãn được giới hạn Technical của Developer. Theo em thấy, QC - Agile Tester cần có rất rất nhiều kiến thức, từ Front-end, Back-end (DB, API), UX UI, Agile Process, etc. Tuy có thể nông hơn các role tương ứng, nhưng vẫn phải nắm được để discuss/debate.
Về thị trường, em cảm thấy phần lớn các công ty ít khi cho QC hành nghề theo Agile Tester, bởi vì deadline, commit release với Client. Người ta chỉ dành thời gian cho BA lấy req từ Client, phổ biến lại, developing và testing, vậy thôi. Vô hình chung làm dự án sẽ có rất nhiều vấn đề, từ misunderstanding với Client, technical không đáp ứng được req, nhiều production issues, etc. Làm cho nhiều ace Tester cực kì khó ở vì phải OT nhiều, bởi vì thường các dev sẽ deploy, build rất trễ vào cuối sprint, làm không kịp. Vì vậy, thường dev và test có mqh không tốt đẹp. Mong mọi người đọc được bài này thì có thể nhẹ nhàng hơn với đồng nghiệp của mình chăng
Về lương bổng, em đánh giá rằng, Manual Tester < Front-end dev < Automation Test < Back-end dev,... Có thể có trường hợp đếm cua trong lỗ, nhưng mà nhìn chung em thấy vậy.
Em sẽ nợ topic Automation Test viết sau, bài viết cũng dài rồi, mong là nó không flop
)))))Chúc ace cuối tuần vui vẻ, happy testing!
Tiếp tục câu chuyện, em xin nói về Automation Test.
Bắt đầu từ khi em đi thực tập - Rookies NashTech, may mắn là em được train rất tốt, bởi vì em rất try hard học cái framework người ta dạy (build from scratch), em cày 10-12 tiếng 1 ngày kể cả t7, CN, ngồi đặt 100 câu hỏi tại sao người ta lại tổ chức folder, phải init driver như vậy,...Actively hỏi mentor, chị ấy tuy khó tính nhưng nhờ vậy em đã phát triển hơn rất nhiều. Có thể nói 3 tháng thực tập của em hơn cả 1 năm làm việc dự án
Sau này đi làm vài công ty, em thấy mình chả học hỏi được gì nhiều nếu ko có cái nền ở Nash, vì vậy em cực kì biết ơn. Nên, nếu những lứa sau muốn chọn theo Automation thì nên kiếm công ty training tốt hoặc đc involve implement framework. Vì phần lớn các prj hiện giờ đều có framework sẵn, chỉ cần viết test case từ cái core có sẵn.
Sau đó, em làm B*sch, ở B em học được về chính trị
, cách negociate, chấp nhận những khúc mắc trong môi trường công sở. Cũng có một số technical nhưng mà cũng không đáng kể, ví dụ như working với một team size to, có những conflict với nhau,...Còn về Automation technical, có quá nhiều source trên mạng rồi, ae tham khảo thôi
)Reactions:
ultraego, nart_1412, Hammoni and 16 others
