“Mục đích của Tester là tìm bug, nhưng vẫn hỗ trợ cho mục đích cuối cùng là làm sản phẩm tốt hơn, chứ không phải là chỉ trích, đánh giá Developer.”
Đọc bài phỏng vấn của ITviec với anh Trương Minh Sử Nhiên – Senior Automation Tester của KMS Technology – để tìm hiểu:
- Automation Test là gì? Khi nào nên sử dụng Automation Test?
- Sai lầm mắc phải trong sự nghiệp Automation Tester và cách anh vượt qua
- 6 kỹ năng cần thiết cho mọi Tester + cách rèn luyện
- 3 lời khuyên thực tế cho các Tester trẻ cải thiện ngay hôm nay
Xem việc làm Automation Tester tại ITviec
Sự khác nhau giữa Manual Test và Automation Test là gì ạ?
Lúc trước, hình thức test phần mềm phổ biến là Manual Test (kiểm tra thủ công bằng tay). Ví dụ để test form log in, một Manual Tester sẽ tự nhập tay username, password, click “log in”, xem kết quả đăng nhập thành công hay không.
Khi có sự thay đổi về giao diện hay tính năng thì Tester phải test lại những case đã từng làm để đảm bảo không có thêm bug mới. Quá trình này mất khá nhiều thời gian và công sức.
Khi khái niệm Automation Test (kiểm tra tự động) ra đời, Tester chỉ cần viết một đoạn code hoặc sử dụng một số công cụ như Selenium, Test Complete, Jmetter… để chạy tự động tất cả các bước bao gồm nhập thông tin, click, kiểm tra kết quả, so sánh kết quả thực tế với kết quả giả định.
Nhiều loại test có thể làm auto, ví dụ như functional testing, performance/load testing, unit testing.
Xem thêm:
Tester là gì? Kỹ năng nào cần để trở thành Tester giỏi?
Manual Tester: Vai trò, Kỹ năng cần thiết và Lộ trình sự nghiệp
Ưu điểm và nhược điểm của Automation Test so với Manual Test là gì?
Ưu điểm của Automation Test là:
1) Đáng tin cậy. Test chạy chính xác theo quy trình đã định sẵn. vì vậy tránh được nhiều lỗi do con người tạo ra, ví dụ như nhập sai dữ liệu.
2) Mình có thể test cách phần mềm xử lý (tính năng/hiệu năng) khi gặp tình huống chạy lặp đi lặp lại nhiều lần (cùng lúc) trên cùng script test. Đây còn gọi là performance/load testing.
3) Mình có thể lập trình nhiều test tinh vi hơn để thu về những thông tin ẩn từ ứng dụng. Ở điểm này thì Manual Test không thể làm được.
4) Test mang tính toàn diện cao. Mình có thể tạo ra một bộ test để bao quát hết tất cả tính năng trong ứng dụng.
5) Mình có thể tái sử dụng test trên nhiều phiên bản khác nhau của ứng dụng, ngay cả khi có sự thay đổi giao diện.
Ví dụ như khi sản xuất phần mềm, chúng ta cần lần lượt test sản phẩm ở nhiều môi trường: 1) môi trường test, 2) môi trường beta, 3) môi trường production.
Nếu chạy Manual Test thì một test case mất một tiếng, ba môi trường tốn ba tiếng. Mà trong suốt quá trình phát triển sản phẩm, chúng ta phải lặp lại quá trình test vô số lần, dẫn đến mất thời gian nếu làm Manual Test. Thay vào đó, chỉ cần viết một script test thì mỗi lần deploy lên môi trường mới, mình chỉ cần thay đổi URL là test tự chạy được.
6) Chất lượng và hiệu suất phần mềm tốt hơn bởi vì mình có thể chạy nhiều test trong thời gian ngắn hơn với ít resource nhất.
7) Automation Testing Tools giúp chạy test nhanh hơn test bằng tay.
8) Có tính kinh tế cao vì có thể giảm thiểu nguồn nhân lực làm kiểm tra hồi quy.
Nhược điểm của Automation Test là:
1) Nhiều tool có chi phí rất cao, ví dụ như commercial tool: HP Quick Test Pro.
2) Thường thì lương trả cho Automation Tester nhiều hơn Manual Tester, vì công việc đòi hỏi họ có kỹ năng cao hơn, ví dụ như phải biết code, phải viết được script.
3) Chi phí để phát triển và bảo trì test script cao. Ví dụ một test case nếu Manual Test thì mất 1 tiếng. Nhưng nếu đổi sang chạy Automation Test, cần chuẩn bị test script (mà trong trường hợp khó) thì phải mất 6-7 tiếng để viết test script. Người viết test script cần có kỹ năng lập trình và tool để chạy test. Vì vậy chi phí cho Automation Test cao hơn Manual Test.
4) Đòi hỏi Tester phải có kinh nghiệm technical và kỹ năng lập trình.
5) Đòi hỏi thời gian chuẩn bị dài hơn để thiết kế, cài đặt kỹ càng trước khi cần đưa dự án đi test.
6) Có những dự án không nên chạy Automation Test, nhưng nhiều Tester vẫn hiểu nhầm và chạy Automation Test, dẫn đến mất thời gian, resource, công sức. Ví dụ như khi test một chức năng quá phức tạp của một ứng dụng hoặc một GUI object thì phải chạy Manual Test.
Việc làm QA-QC-Tester tại TP HCM
Công việc, trách nhiệm thường ngày của anh là gì?
Với vị trí Automation Tester Architect, anh xác định các tính năng của Automation Testing Framework, hỗ trợ phát triển Framework để làm Automation Test.
Điểm cộng và điểm trừ của công việc Automation Tester là gì ạ?
Điểm cộng của nghề này là nó giúp anh nâng cao kỹ năng phân tích vấn đề và kỹ năng quản lý sự cố. Còn điểm trừ là lúc đầu, anh hay vướng vào tranh cãi với team development về các bug mà anh tìm ra.
Kỹ năng phân tích vấn đề và kỹ năng quản lý sự cố được nâng cao là do khi làm một test plan để test log-in form, anh phải xác định tất cả các trường hợp có thể xảy ra, như là:
1) nếu nhập sai username hoặc password thì thế nào
2) nếu sai một trong hai trường đó thì sao
3) nếu nhập ký tự đặc biệt thì sao…
Anh Nhiên cùng team meeting một dự án mới
Vì sao anh lại chọn trở thành Automation Tester thay vì Manual Tester hay Developer?
Từ năm 2004, anh được tiếp cận với Automation Test, sử dụng công cụ IBM Rational Robot. Anh thấy thích và anh nhìn nhận Automation Test là định hướng tốt, có tiềm năng phát triển cho nghề Tester.
Vì vậy, anh tự nghiên cứu và xây dựng nhiều Automation Testing Framework dựa trên Rational Robot, HP QTP/UFT, Selenium WebDriver, Test Complete, cũng như bắt đầu sự nghiệp với vị trí Automation Tester.
Anh nhận định xu hướng testing trong tương lai như thế nào?
Vài năm trở lại đây, vị trí Automation Tester đang là vị trí hot của tuyển dụng, từ những vị trí chuyên sâu về phát triển tool/framework/library đến những bạn có thể viết được script dựa trên một công cụ Automation Test nào đó.
Vì vậy, anh nghĩ Automation Test đang và sẽ là xu thế chung của ngành Tester.
Sai lầm lớn nhất anh từng mắc phải là gì? Anh vượt qua thế nào và anh học được gì từ nó?
Hai năm trước, khi đàm phán xây dựng một Automation Testing Framework cho khách hàng, anh cố đưa ra estimation rất thấp để ghi điểm cho công ty, rồi làm việc một mình để hoàn thành dự án đó, vì anh nghĩ những thành viên khác trong nhóm không chuyên về code nên nếu họ tham gia sẽ kéo tiến độ công việc xuống. Anh thường xuyên ngủ lại công ty để cố hoàn thành tiến độ đúng thỏa thuận.
Cuối cùng, dự án hoàn thành, được đánh giá cao từ phía khách hàng và công ty. Tuy nhiên từ đó, anh bị stress trầm trọng và gần như muốn xin nghỉ việc. Anh đi gặp Manager của mình và chia sẻ thì nhận được lời khuyên:
Em nên chia sẻ công việc cho người khác. Dù em làm chỉ cần 1 giờ, so với việc cho các thành viên khác có thể mất 5-6 giờ, em vẫn phải giao, vì team phát triển đồng đều mới bền vững.
Từ đó, mỗi lần đàm phán với khách hàng, anh đều dựa trên nền tảng khả năng chung của team.
Ngoài ra, anh cũng có những buổi chia sẻ kinh nghiệm để khuyến khích anh em nghiên cứu nhiều hơn về những công nghệ, kỹ năng cần thiết của một người Automation Tester.
Điều này giúp anh em cảm thấy được tin tưởng giao việc, được khuyến khích cùng nhau phát triển. Anh cũng không cảm thấy áp lực nặng nề nữa.
Một thử thách mà mọi Automation Tester nào khi vào nghề cũng gặp phải là gì?
Thử thách chính là giao tiếp với Developer. Khi mới vào nghề, tìm được bug, anh chỉ nói với Developer là ‘tôi thấy có lỗi ở chỗ này, kia, nọ, anh sửa đi’.
Lúc đó anh thường xuyên dính vào tranh cãi với developer vì
1) anh không chỉ ra chi tiết lỗi đó là gì, bị lỗi ngay bước nào
2) thái độ khi làm việc với Developer của anh không mang tính tích cực xây dựng sản phẩm, mà lại hơi có phần chỉ trích và đánh giá Developer
Sau này, khi được cấp trên hướng dẫn, mỗi khi tìm thấy bug, anh đều giao tiếp với Developer theo trình tự thế này:
1) Tóm lược vấn đề
2) Chỉ ra các bước cụ thể trong quy trình test của mình
3) Giải thích cụ thể là nó xảy ra lỗi gì
4) Nêu kết quả mong đợi
5) Cho Developer thấy hình ảnh screenshot bug mà mình tìm được
Anh nhận ra rằng mối quan hệ giữa Tester và Developer là quan hệ hỗ trợ lẫn nhau. Mục đích của Tester là tìm bug, nhưng vẫn hỗ trợ cho mục đích cuối cùng là làm sản phẩm tốt hơn. Không nên chỉ trích hay đánh giá Developer.
Xem thêm: Nghề Tester ở Việt Nam khổ vì định kiến
Những kỹ năng nào là cần thiết dành cho một Automation Tester?
1) Hiểu nguyên lý nhận dạng test objects. Nếu làm Web Automation Test cần nắm rõ HTML và XPath. Bạn có thể học hai mảng này ở W3School.
2) Hiểu nguyên lý lập trình, và thành thạo ít nhất một ngôn ngữ lập trình. Web Automation Engine được dùng phổ biến ở thị trường hiện nay là Selenium WebDriver, có kết hợp cho các ngôn ngữ Java, C#, Ruby, Python…
Ngoài ra các bạn có thể tham khảo thêm các ngôn ngữ scripting phổ biến như VBScript, JavaScript hoặc Groovy nếu cần.
3) Không bỏ qua SQL và XML. Hai mảng này bạn có thể học tại TutorialsPoint và W3School.
Đa số các dự án lập trình đều cần có cơ sở dữ liệu. XML được hiểu như một phần của portal database và SML cũng được sử dụng khá nhiều hiện nay.
4) Những bạn muốn đi sâu vào thiết kế tốt framework/common library thì nên tìm hiểu sâu về software design pattern.
5) Làm Automation Tester là liên quan đến coding nên các bạn cần quan tâm đến những kỹ năng của code như debug, source version control, coding convention, unit testing… Tìm kiếm các từ khoá này trên Google là thấy ngay tài liệu.
6) Nên ham học hỏi những cái mới trong chuyên môn.
Ví dụ, xu thế Automation Test và software development hiện tại là kỹ thuật tích hợp (integration). Đó là một chuỗi khép kín, tương tác giữa development, deploy và test. Anh đang nghiên cứu kỹ thuật này vì nó là xu hướng chung, không học hỏi sẽ bị tụt hậu.
3 lời khuyên anh dành cho các bạn Automation Tester trẻ để các bạn có thể thực hành ngay và cải thiện bản thân mình?
1) Phải xác nhận thông tin cẩn thận với khách hàng.
Có một lần, khi khách hàng đưa yêu cầu mới cho Automation Framework anh đang đảm trách. Mọi thứ trao đổi qua Skype, và dù mỗi tuần, anh báo cáo đầy đủ việc đã làm xong – đang làm – sẽ làm và vướng mắc nếu có, nhưng đến khi bàn giao sản phẩm, họ nói ‘đó không phải là cái chúng tôi muốn.’
Từ đó anh rút ra bài học là mỗi khi trao đổi với khách hàng, mình đều phải viết meeting minutes. Sau đó, gửi cho khách hàng và yêu cầu họ trả lời xác nhận email. Điều này giúp tránh xảy ra vấn đề hiểu nhầm hoặc khách hàng chối bỏ những yêu cầu mà họ đưa ra trước đó.
2) Không được bảo thủ.
Do có nhiều kinh nghiệm về tạo Automation Testing Framework, nên có một lần, khách hàng đưa ra đề nghị cho anh.
Để tốt hơn cho người sử dụng, framework nên hỗ trợ việc bắt các test object bằng nhãn. Những chữ hiện thấy (visible text) trên web page thay vì bắt người dùng phải tìm thông tin mang tính kỹ thuật như XPath.
Nghĩ mình có nhiều kinh nghiệm trong việc bắt XPath, anh cố gắng bảo vệ quan điểm của mình và thuyết phục khách hàng rằng như vậy là không chính xác + mất nhiều thời gian xử lý.
Nhưng sau một thời gian trao đổi + suy nghĩ, anh thấy cách của khách hàng là một hướng đi mới cũng rất khả quan.
Dù có nhiều khó khăn, nhưng mình nên tìm cách giải quyết thay vì bác bỏ ngay từ đầu.
Cuối cùng, anh quyết định làm theo yêu cầu của khách hàng, và dự án đó thành công.
3) Tư vấn không có nghĩa là quyết định.
Có lần anh làm việc với một khách hàng Mỹ, và xảy ra tranh luận về quan điểm. Họ muốn anh làm cách A, nhưng với kinh nghiệm của mình, anh biết đó không phải là lựa chọn tốt, anh thuyết phục họ làm theo cách B của anh.
Cuộc tranh luận ngày càng gay gắt và sếp anh kịp thời can thiệp. Sếp chỉ cho anh biết rằng: là người tư vấn, anh nên chỉ cho khách hàng biết họ có những lựa chọn nào, thuận lợi – khó khăn của từng lựa chọn.
Rồi khách hàng mới là người quyết định chọn cái nào và chính họ chịu trách nhiệm về sự lựa chọn đó.
Cuối cùng, anh làm theo cách A của khách hàng. Nhưng sau khi chạy dự án một thời gian, họ nhận ra cách của họ không phù hợp nên họ yêu cầu chuyển sang làm cách B của anh.
Cuối cùng, dự án phát sinh thêm một số chi phí. Nhưng khách hàng hiểu vấn đề là do họ chọn sai cách nên họ sẵn lòng trả thêm. Dự án vẫn thành công.
Trong suốt sự nghiệp của mình, anh có thường xuyên tham khảo sách/ resource nào không?
Anh có tham khảo hai quyển sách.
1) Automated Testing Handbook. Quyển sách này mô tả rõ ràng và đầy đủ các đặc điểm chính và các tính năng tìm kiếm trong một bộ kiểm tra tự động.
2) Experiences Of Test Automation. Những cách tiếp cận vấn đề phù hợp, các ứng dụng nào có thể áp dụng Automation Test, và Automation Test thay đổi như thế nào. Đây là ba vấn đề trọng điểm được bao quát trong quyển sách này.
Một bạn nếu chọn phát triển sự nghiệp theo định hướng Tester thì bạn đó sẽ có những hướng phát triển nào?
Trường đại học ít khi dạy kỹ năng testing để trở thành Tester. Thông thường các bạn phải tham gia một chương trình đạo tạo ngắn hạn. Ví dụ như Launch Program ở KMS Technology để chuẩn bị bước vào nghề Tester.
Từ Junior Tester, các bạn có thể phát triển lên Senior Tester. Rồi từ đó có hai hướng chính cho bạn phát triển.
1) Đi theo hướng quản lý, tức là bạn thăng tiến lên làm Tester Lead, sau đó là Tester Manager.
2) Đi theo hướng kỹ thuật, giống như anh, hiện tại anh là Tester Architect.
Tiểu sử:
Sau khi tốt nghiệp Đại Học Cần Thơ năm 2003 chuyên ngành CNTT, anh Nhiên lên Tp. HCM làm khoảng 1 năm cho Đại Học Bách Khoa ở vị trí Software Developer.
Trong 2 năm tiếp theo, anh làm Software Tester Leader tại Global CyberSoft.
5 năm sau đó, anh công tác ở Ndex Technologies lần lượt ở vị trí QC Leader và QC Manager.
Anh làm Software Department Manager trong 1 năm tiếp theo. 1 năm sau đó anh làm Automation Tester Leader tại Sunrise Software Solutions Corporation.
Trong 1 năm tiếp theo, anh tiếp tục công tác tại vị trí Automation Tester Leader tại COSATECH.
Bắt đầu từ tháng 5 năm 2015, anh bắt đầu làm việc tại KMS Technology ở vị trí Senior Automation Tester.
Xem thêm các việc làm Automation Tester tại ITviec
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é!
P.S. Thỉnh thoảng, anh Nhiên tổ chức thêm các lớp dạy Automation Test dành cho các bạn Manual Tester muốn chuyển hướng sự nghiệp sang làm Automation Tester, bởi vì hiện nay chưa có trường lớp chính quy nào dạy về vấn đề này. Đến hiện tại anh đã dạy được 4-5 lớp. Bạn nào có nhu cầu học thì có thể liên hệ anh qua email tmsnhien@gmail.com.