❤️ Tester là người chịu trách nhiệm cho các hoạt động (công việc) kiểm thử trong một dự án phát triển phần mềm. Tùy công ty sẽ có tên gọi cho vai trò này khác nhau như Tester (kiểm thử viên), QC (Quality Control – nhân viên kiểm soát chất lượng), QA (Quality Assurance – nhân viên bảo đảm chất lượng), chỉ là QA Engineer (QAE – kỹ sư chất lượng). Vì thế bạn đừng quá quan tâm vào tên gọi của vị trí này, thay vào đó bạn hãy quan tâm đến mô tả công việc (job description) khi tìm hiểu và muốn nộp hồ sơ vào công ty nào đó.
Tuy chúng ta đều là tester đang đi làm, nhưng bạn có biết rằng công việc tester ở mỗi dự án, công ty có thể khác nhau không? Có bạn tester phải viết hướng dẫn sử dụng cho sản phẩm mà mình đang kiểm thử; Có tester thì phải đi gặp khách hàng để thu thập yêu cầu và viết tài liệu mô tả cho nhóm phát triển phần mềm; Có bạn phải làm cả manual testing (kiểm thử thủ công) và automation testing (kiểm thử tự động).
Trong bài viết này mình sẽ giới thiệu công việc chung của tester trong công ty outsourcing và công ty phát triển sản phẩm (các bạn hay gọi “công ty product”). Qua đó giúp các bạn đang tìm hiểu về nghề tester có được cái nhìn tổng quát về công việc kiểm thử phần mềm này.
Mời bạn xem video giải thích chi tiết về Nghề Tester
Tại sao cần phải kiểm thử?
Trước khi nói về công việc của tester trong một dự án thì mình sẽ giới thiệu sơ về lý do tại sao cần phải có nhân viên kiểm thử.
Quá trình phát triển phần mềm cơ bản bao gồm các giai đoạn:
- Thu thập và phân tích yêu cầu
- Thiết kế hệ thống phần mềm
- Lập trình (phát triển, xây dựng ra phần mềm)
- Kiểm thử
- Khách hàng nghiệm thu và triển khai sử dụng thực tế
Trong các giai đoạn trên đều có sự tham gia của con người nên có khả năng xảy ra sai sót. Ví dụ nhân viên phân tích nghiệp vụ (BA – Business Analyst) hoặc PM (Product Manager) có sai sót trong quá trình thu thập, phân tích, và mô tả yêu cầu dẫn đến có khiếm khuyết (defect/bug) trong tài liệu mô tả yêu cầu chức năng của hệ thống. Lập trình viên dựa vào tài liệu sai đó để lập trình, dẫn đến sản phẩm (product/system) được phát triển đó không hoạt động như khách hàng mong đợi.
Nếu may mắn, lỗi này được phát hiện trong quá trình kiểm thử thì cũng tốn thời gian công sức để sửa lại tài liệu mô tả yêu cầu, lập trình lại phần chức năng bị sai đó. Tester phải test lại để xác nhận lỗi này đã được sửa thành công (gọi là confirmation testing), bên cạnh đó phải kiểm thử lại những chức năng liên quan để bảo đảm chúng vẫn còn hoạt động bình thường (hoạt động này được gọi là regression testing – kiểm thử hồi quy).
Tùy vào mức độ nghiêm trọng của lỗi, nhẹ thì có thể làm khách hàng mất thời gian hoặc bực mình, nặng hơn thì có thể dẫn đến mất nhiều tiền (ví dụ các hệ thống thanh toán trực tuyến) của khách hàng, người dùng, và công ty vận hành hệ thống. Ví dụ một tổ chức tín dụng có lỗi bảo mật dẫn đến lộ thông tin người dùng, và kẻ gian đã sử dụng những thông tin đó để thực hiện những giao dịch mua hàng ở lãnh thổ khác mà người dùng chứng minh rằng họ không phải là người thực hiện giao dịch đó, thì tổ chức tín dụng đó phải hoàn trả lại tiền cho khách hàng, và tổ chức này bị thiệt hại phần tiền đó. Thử tưởng tượng bạn ngồi trong một một chiếc ô tô tự lái, và nó có lỗi liên quan đến bộ phận kiểm soát tốc độ và phanh xe? Nếu có vấn đề thì thiệt hại là ảnh hưởng đến trực tiếp sức khỏe, tính mạng con người.
Đó là lý do tại sao phần mềm cần phải được kiểm thử trước khi đưa vào sử dụng thực tế nhằm giảm khả năng xảy ra những lỗi và sự cố trên. Tùy vào thể loại phần mềm mà việc kiểm thử được tiến hành sơ sài hoặc có thể bỏ qua, hay phải kiểm thử nghiêm ngặt và kỹ càng ở nhiều mức khác nhau từ kiểm thử đơn vị (unit testing) đến kiểm thử ở mức hệ thống (system testing).
Công việc thường ngày của tester là gì
Vậy công việc thường ngày của tester bao gồm những việc gì? Công việc cụ thể chi tiết của từng tester phần lớn sẽ phụ thuộc vào mô hình phát triển phần mềm và loại hình phát triển phần mềm của công ty đó.
Với các nhóm dự án gia công phần mềm (outsourcing) thì tester chủ yếu là đọc và phân tích tài liệu mô tả yêu cầu (chi tiết) để viết test case, chuẩn bị cài đặt môi trường cần thiết như các trình duyệt hoặc công cụ cần để kiểm thử, tạo dữ liệu liên quan, và thực thi các test case đã viết để kiểm thử một màn hình/chức năng nào đó sau khi lập trình viên (dev – developer) đã lập trình xong. Trong các dự án này, mục tiêu chính của việc kiểm thử có thể là bảo đảm phần mềm (sản phẩm – product) đã đáp ứng toàn bộ các yêu cầu đã mô tả (từ khách hàng). Nên tester chỉ chú trọng vào việc bảo đảm mọi yêu cầu đã được đáp ứng.
Có thể nói công việc của một tester trong dự án gia công phần mềm:
- Đọc và phân tích tài liệu yêu cầu
- Viết test case (thường là chi tiết đầy đủ)
- Chuẩn bị môi trường và dữ liệu kiểm thử (test data)
- Thực hiện test case và post bug nếu có
- Kiểm thử lại bug (cả confirmation và regression testing)
Ngược lại, đối với một nhóm phát triển phần mềm của “công ty product” (công ty tự phát triển và kinh doanh/kiếm tiền từ chính sản phẩm phần mềm đó) thì công việc của tester sẽ có phần phần khác hơn do mục tiêu kiểm thử trong dự án này khác với nhóm gia công phần mềm. Ngoài những công việc tương tự như trên, Tester trong nhóm phát triển sản phẩm còn phải tìm hiểu kỹ về nghiệp vụ, hiểu rõ về lĩnh vực hoạt động của phần mềm (domain knowledge) mình đang tham gia kiểm thử. Ví dụ, đó là ứng dụng giao hàng. Thì tester phải tìm hiểu nghiệp vụ giao hàng, các bên liên quan (personas) trong hệ thống này (ít nhất là người giao hàng, người mua hàng/nhận hàng, người bán hàng) và các nghiệp vụ cơ bản như giao hàng, đổi hàng, đổi địa chỉ, hủy đơn hàng, liên lạc người mua không được,… thì phần mềm sẽ phải xử lý thế nào? Từ đó tester có thể lên kế hoạch và xác thực (validate) một yêu cầu có đáp ứng được nhu cầu sử dụng trong thực tế hay không. Việc làm rõ và chứng minh tính hợp lệ của một yêu cầu từ lúc nó được đưa ra (thường là từ Product Owner hoặc Product Manager) giúp tiết kiệm thời gian và giảm chi phí cho quá trình phát triển một chức năng nào đó.
Tóm lại công việc cơ bản của một tester trong nhóm phát triển sản phẩm gồm:
- Tham gia quá trình thảo luận yêu cầu và đề xuất ý kiến cho chức năng mới
- Tìm hiểu về người dùng (end user) và cách họ sử dụng sản phẩm
- Tìm hiểu về ngành nghề hoạt động của phần mềm đang kiểm thử
- Viết test case (thường là cơ bản, hoặc checklist)
- Kiểm thử trên môi trường non-production và production
Tương tự, công việc của tester sẽ khác nhau trong các nhóm áp dụng mô hình truyền thống như V-model và mô hình Scrum. Những kỹ năng cần thiết sẽ khác nhau. Trong mô hình Scrum thì tester đòi hỏi ngoài kỹ năng kiểm thử thủ công tốt thì còn phải biết kiểm thử tự động. Và đặc biệt là kỹ năng Exploratory Testing là rất cần thiết vì mỗi sprint sẽ không có nhiều thời gian để viết test case và kiểm thử chi tiết.
Con đường sự nghiệp của một tester
Dù bạn xuất thân là dân công nghệ thông tin (IT) hay trái ngành (non-IT), dự định làm manual tester hay automation tester thì ban đầu cũng nên nắm vững kiến thức kiểm thử phần mềm để phát triển cao và xa hơn trong tương lai.
Ban đầu bạn nên làm manual để hiểu rõ hơn về kiểm thử phần mềm và áp dụng nhuần nhuyễn các kỹ thuật kiểm thử như phân vùng tương đương và phân tích giá trị biên, kiểm thử dựa vào bảng quyết định (decision table testing), hoặc kiểm thử dựa vào chuyển đổi trạng thái (state transition testing). Sau đó bạn học một ngôn ngữ lập trình nào đó như Java, Python và áp dụng một thư viện (ví dụ Selenium) hoặc công cụ kiểm thử nào đó (như Appium, Katalon Studio, Cypress) để làm automation. Automation tester (gọi đúng là test automation expert – người có chuyên môn hóa là kiểm thử tự động) thì cũng giống như lập trình viên vì test automation tool (công cụ kiểm thử tự động) là một phần mềm có mục đích là để kiểm thử phần mềm khác (là ứng dụng, mà nhóm bạn đang phát triển – hay được gọi là AUT | Application Under Test).
Sau này khi bạn đã nắm vững kiến thức và kỹ năng kiểm thử phần mềm, bạn có thể phát triển theo hướng chuyên môn hóa như kiểm thử tự động vừa được đề cập, hoặc kiểm thử hiệu năng (performance test specialist) hay kiểm thử bảo mật (security testing). Bạn cũng có thể phát triển chuyên sâu một mảng công việc như chuyên kiểm thử ứng dụng web, ứng dụng trên điện thoại (mobile testing), kiểm thử phần mềm nhúng (embedded testing), kiểm thử game (trò chơi điện tử), v.v… Về sau này trong tương lai, mỗi ngách này đều có mặt thuận lợi và bất lợi riêng của chúng. Ví dụ bạn rất khó để chuyển sang tìm kiếm một công việc ở ngách khác.
Nếu bạn không muốn phát triển theo hướng kỹ thuật như trên thì bạn hoàn toàn có thể phát triển theo hướng quản lý đội nhóm. Công việc này không đòi hỏi kiến thức về kỹ thuật (như phải học chuyên ngành IT) mà đòi hỏi bạn phải khéo léo, có kỹ năng giao tiếp, đàm phán, quản lý thời gian và công việc tốt. Bạn sẽ quản lý nhóm, ước lượng công việc và bao gồm quản lý tiến độ công việc. Bạn sẽ nắm giữ vai trò Test Leader, Test Manager.
Hoặc bạn có thể chuyển hướng sang BA (phân tích nghiệp vụ) hoặc PM/PO (quản lý dự án, quản lý và phát triển sản phẩm). Nếu bạn giỏi tiếng Nhật có thể làm BSE (Kỹ sư cầu nối) hoặc Comor (Người biên dịch tài liệu và phiên dịch trong các buổi họp). Hoặc chán làm phần mềm thì về buôn bán bất động sản hoặc tiền kỹ thuật số 😀
Mời bạn xem cách để được lương cao hơn Software Tester's guide to Higher pay
Bạn có phù hợp với công việc này không?
Để làm tốt công việc tester, bạn phải có tính cẩn thận. Nói đến cẩn thận chắc xe ôm công nghệ là cần nhất vì phải chạy xe ngoài đường nhiều 😀 Nói vậy thôi chứ nghề gì mà không phải cẩn thận chứ. Có nghề nào cần người làm việc cẩu thả đâu.
Tính tò mò (curiosity) là một trong những đức tính rất cần đối với tester. Với tính tò mò bạn sẽ luôn tự hỏi “chuyện gì sẽ xảy ra nếu như tôi thao tác thế này, thế này…?” Tính tò mò kết hợp với kiến thức về hệ thống và mối liên quan giữa các chức năng trong hệ thống giúp bạn phát hiện rủi ro sớm, có khi ngay từ lúc yêu cầu của một tính năng mới được đưa ra, hoặc khi khách hàng muốn thay đổi một chức năng hiện có nào đó. Thường những bug (lỗi) được phát hiện bởi tính tò mò này rất khó để sửa. Đôi khi cần phải thay đổi lại thiết kế của phần nào đó để khắc phục lỗi đó. Tính tò mò giúp ích nhiều trong lúc thực hiện exploratory testing.
Người có tính đa nghi (chủ nghĩa hoài nghi – skeptical). Thường thì bạn ít có tin cái gì đó cho đến khi bạn tận mắt chứng kiến hoặc trải nghiệm. Nó giúp cho tester không dễ bỏ qua các trường hợp mà mình chưa kiểm thử (test). Như vậy thì khi mình kiểm thử xong kết quả dù pass hay fail (đạt hay không) thì mình cũng biết được khả năng xảy ra của một rủi ro nào đó. Khi chưa kiểm thử thì nó là rủi ro, khi test rồi thì có 2 trường hợp:
- Có lỗi: rủi ro (risk) đó đã biến thành sự cố (problem/incident)
- Không có lỗi: rủi ro đó không còn là rủi ro nữa vì trường hợp đó không xảy ra (ít nhất là trên môi trường thử nghiệm).
Người có tính cầu toàn (hãy là “motivation for good” chứ đừng là perfectionist). Bạn luôn nghĩ về một phiên bản tốt hơn hiện tại. Tuy nhiên, bạn nên dừng lại ở mức độ TỐT thôi chứ đừng đòi hỏi HOÀN HẢO. Vì nếu đòi hỏi hoàn hảo thì nhóm của bạn rất mất thời gian để sửa (fix) những lỗi về giao diện hoặc không liên quan trực tiếp đến yêu cầu chính. Có thể dẫn đến việc release trễ hoặc không bao giờ release được sản phẩm.
Tóm lại, làm tester không hề khó. Ai cũng có thể làm được miễn bạn tìm được niềm vui trong công việc hoặc động lực để bạn học và làm tester. Mình đã từng chứng kiến rất nhiều học viên là người trái ngành (non_IT) và đang làm tốt công việc kiểm thử phần mềm, thậm chí là ở vị trí cao nữa là khác. Tuy nhiên để phát triển xa hơn và cao hơn trong công việc này đòi hỏi bạn phải học hỏi không ngừng nghỉ, học cả đời chứ không phải trong một vài tháng. Mình hay nói trong lớp Fresher Tester là mình dạy các bạn cách câu cá rồi các sẽ bạn tự câu. Sau này các bạn tự tìm kiếm kỹ năng câu tốt hơn và nơi có nhiều cá hơn để câu. Nhiều bạn giờ câu tốt hơn, năng suất hơn mình rất nhiều.
Thân.
Hoàng Liên Sơn
Mời bạn xem video giải thích chi tiết về Nghề Tester