Bạn nghĩ rằng kiểm thử phần mềm chỉ bắt đầu khi các lập trình viên đã hoàn tất việc xây dựng một phần mềm, ứng dụng? Thực tế, quy trình kiểm thử gồm nhiều giai đoạn khác nhau, được các Tester thực hiện từ khi nhận được yêu cầu của khách hàng đến lúc phần mềm được triển khai. Trong bài viết này, Got It xin chia sẻ đến các bạn những giai đoạn chi tiết trong quá trình kiểm thử phần mềm.
Bạn đang xem: Các bước kiểm thử phần mềm
Requirement analysis – Phân tích yêu cầu
Giai đoạn đầu tiên của quy trình kiểm thử là phân tích các yêu cầu thông qua những tài liệu bao gồm: tài liệu yêu cầu của khách hàng, prototype của khách hàng, tài liệu đặc tả yêu cầu của phần mềm, tài liệu thiết kế hệ thống…
QA team có nhiệm vụ phân tích và xác định những yêu cầu của khách hàng, trong đó có yêu cầu về kiểm thử chức năng/phi chức năng của phần mềm. Trong quá trình phân tích, QA team có thể đặt ra câu hỏi để hiểu chính xác hơn về yêu cầu của sản phẩm, đồng thời hỗ trợ đưa ra giải pháp thích hợp cho khách hàng.
Quy trình kiểm thử bắt đầu với giai đoạn phân tíchTest planning – Lập kế hoạch kiểm thử
Test plan là gì?Dựa vào tài liệu nhận được trong giai đoạn đầu, Test Lead hoặc Test Manager sẽ lên kế hoạch kiểm thử phần mềm cho QA team để xác định một số yếu tố:
Phạm vi dự án: Thời gian thực hiện dự án bao lâu? Trong từng khoảng thời gian sẽ có những công việc gì?Phương pháp tiếp cận: Dựa vào yêu cầu chất lượng của khách hàng, thời gian test, kỹ thuật phát triển ứng dụng, lĩnh vực của sản phẩm… Test Manager sẽ đưa ra phương pháp tiếp cận sao cho đảm bảo tiến độ và chất lượng sản phẩm. Sau khi kết thúc giai đoạn này, QA team cần nhận được test plan, test schedule, test estimation.Lên kế hoạch kiểm thử
Test case development – Thiết kế kịch bản cho quy trình kiểm thử
Trong giai đoạn này, các Tester sẽ đọc hiểu tất cả các tài liệu, từ đó xác định những việc cần làm, chức năng nào cần test hoặc không. Sau đó, dựa vào kế hoạch và kỹ thuật thiết kế kịch bản kiểm thử, Tester sẽ bắt đầu viết test case. Yêu cầu của test case: Thể hiện tất cả các trường hợp kiểm thử có thể phát sinh để đáp ứng yêu cầu sản phẩm. Ngoài test case, Tester cũng cần chuẩn bị các dữ liệu cần thiết khác như test data, test script, test design, test automation script.
Thiết kế kịch bản cho quy trình kiểm thửTest environment set up – Thiết lập môi trường kiểm thử
Đây là một trong những giai đoạn đóng vai trò rất quan trọng trong Software Testing Life Cycle (vòng đời phát triển phần mềm). Dựa trên yêu cầu khách hàng và đặc thù của sản phẩm, môi trường kiểm thử sẽ được xác định. Tester cần chuẩn bị smoke test case để kiểm tra môi trường cài đặt đã đáp ứng yêu cầu và sẵn sàng cho giai đoạn kiểm thử tiếp theo hay chưa.
Test execution – Thực hiện kiểm thử
Theo test case đã thiết kế và môi trường kiểm thử đã hoàn tất cài đặt, Tester sẽ báo cáo bug lên tool quản lý lỗi và theo dõi đến khi fix bug thành công. Tiếp đó, Tester thực hiện retest để verify các fix bug và regression test trong trường hợp có sự thay đổi. Sau khi hoàn tất giai đoạn này, các chuyên viên kiểm thử cần có được test results (kết quả kiểm thử) và defect reports (danh sách các lỗi tìm được).
Test cycle closure – Đóng chu trình kiểm thử
Để đóng chu trình kiểm thử, QA team cần có được những tài liệu đã được tổng hợp và hoàn thiện từ những giai đoạn trước: tài liệu phân tích đặc tả yêu cầu, test plan, defect reports, test results… Tiếp đó, QA team sẽ tổng kết, báo cáo về quá trình kiểm thử, có bao nhiêu bug đã được fix, bug có nghiêm trọng hay không, chức năng nào còn lỗi, chức năng nào đã hoàn thành…
Mong rằng bài viết trên đã giúp bạn hiểu được toàn bộ các giai đoạn trong quy trình kiểm thử phần mềm. Hãy tham khảo cách tạo test plan hoàn chỉnh cho một tính năng hoặc một sản phẩm mới và góp ý qua bình luận cho Got It nhé!
Nếu bạn quan tâm, hãy xem các vị trí đang tuyển dụng của Got It tại: bit.ly/gotit-hanoi và đọc thêm về quy trình tuyển dụng tại đây.
Quy trình và các phương pháp quản lý dự án đóng vai trò rất quan trọng trong một dự án thành công. Trong nhiều trường hợp, bạn có thể tìm được một người hoàn hảo cho vị trí trong team, nhưng điều đó cũng sẽ không còn quan trọng nữa nếu người đó không có một quy trình xử lý tối ưu để quản lý công việc. Trong bài viết này, hãy cùng tìm hiểu 4 bước kiểm thử cơ bản trong một quy trình kiểm thử phần mềm nhé!
1. KIỂM THỬ PHẦN MỀM LÀ GÌ?
Có rất nhiều cách hiểu về Kiểm thử phần mềm. Hiểu một cách đơn giản thì Kiểm thử phần mềm (Test) là quá trình thực hiện một chương trình hay ứng dụng nào đó với mục đích tìm kiếm lỗi. Nói một cách hoa mỹ hơn. thì Kiểm thử phần mềm là quá trình xét duyệt một sản phẩm phần mềm có đạt đủ các yêu cầu về thương mại và kỹ thuật. Kiểm thử là con đường chính để kiểm định sản phẩm bạn làm ra đã đạt đủ những yêu cầu cần thiết.
Dù sử dụng bất kỳ phương pháp quản lý dự án nào, bạn cũng cần phải lên kế hoạch để thực hiện test cẩn thận cho sản phẩm. Test giúp bạn đảm bảo sản phẩm cuối cùng được vận hành đúng như mong muốn, đồng thời giảm thiểu các lỗi xảy ra sau này gây ảnh hưởng tới tài chính, danh tiếng và đôi khi là vi phạm quy định.
2. NHỮNG AI SẼ THAM GIA KIỂM THỬ PHẦN MỀM?
Khác với những quan niệm thông thường của nhiều người rằng Kiểm thử phần mềm là công việc của vị trí QA/Tester, đây là một công việc đòi hỏi sự tham gia của tất cả thành viên trong dự án. Chỉ một giai đoạn Testing dù chất lượng cũng không thể tìm kiếm hết được các lỗi bug trong sản phẩm.
Kiểm thử phần mềm cần phải trở thành một thói quen, một phần của mọi cuộc trao đổi và task mà nhóm dự án đó thực hiện.
Nếu nhìn theo cách này, mọi người trong dự án đều là những nhân tố then chốt.
Dev thực hiện dev testing,PO (product owner) chịu trách nhiệm review copy và thực hiện test trực tiếp,BA thường xuyên phải review yêu cầu của khách hàng,PM và Scrum master sẽ chịu trách nhiệm theo dõi kế hoạch phát triển và có những điều chỉnh về mức độ ưu tiên các task nhằm tối ưu hóa công việc.Tất cả mọi người đều có trách nhiệm thực hiện những hoạt động test bằng cách này hay cách khác.
3. BỐN BƯỚC KIỂM THỬ PHẦN MỀM CƠ BẢN
Agile hay Waterfall, Scrum hay RUP, truyền thống hay thử thách, dù dự án phát triển theo cách nào cũng đều có một quy trình nền tảng cho hoạt động kiểm thử phần mềm. Hãy cùng đến với 4 bước kiểm thử phần mềm cơ bản sau đây.
#1 Chiến lược Test và kế hoạch Test (Test Strategy và Test Plan)
Mọi dự án đều cần có chiến lược test và kế hoạch test. Những yếu tố này sẽ mô tả quy mô của phần kiểm thử trong dự án đó:
Phần hệ thống cần được test, và các config cụ thểCác tính năng mà dự án tập trung phát triển
Các yêu cầu phi chức năng
Cách tiến hành test: kiểu truyền thống, kiểu thăm dò, kiểu automation hoặc kết hợp
Các quy trình then chốt cần tuân thủ: quy trình xử lý defect, phân loại defect,…Tool sử dụng để log defect, tạo test case, hay để truy vết
Các loại tài liệu tham khảo, hoặc tài liệu cần có trong output
Các yêu cầu và các cài đặt môi trường test
Risks, dependencies và các nguy cơ rủi ro
Lịch trình test
Workflow cho việc tiếp nhận (approval workflow)Entry/Exit Criteria
Và rất nhiều các yếu tố khác. Dù dự án của bạn đi theo quy trình quản lý nào đi chăng nữa thì Chiến lược test và Kế hoạch test là 2 loại tài liệu không thể thiếu. Chúng có thể được viết độc lập, nhưng cũng có thể gộp lại thành 1 bản tài liệu tổng quát.
Xem thêm: Các Chữ Trong Word Bị Cách Quá Xa Nhau, Cách Sửa Lỗi Chữ Bị Cách Xa Trong Word
Nếu không có hai loại tài liệu này, một dự án khó có thể trở nên hiệu quả được, ngay cả với những phương pháp quản lý linh hoạt như Agile. Lý do là việc tạo lập chiến lược và kế hoạch sẽ giúp bạn nhìn ra những mối tương quan, liên hệ giữa các bên mà bình thường bạn khó mà nhìn thấy được.
Ví dụ: trong một dự án phát triển mobile app, việc xây dựng chiến lược test sẽ giúp bạn xác định rõ hệ điều hành (hdh), phiên bản hdh, loại thiết bị mà bạn cần sử dụng để test app đó.
Có không ít dự án đã phải thay đổi đáng kể các kế hoạch ban đầu do không đầu tư nhiều thời gian vào việc xây dựng chiến lược ban đầu. Kế hoạch test có thể giúp định nghĩa entry và exit criteria nhằm phục vụ test. Điều này rất quan trọng bởi nó có thể điều hướng hoạt động cho toàn bộ team dự án. Nếu sản phẩm đưa ra chưa đạt được đến mức chất lượng yêu cầu thì nó không thể chuyển sang giai đoạn test. Tương tự, nếu đoạn code đã được test không vượt qua yêu cầu chất lượng thì nó sẽ không thể đi tiếp đến các giai đoạn khác của quá trình phát triển phần mềm.
#2 Thiết kế Test (Test Design)
Công việc tiếp theo cần làm đó là thiết kế một bộ test hoàn chỉnh. Bộ test là tập hợp các test case cần thiết để có thể đối chiếu hệ thống thực tế với những yêu cầu ban đầu của nó.
Bản thiết kế test là sự tập hơn những kinh nghiệm trong nhiều năm của Test manager, sự hiểu biết của tester về hệ thống và các tính năng tương ứng cũng như kinh nghiệm test thực tế. Ví dụ, nếu công ty của bạn đang phát triển sản phẩm mới ở giai đoạn đầu, việc cần được ưu tiên là kiểm tra những lỗi lớn trong các phiên bản alpha/beta, thay vì cố gắng khiến sản phẩm hoàn hảo không có bug.
Trong trường hợp này, bạn có thể sẽ hạn chế các loại kiểm thử tiêu cực (negative testing) mà tập trung nhiều hơn vào kiểm thử thăm dò (exploratory testing) và kiểm thử phá hủy (disruptive testing) để loại bỏ những bug phức tạp và nghiêm trọng. Đồng thời, bạn sẽ không muốn thực hiện những phần kiểm thức chi tiết trước khi sản phẩm của mình có hình hài cụ thể. Vì thế, bộ test ở giai đoạn đầu của vòng phát triển cần tập trung nhiều hơn và kiểm thử những phần nền tảng cơ bản.
Khi sản phẩm đã đủ yêu cầu để đến tay khách hàng. Chúng ta nên thực hiện những phần kiểm thử chuyên môn cao hơn để đảm bảo sản phẩm có ít lỗi nhất có thể, từ đó nâng cao trải nghiệm của khách hàng. Mặc khác, nếu bạn đang test một sản phẩm hay hệ thống đã tồn tại sẵn thì có thể bạn đã có trong tay một bộ test tương đối hoàn chỉnh rồi. Việc cần làm lúc này là đối chiếu bộ test với dự án hiện tại để chỉnh sửa cho phù hợp.
Khi đã có nhiều kinh nghiệm trong việc quản lý các test case, bạn có thể xây dựng một “ngân hàng test” với chất lượng cao, từ đó giảm đáng kể thời gian mà team cần đầu tư vào phần lên kế hoạch và thiết kế.
#3 Triển khai Test (Test Execution)
Bạn có thể thực hiện test theo nhiều cách, ví dụ như là 1 phase SIT (System Integration Test) hay UAT (User Acceptance Test) trong dự án waterfall, hay là 1 phần trong 1 sprint của Agile. Dù bằng cách nào đi chăng nữa, mục đích của cuối cùng vẫn là thực hiện một khối lượng test đủ để đảm bảo hệ thống gần như không còn bug.
Điều đầu tiên chúng ta cần chú ý đó là hiểu rõ môi trường test để có thể quyết định chiến lược test của mình. Lấy ví dụ về dự án phát triển mobile app ở trên, nếu ứng dụng của bạn cần phải liên kết với hệ thống backend lõi để hiển thị thông tin và notification cho khách hàng, thì môi trường test của bạn cần có liên kết với backend để thực hiện được những test case có giá trị. Ngoài ra, cách chúng ta thực hiện test còn phụ thuộc vào nhiều yếu tố như hệ thống cơ sở hạ tầng có sẵn, cấu trúc của team và dự án trong công ty/tổ chức của bạn.
#4 Đóng Test (Test Closure)
Sau khi đã có toàn bộ kế hoạch và tài liệu, thực thi test xong thì đã đến lúc đưa quyết định về sản phẩm đã được test. Bạn cần quan tâm đến những exit criteria để xác định 1 vòng test đã hoàn thành và sẵn sàng cho release. Dưới đây là một số những criteria phổ biến:
Test bao phủ 100% yêu cầu: tất cả các yêu cầu về kinh doanh và kỹ thuật đều phải được kiểm thửTỷ lệ pass tối thiểu: Thường sẽ đặt ở mức đáp ứng 90% test case
Tất cả các defect phải được xử lý
Việc định nghĩa các mức đạt yêu cầu đều phụ thuộc vào hoàn cảnh của từng dự án, từng doanh nghiệp và từng ngành nghề khác nhau.
Hãy luôn nhớ rằng, không một ai có thể chấp nhận sản phẩm vẫn còn những defect nghiêm trọng chưa được giải quyết khi đã bàn giao cho khách hàng, đặc biệt là khi sản phẩm đó có chứa thông tin cần bảo mật.
Cuối cùng, chúng ta nên gói gọn lại công việc test trong một bản Báo cáo test và defect. Tài liệu này sẽ cung cấp những số liệu về quá trình test như: có bao nhiêu defect thuộc dạng thấp/trung/cao? Có những tính năng nào bị ảnh hưởng? Phần nào có nhiều defect nhất?…
4. LƯU Ý VỀ KIỂM THỬ PHI CHỨC NĂNG
Không khó để tìm kiếm những tài liệu nói về các yêu cầu phi chức năng (Non-functional Requirements Testing), và tầm quan trọng của kiểm thử phi chức năng để dự án đạt hiệu quả và thành công. Việc thực hiện song song kiểm thử chức năng và phi chức năng sẽ giúp team nhìn ra những yêu cầu bổ sung cần có trong test case (ví dụ như: ứng dụng cần hỗ trợ đa ngôn ngữ), hay giúp hoàn thiện kế hoạch test ngay từ đầu để không xảy ra những phát sinh ở giai đoạn sau. Đừng nghĩ kiểm thử phi chức năng như một task phụ phải làm, hãy nghĩ nó như một việc cơ bản mà dự án phải cung cấp cho khách hàng.
Để kết lại, hãy luôn nhớ rằng phương pháp quản lý dự án của bạn không ảnh hưởng tới bất kỳ bước kiểm thử phần mềm nào nêu trên. Ngược lại, tuân thủ theo một quy trình test hiệu quả còn giúp tối ưu hóa hoạt động của cả dự án. Kiểm thử phần mềm chính là một phần nền tảng và cốt lõi của bất kỳ dự án phát triển phần mềm nào.
Đầu tư đúng mức cho kế hoạch test, và bạn sẽ tự tin bàn giao những sản phẩm không bug tới tay khách hàng!
