Theo báo cáo từ State of Testing, kiểm thử phần mềm đang là ngành công nghiệp phát triển đứng top đầu hiện nay. Đây không phải là điều đáng ngạc nhiên khi có ngày càng nhiều người yêu thích và muốn trở thành người kiểm thử. Dễ nhận thấy nhất đó là mức thu nhập ổn định mà công việc này đem lại và về cơ bản nó cũng cao hơn so với nhiều ngành nghề khác.

Đây chính là những chia sẻ chân thành từ những người đồng nghiệp đi trước của mình. Tôi vui mừng khi nghe điều đó và hạnh phúc cho họ.

Nhưng cũng có không ít những lời phàn nàn từ mọi người rằng họ không thích kiểm thử phần mềm. Sau một thời gian theo đuổi nó, họ cảm thấy như bản thân đã chọn sai con đường, lãng phí thời gian và công sức của mình.

Câu hỏi đặt ra: Tại sao họ lại không vui? Tại sao họ không yêu thích công việc mà chính mình đã chọn? Có cách nào để giúp mọi người quan tâm, yêu thích và có niềm đam mê với kiểm thử ngay từ lần đầu tiếp cận với nó hay không?

Có một số lý do để giải thích tại sao điều đó xảy ra, nhưng một lý do lớn và thực tại nhất đó là: sự vỡ mộng.

Có một số bộ phận sẽ nghĩ rằng việc kiểm thử phần mềm rất đơn giản và dễ dàng, nhưng đi vào thực tế thì sẽ trái ngược hoàn toàn. Hiện tại diễn ra luôn khác với những điều mà chúng ta mơ mộng.

Họ nghĩ đơn giản rằng kiểm thử phần mềm là tìm ra lỗi, bây giờ họ nhận ra có nhiều hoạt động cần làm liên quan đến nó hơn. Họ bối rối và không chắc chắn rằng liệu kiểm thử có phải là con đường phù hợp mà bản thân họ muốn theo đuổi hay không?

Suy nghĩ ấy chắc chắn là rất tệ và đáng buồn hơn nếu nó xảy ra. Tuy nhiên, bạn có thể tránh rơi vào tình huống như vậy bằng cách hãy tìm hiểu những kiến thức căn bản về kiểm thử, biết kiểm thử phần mềm trông như thế nào, hoạt động kiểm thử nào đang chờ bạn phía trước. Từ đó đưa đến quyết định xem bạn có muốn hòa hợp với nó ngay từ đầu không. Đây chính là nội dung mà tôi muốn chia sẻ đến mọi người thông qua bài viết này.

Lưu ý: Trước khi bắt đầu đọc các hoạt động kiểm thử trong bài viết, xin lưu ý các hoạt động kiểm thử phần mềm không giới hạn ở những gì tôi đã đề cập trong bài viết này. Dựa trên kinh nghiệm và hiểu biết của mình, tôi sẽ cố gắng liệt kê một số hoạt động cơ bản và trình bày lại cho mọi người dễ hiểu nhất nhưng có một điều chắc chắn nó không phải là danh sách đẩy đủ nhất về các hoạt động. Đồng thời, hãy lưu ý một số công ty sử dụng các thuật ngữ khác nhau để đề cập đến những hoạt động tương tự mà tôi trình bày trong bài viết này.

Bây giờ, hãy bắt đâù.

1) Đọc các loại tài liệu

Cuối cùng bạn đã được tuyển dụng, sau nhiều lần trao đổi cho dù đó là những buổi phỏng vấn với các câu hỏi chuyên môn khó hay những câu hỏi đơn giản, nhưng điều đó không còn quan trọng nữa. Bây giờ bạn đủ điều kiện cho vị trí này và bạn chính thức là một người kiểm thử.

Ngày đầu tiên đi làm, bạn sẽ được giới thiệu với các thành viên trong team. Sau khi tìm hiểu nhau, bạn sẽ bắt tay vào nhiệm vụ đầu tiên của mình.

Người quản lí của bạn sẽ nói: "Đây là tài liệu của dự án, em hãy bắt đầu đọc và tìm hiểu chúng đi" .

