Tiểu sử. Sau khi tốt nghiệp Đại học Cần Thơ năm 2003 chuyên ngành CNTT, anh 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 QA Leader tại Global CyberSoft. 5 năm sau đó, lần đầu tiên anh công tác tại Ndex Technologies ở 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 QA Leader at 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 QA 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 QA
Sự khác nhau giữa manual test và automatic test là gì ạ?
Lúc trước, phần kiểm tra công thức phần mềm phổ biến là kiểm tra thủ công. Ví dụ để kiểm tra biểu mẫu đăng nhập, một QA thủ công sẽ tự động nhập tên người dùng, mật khẩu vào tay, nhấp vào “đăng nhập,” xem kết quả đăng nhập thành công hay không
Một QA tự động sẽ viết kịch bản để chạy tự động tất cả các bước bao gồm nhập thông tin, nhấp chuột, 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 thử nghiệm có thể thực hiện tự động, ví dụ như thử nghiệm chức năng, thử nghiệm hiệu suất/tải, thử nghiệm đơn vị
Điểm cộng và điểm trừ của kiểm thử tự động so với kiểm thử thủ công là gì?
Điểm cộng của kiểm thử tự động là
1] Đáng tin cậy. Chạy thử chính xác theo quy trình đã có sẵn, vì vậy tránh được nhiều lỗi do người tạo ra, ví dụ như nhập sai dữ liệu
2] Mình có thể test cách xử lý phần mềm [tính năng/hiệu năng] khi gặp sự cố chạy lặp lại nhiều lần [cùng lúc] trên cùng script test. This also call is performance/load testing
3] Mình có thể thiết lập nhiều trình kiểm tra tinh vi hơn để thu thập các thông tin ẩn từ ứng dụng. At this point, manual test could not doing
4] Kiểm tra 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ả cá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 phẩm xuất phần mềm, chúng ta cần thử nghiệm sản phẩm một lần ở nhiều môi trường. 1] môi trường thử nghiệm, 2] môi trường beta, 3] môi trường sản xuất. Nếu chạy manual test thì một test case mất một tiếng, ba môi trường tiề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 test script, mỗi lần triển khai 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 của phần mềm tốt hơn bởi vì mình có thể chạy nhiều bài kiểm tra trong thời gian ngắn hơn với ít tài nguyên nhất
7] Công cụ tự động giúp chạy test nhanh hơn test 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
Điểm trừ của bài kiểm tra tự động là
1] Nhiều công cụ có chi phí rất cao, ví dụ như công cụ thương mại, chẳng hạn như HP Quick Test Pro
2] Thường thì trả lương cho QA tự động hóa nhiều hơn QA thủ công, vì công việc yêu cầu 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ụ test case if test manual thì mất 1 tiếng. Nhưng nếu chuyển sang chạy thử nghiệm tự động, cần chuẩn bị sẵn 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à công cụ để chạy test. Vì vậy chi phí cho kiểm tra tự động cao hơn kiểm tra thủ công
4] Đòi hỏi QA phải có kinh nghiệm kỹ thuật và kỹ năng lập trình
5] Yêu cầu thời gian tiêu chuẩn dài hơn để thiết kế, cài đặt kỹ càng hơn trước khi cần đưa dự án đi kiểm tra
6] Có những dự án không nên chạy auto test, nhưng nhiều QA vẫn hiểu nhầm và chạy auto test, dẫn đến mất thời gian, tài nguyên, công sức. Ví dụ như khi kiểm tra một chức năng quá phức tạp của một ứng dụng hoặc một đối tượng GUI thì phải chạy kiểm tra thủ công
Công việc, nhiệm vụ thường ngày của anh là gì?
Với vị trí Automated QA Architect, xác định các tính năng của khung kiểm thử tự động, hỗ trợ phát triển khung để thực hiện kiểm thử tự động
Điểm cộng và điểm trừ của công việc QA tự động hóa là gì ạ?
Điểm cộng của nghề này là nó giúp nâng cao kỹ năng phân tích vấn đề và kỹ năng quản lý sự cố. Điểm trừ là lúc đầu, anh hay cãi vào tranh cãi với team development về các lỗi 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 ví dụ như khi lập một kế hoạch thử nghiệm để kiểm tra biểu mẫu đăng nhập, bạn phải xác định tất cả các trường hợp có thể xảy ra, như là 1
Vì sao anh lại chọn trở thành QA tự động hóa thay vì QA thủ công hay Developer?
Từ năm 2004, anh tiếp cận với kiểm tra tự động, sử dụng công cụ IBM Rational Robot. Anh thấy thích và anh nhìn nhận kiểm thử tự động là định hướng tốt, có tiềm năng phát triển cho nghề QA. Vì vậy, anh tự nghiên cứu và xây dựng khung kiểm thử tự động nhều 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í QA tự động
Anh nhận định xu hướng thử nghiệm trong tương lai như thế nào?
năm trở lại đây, vị trí QA tự động đ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 công cụ/framework/thư viện cho đến những bạn có thể viết được kịch bản dựa trên một công cụ kiểm thử tự động nào đó. Vì vậy, anh nghĩ kiểm thử tự động đang và sẽ là xu thế chung của ngành QA
Sai lầm lớn nhất anh từng thắc mắc phải là gì?
Hai năm trước, khi đàm phán xây dựng khung kiểm thử tự động hóa cho khách hàng, anh cố gắng đưa ra ước tính 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 . Anh thường xuyên ngủ lại công ty để hoàn thành đúng tiến độ 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à anh 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ờ, nên với công việc của 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 không gian
Từ đó, mỗi lần phán xét với khách hàng, anh đều dựa trên nền tảng khả năng chung của đội ngũ. 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 QA tự động. Đ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 QA tự động hóa nào khi vào nghề cũng gặp phải là gì?
Try to master is interface with developer. Khi mới vào nghề, tìm được bug, anh chỉ nói với developer là ‘tôi thấy có bug ở chỗ này, chỗ kia, chỗ nọ, anh sửa đi’. Lúc đó anh thường xuyên xuyên 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
Sau này, khi được cấp theo hướng dẫn, mỗi khi tìm thấy lỗi, anh đều giao tiếp với nhà phát triển theo trình tự thế này
1] Tóm tắt vấn đề
2] Chỉ ra các bước cụ thể trong quy trình kiểm tra của mình
3] Giải thích cụ thể là nó xảy ra lỗi gì
4] Unexpected results
5] Cho nhà phát triển thấy lỗi ảnh chụp màn hình mà mình tìm thấy
Anh nhận ra rằng mối quan hệ giữa QA và developer là quan hệ hỗ trợ lẫn nhau. Mục đích của QA là tìm lỗi, nhưng vẫn hỗ trợ cho mục đích cuối cùng là làm cho sản phẩm tốt hơn, chứ không phải chỉ là trích dẫn, đánh giá nhà phát triển
Những kỹ năng nào cần thiết dành cho một QA tự động hóa?
1] Nguyên lý nhận định dạng đối tượng thử nghiệm. Nếu làm web tự động kiểm tra cần xác định HTML và XPath. You can learn this array at W3School
2] Hiểu nguyên lý lập trình, và thành công tối thiểu một ngôn ngữ lập trình. Công cụ tự động hóa web được sử dụng phổ biến trên thị trường hiện nay là Selenium WebDriver, có sự kết hợp với 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 biến ngôn ngữ kịch bản phổ biến như VBScript, JavaScript
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 number of the projected projectđều cần có cơ sở hạ tầng. XML được hiểu như một phần của cơ sở dữ liệu cổng thông tin 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 design good framework/common library thì nên tìm hiểu sâu về software design pattern
5] Làm QA tự động là liên quan đến mã hóa nên các bạn cần quan tâm đến những kỹ năng của mã như gỡ lỗi, kiểm soát phiên bản nguồn, quy ước mã hóa, kiểm tra đơn vị… Tìm kiếm các từ khóa này trên Google là tài liệu được tìm thấy ngay
6] Nên ham học hỏi những cái mới trong chuyên môn. Ví dụ, xu thế kiểm thử tự động và phát triển phần mềm hiện tại là kỹ thuật tích hợp [tích hợp]. Đó là một chuỗi khép kín, tương tác giữa phát triển, triển khai và kiểm tra. Anh đang nghiên cứu kỹ thuật này, vì nó là xu hướng chung, mình không nghiên cứu sẽ bị phản công
Lời khuyến khích anh dành cho các bạn tự động hóa QA trẻ để các bạn có thể thực hiện hành động 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 ra yêu cầu mới cho khung tự động hóa anh ta đang nghiền ngẫm. Mọi thứ trao đổi qua Skype, và dù mỗi tuần, anh báo cáo đầy đủ những việc đã làm xong – đang làm – sẽ làm và bối rối nếu có, nhưng đến khi bàn giao sản phẩm, họ nói 'đó không phải là cái của họ . ’
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 biên bản họp, gửi cho khách hàng và yêu cầu họ trả lời xác nhận email đó, để tránh xảy ra sự cố hiểu nhầm hoặc khách hàng từ chối
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 đề nghị anh là để tốt hơn cho người sử dụng, framework của anh nên hỗ trợ bắt các đối tượng kiểm tra bằng nhãn, các chữ hiện thấy [có thể nhìn thấy]
Nghĩ mình có nhiều kinh nghiệm trong công 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ự kiế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ỹ, 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.
Cuộc tranh luận ngày càng gay gắt, và thời gian anh bỏ thời gian can thiệ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 cách B của anh. Cuối cùng, dự án phát sinh thêm một số phí, nhưng khách hàng hiểu vấn đề là họ chọn sai cách nên sẵn sàng trả thêm. Project is public
Trong suốt sự nghiệp của mình, anh có thường xuyên tham khảo sách/tài nguyên nào không?
Anh has tham khảo hai cuốn sách
1] Cẩm nang kiểm thử tự động. Cuố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 được tìm kiếm trong một bộ kiểm tra tự động
2] Kinh nghiệm kiểm thử tự động. Những cách tiếp cận vấn đề phù hợp, ứng dụng nào có thể áp dụng kiểm tra tự động và kiểm tra tự động thay đổi như thế nào. Đây là ba vấn đề quan trọng được bao hàm trong cuốn sách này
Một bạn nếu chọn phát triển sự nghiệp theo định hướng QA thì bạn sẽ có những hướng phát triển nào?
Trường đại học ít khi dạy kiểm tra kỹ năng để trở thành QA. Thông thường các bạn phải tham gia một chương trình đạo tạo thời hạn ngắn, ví dụ như Chương trình khởi chạy tại KMS Technology để chuẩn bị bước vào nghề QA
Từ Junior QA, các bạn có thể phát triển lên Senior QA. Rồi từ đó có hai hướng chính cho bạn phát triển