Hơi phóng đại một chút nhưng về cơ bản, bạn sẽ được giao một nhiệm vụ để đọc một số tài liệu như đặc tả, hướng dẫn, trợ giúp, v.v để bạn biết thêm về hệ thống mà mình sẽ kiểm tra.

Trong khi một số bạn háo hức vẽ ra cho mình một viễn cảnh mong đợi trở thành một ngôi sao, mình sẽ tìm ra rất nhiều bug ngay ngày đầu tiên đi làm khiến người quản lý của bạn kinh ngạc. Nhưng không phải như vậy, đọc tài liệu để hiểu hệ thống đang thử nghiệm là một trong những điều đầu tiên bạn phải làm trong dự án.

Nếu bạn không có bất kỳ câu hỏi nào, bạn không thể có bất kỳ tài liệu nào, hãy hỏi người quản lý của bạn để hiểu về hệ thống.

Bạn cũng có thể sử dụng kiến thức bạn có được để bắt đầu các hoạt động kiểm tra khác như viết ra các trường hợp kiểm thử.

Hoạt động này kéo dài bao lâu?

Một số dự án nhỏ, bạn cần phải mất 1-2 ngày để đọc tài liệu. Một số dự án lớn, có thể bạn sẽ mất nhiều thời gian hơn.

Có một câu hỏi đặt ra là: Hoạt động này thú vị đến mức nào? Câu trả lời đó là: Nó rất nhàm chán. Nó thậm chí còn nhàm chán hơn trong một số trường hợp khi bạn không có quyền truy cập vào hệ thống trong khi đọc tài liệu. Không có tài liệu, hình ảnh để mô tả cụ thể về các chức năng trong hệ thống đó.

Tuy nhiên hoạt động này rất quan trọng. Nó quan trọng đến mức nào? Nếu bạn càng biết nhiều về hệ thống đang thử nghiệm, bạn có thể viết ra các trường hợp kiểm thử hoặc tìm ra lỗi nhiều hơn.

2) Test case design or test case writing

Nếu dự án của bạn tham gia là một dự án cổ điển theo vòng đời phát triển phần mềm truyền thống thì đây là công việc chắc chắn bạn sẽ phải làm.

Hoạt động này được gọi là thiết kế các trường hợp kiểm thử ( create testcase).

Nếu bạn chưa hiểu hay có nhiều kinh nghiệm về họat động này, hãy tham khảo thêm các tài liệu trên internet hoặc đọc các tài liệu về ISTQB để nâng cao khả năng. Tập xây dựng các viewpoint (quan điểm test) để test theo sơ đồ tư duy. Tìm hiểu thêm về các kĩ thuật viết testcase( Phân vùng tương đương, phân tích giá trị biên, bảng quyết định,...) để tạo ra được các trường hợp kiểm thử tối ưu và hiệu quả nhất.

Điều đó nghe có vẻ quá sức nhưng đừng lo lắng. Thông thường, người quản lý của bạn sẽ cung cấp cho bạn một số tài liệu hướng dẫn về cách thiết kế các trường hợp kiểm thử có sẵn của công ty hay dự án. Từ đó bạn có thể làm theo dễ dàng.

Một hoạt động cần đi kèm việc thiết kế testcase đó là:

Xem xét các trường hợp kiểm thử: Vì bạn là người mới, bạn sẽ được mọi người chú ý đến các thiết kế testcase mà bạn tạo ra. Họ sẽ review và góp ý giúp bạn để đảm bảo các trường hợp thử nghiệm mà bạn đưa ra đúng và đủ luồng hoạt động.

Nếu bạn thực hiện đúng ngay lần đầu tiên, thì điều đó thật tuyệt! Nhưng nếu như bạn có bị góp ý chỉnh sửa nhiều lần thì hãy lắng nghe ý kiến đóng góp của người quản lí, họ sẽ giúp bạn cải thiện rất nhiều kĩ năng trong việc tạo testcase. Đừng buồn hay áp lực bản thân nếu bạn làm chưa tốt. Vì kinh nghiệm của bạn chưa đủ để có thể nhìn ra được tất cả lỗi của hệ thống đó. Hãy xem đó là một cơ hội tuyệt vời để bạn đặt câu hỏi và làm rõ mọi thứ và yêu công việc kiểm thử mà mình đã chọn.

3) Test execution/regression

Test execution/regression: Chúng tôi gọi đây là hoạt động kiểm tra hồi quy.

Về cơ bản, kiểm tra hồi quy là:

Nếu bạn có 10 trường hợp kiểm thử cho một chức năng, bạn cần chạy tất cả 10 trường hợp đó.

Nếu bạn có 100 trường hợp kiểm thử cho hệ thống của mình, bạn cần chạy tất cả 100 trường hợp đó.

Kiểm tra hồi quy có lợi ích rất lớn nhưng bạn lại gặp một vấn đề khác đó là thường xuyên phải cập nhật lại các trường hợp kiểm thử mà bạn đang có. Tuy nhiên nếu bộ testcase hiện tại của bạn có đến vài trăm hoặc vài nghìn case thì điều đó không vui chút nào.

Đừng lo lắng, hệ thống của bạn không phải lúc nào cũng thay đổi. Sẽ đến thời điểm, bộ testcase ấy sẽ phát huy chức năng của chúng và bạn thậm chí còn tìm thấy một số lỗi quan trọng khi chạy các trường hợp thử nghiệm của mình. Kiểm tra hồi quy thực sự quan trọng, dù muốn hay không, sớm hay muộn, để hệ thống của bạn có chất lượng tốt nhất bạn sẽ phải làm điều đó.

4) Exploratory testing

Hầu hết các hoạt động kiểm tra đều khá nhàm chán nhưng với tư cách là người kiểm thử tôi chắc chắn bạn sẽ thích hoạt động này: Exploratory testing (kiểm thử khám phá).

Đây là cơ hội để bạn sử dụng tất cả kinh nghiệm, kiến thức về hệ thống, kỹ năng tìm lỗi của bạn để tìm ra lỗi trong hệ thống.

Bạn sẽ tìm thấy các lỗi mà trước đây khi dùng bộ testcase mà bạn viết để chạy thì lỗi ấy cũng chưa được phát hiện ra. Bạn sẽ giải phóng khả năng sáng tạo và trí tưởng tượng của mình để nghĩ ra các tình huống trong đó người dùng cuối sẽ sử dụng trên hệ thống và mọi thứ có thể sai như thế nào.

Vì Exploratory testing là một hoạt động quan trọng và nó rất thú vị để thực hiện, tôi luôn khuyên chúng ta nên sắp xếp một khoảng thời gian phù hơp để thực hiện loại kiểm thử này trong dự án của mình.

5) Bug reporting

Nếu bạn là một người kiểm thử, sớm hay muộn bạn cũng sẽ tìm thấy lỗi trong hệ thống của mình và bạn cần báo cáo nó. Về cơ bản, nó chỉ là một hoạt động để bạn nói với mọi người về vấn đề bạn đã tìm thấy, khiến họ chú ý và sửa chúng.

Việc này có khó không? Nếu công ty hoặc dự án của bạn cũng có một bộ hướng dẫn hoặc định dạng để bạn làm theo. Bám sát nó và bạn sẽ ổn thôi.

Có chán không? Không hẳn vậy. Tôi không biết bạn thế nào nhưng viết báo cáo lỗi khá thú vị đối với tôi. Nó không chỉ là một cách để thể hiện ra kết quả kiểm thử của tôi mà còn giúp tôi rèn luyện kỹ năng viết báo cáo. Nếu tôi có thể viết một báo cáo lỗi tốt, mọi người có thể hiểu vấn đề nhanh chóng và đánh giá được mức độ nghiêm trọng của vấn đề.

Việc báo cáo bug rất quan trọng. Xin lưu ý rằng khi bạn kiểm thử, bạn không chỉ là người kiểm tra sản phẩm, mà còn cung cấp dịch vụ và công việc của bạn là cung cấp càng nhiều thông tin về hệ thống đang được kiểm tra càng tốt và báo cáo lỗi là một trong số đó. Nếu bạn làm đúng và hiệu quả, mọi người sẽ thấy giá trị mà công việc của bạn đang làm.

Một số điểm cần lưu ý:

Tránh báo cáo lỗi trùng lặp

Tránh báo cáo lỗi không hợp lệ

Tránh báo cáo lỗi không thể sửa chữa

Tránh đổ lỗi cho ai đó về nguyên nhân của lỗi

Tránh bỏ lỡ thông tin quan trọng trong các lỗi như tiêu đề, mô tả, từng bước để tái tạo, chứng cứ, v.v.

Các thông tin mô tả trong lỗi cần rõ ràng, ngắn gọn nhưng phải đầy đủ.

6) Meetings

Meeting đây là việc cần làm, cho dù trong cuộc họp đấy có tranh luận, có chê trách hay phàn nàn. Nhưng dù muốn hay không, meeting là việc không thể tránh khỏi trong các dự án.

Có nhiều loại cuộc họp khác nhau diễn ra trong suốt vòng đời dự án. Dưới đây là một số phổ biến:

Daily meeting (Cuộc họp hàng ngày):

Nếu nhóm của bạn đang làm việc theo mô hình Scrum, cuộc họp hàng ngày được coi là bắt buộc. Nó diễn ra tầm 15-20 phút. Trong cuộc họp này, mỗi thành viên trong nhóm sẽ lần lượt cập nhật tiến độ làm việc bằng cách trả lời ba câu hỏi sau:

Bạn làm gì hôm qua?

Bạn làm những gì hôm nay?

Có khó khăn gì không?

Nếu nhóm của bạn không làm việc theo mô hình Scrum thì cuộc họp hàng ngày cũng rất quan trọng. Trong trường hợp bạn có một nhóm lớn và các thành viên trong nhóm không có giao tiếp thường xuyên thì bạn vẫn có thể nắm bắt được tình hình công việc và tiến độ của dự án.

Bug meeting/bug triage meeting (Cuộc họp lỗi / cuộc họp xử lý lỗi)

Trong cuộc họp này, các thành viên trong nhóm, trưởng nhóm hoặc người quản lý sẽ xem xét các lỗi được báo cáo bởi nhóm kiểm thử (có nghĩa là: bạn) và thảo luận về chúng để:

Làm rõ một số điểm không rõ ràng của lỗi hoặc yêu cầu thêm thông tin từ người kiểm thử.

Đánh giá và đưa ra mức độ ưu tiên. Quyết định cái nào sẽ sửa trước, cái nào sẽ sửa sau.

Thông thường, mọi người không thích hội họp nói chung. Tuy nhiên, nếu dự án lớn, phức tạp hoặc nhóm của bạn không cùng vị trí, một cuộc họp thường xuyên có thể tăng cường giao tiếp nhóm. Vì vậy, hãy tận dụng cơ hội này để đặt câu hỏi tốt để biết thêm về dự án, hệ thống đang thử nghiệm, kế hoạch của dự án. Bạn càng biết nhiều bạn càng có thể kiểm tra hệ thống dễ dàng.

7) Reporting your testing progress

Nếu nhóm của bạn không họp hằng ngày thì bạn có thể báo cáo kết quả kiểm thử của mình theo từng giai đoạn. Bạn có thể báo cáo hằng ngày hoặc hàng tuần tùy thuộc vào nhóm của bạn và vai trò của bạn. Báo cáo có thể trao đổi trực tiếp hoặc thông qua email.

Thường xuyên chia sẻ tiến trình kiểm tra, kết quả kiểm tra của bạn hoặc các vấn đề phát sinh mà bạn quan sát được sẽ giúp người quản lý có thông tin và dữ liệu chính xác để đưa ra quyết định phù hợp.

Thông qua bài viết này tôi đã chia sẻ với bạn một số hoạt động kiểm tra phổ biến mà bạn nên biết trước với tư cách là người kiểm thử.

Ngoài ra, đây là những hoạt động mà tôi đã từng trải nghiệm không phải tất cả các hoạt động ngoài kia. Ngoài ra, tôi biết rằng đây chỉ là những chia sẻ ở bước khởi đầu, cảm giác của tôi và các dự án mà tôi tham gia. Trên thực tế, bạn sẽ hoặc không thể có chính xác các hoạt động tôi chia sẻ ở đây. Chỉ cần lấy nó làm tài liệu tham khảo. Đôi khi, bạn cần thử nghiệm và nhìn mọi thứ qua ống kính của mình. Chúc bạn luôn theo đuổi đam mê và yêu thích công việc kiểm thử mà bạn đã chọn.

Link Tham Khảo: https://www.asktester.com/7-common-software-testing-activities/