7 bước thực hiện kiểm thử bằng tay trước khi release sản phẩm

Để hiểu được quy trình kiểm thử bằng tay hoặc quy trình kiểm thử phân mềm(STLC), trước hết chúng ta cần phải hiểu quy trình phát triển phân mềm (SDLC), mà chắn rằng các bạn đã có một sự hiểu biết nhất định về nó.

Mọi người thường nhắc đến chúng một cách riêng biệt nhưng không chắc chúng có thể cùng tồn tại hay không. Chúng được tích hợp chặt chẽ với nhau. Vâng, ngay cả những quy trình này cũng có rất nhiều phiên bản được tạo ra và trôi nổi trên mạng Internet, chúng khác nhau nhiều về mô hình phát triển được chọn.

Vì hầu hết hiện nay trên thế giới đang sử dụng mô hình Agile, vì vậy bài viết này cũng đơn giản hóa xung quanh Agile.

Chuyên viên Phân tích nghiệp vụ (Người / Nhóm chịu trách nhiệm thu thập yêu cầu) sẽ ghi lại các yêu cầu. Họ ghi rõ yêu cầu, đó là điểm nổi bật, bạn chỉ có thể tập trung vào điều đó. Nơi nó được tài liệu các vấn đề ít hơn.

Mọi người sử dụng bất cứ điều gì để ghi lại các tài liệu phù hợp với họ nhưng không giới hạn ở các nền tảng truyền thống như MS word doc, các nền tảng hiện đại như Jira / Rally và các công cụ mới như Trello.

Sau đó, Nhà phân tích nghiệp vụ phải chia sẻ các yêu cầu đã được ghi chép với Nhóm phát triển, Nhóm kiểm thử và Nhóm UX (nếu cần). Điều này thường diễn ra thông qua một cuộc họp chính thức, nơi SPOCs (Single Point Of Contacts hoặc toàn bộ nhóm, nó phụ thuộc) từ cả ba chức năng đáp ứng và hiểu được toàn bộ yêu cầu. Trong một nền văn hoá làm việc lành mạnh, yêu cầu được thảo luận từ mọi góc độ và mỗi thành viên của cuộc họp có thể đặt câu hỏi và nghi ngờ. Khi tất cả các câu hỏi đã được trả lời và cần sửa đổi yêu cầu thì giai đoạn này có thể được coi là xong. Mặt khác người ta gọi đây là một cuộc họp/ bước đặc biệt và tài liệu hướng dẫn của nó khác nhau tùy từng công ty. Ví dụ, tài liệu được gọi hoặc phân loại thành SRS (Đặc tả yêu cầu hệ thống), Tài liệu Yêu cầu, Epic, User story , Story point (có thể là đơn vị yêu cầu nhỏ nhất) ... Trên các bậc tương tự, yêu cầu cuộc họp này là được chia sẻ được gọi như là cuộc họp thảo luận yêu cầu của khách hàng, Grooming, Hole-punching,.. vv.

Nhấn mạnh vào những thuật ngữ này để bạn luôn luôn nhớ ý tưởng chính không phân biệt các tên gọi khác nhau.

Vị trí hai bước cuộc họp này được kích hoạt cùng một lúc, không theo thứ tự cụ thể, hãy tham khảo hai bước tiếp theo.

Nhóm phát triển bắt đầu với thiết kế kỹ thuật của họ ngay khi yêu cầu được thảo luận xong và khi không có điểm nào bị pending. Những gì được thực hiện trong giai đoạn này lại khác nhau tùy từng công ty.

Giai đoạn này có thể bao gồm nhưng không giới hạn ở các nhiệm vụ sau:

• Quyết định cách tiếp cận phát triển
• Chuẩn bị tài liệu thiết kế
• Thiết kế biểu đồ luồng của dự án
• Ước tính effort
• Tìm ra tác động của yêu cầu mới này đối với bất kỳ chức năng hiện có nào
• Vá dữ liệu hiện có, v.v ... Nhóm UX cũng có thể tham gia vào giai đoạn này khi có sự thay đổi giao diện người dùng hoặc màn hình mới sẽ được phát triển. Nhóm UX giúp đội phát triển và đội kiểm thử với mẫu giao diện người dùng (UI) thử cho chức năng / feature trong buổi thảo luận. Đây có thể là một tài liệu Photoshop, hình ảnh đơn giản, bài thuyết trình PowerPoint hoặc bất cứ điều gì khác mà sẽ làm cho nhóm phát triển hiểu rõ màn hình nên được phát triển như thế nào. Lưu ý: Những màn hình này hoặc ít nhất là phiên bản nháp của họ sẽ được hiển thị trong phần thảo luận yêu cầu để giúp nhóm xây dựng có những hiểu biết tốt hơn. Nó được gắn thẻ theo yêu cầu ban đầu để có thể được tham khảo bất kỳ thời điểm nào.

Song song với giai đoạn Thiết kế, nhóm kiểm thử bắt đầu bằng việc xây dựng các kịch bản kiểm thử (Test scenarios) và / hoặc các trường hợp kiểm thử (Test case) dựa trên các yêu cầu đã được thảo luận. Kịch bản kiểm thử luôn được viết trước và sau đó chia nhỏ thành các trường hợp kiểm thử (Test cases).

Cho dù bạn ghi lại các kịch bản kiểm thử hay không, kịch bản kiểm thử luôn có trước Test case. Kịch bản kiểm thử là điểm đạn của bạn, bạn có thể nói, chúng hướng dẫn bạn đào sâu hơn. Một khi đã hoàn tất các test case, bạn có thể chia sẻ với nhóm phát triển để cho họ biết phạm vi kiểm tra và họ cũng có thể đảm bảo sự phát triển đã diễn ra hoặc đang xảy ra là thỏa mãn các trường hợp kiểm thử.

Các trường hợp kiểm thử một khi đã hoàn thành sẽ được Test lead review hoặc sẽ được review chéo bởi một thành viên khác trong nhóm từ nhiều góc độ như: • Mức độ bao phủ yêu cầu • Chính tả ngữ pháp • Kiểm tra xem viết Test case có theo đúng chuẩn hay không (không có gì nhưng mà phải tuân thủ theo teamplate của nhóm / công ty) • Khả năng tương thích ngược • Khả năng tương thích với các nền tảng • Kiểm tra dữ liệu tham khảo • Các loại kiểm thử mục tiêu, v.v.

Lý tưởng nhất, sau khi xem xét và cần được sửa đổi, chúng được chuyển sang nhóm Phát triển.

Khi tôi nói “Test case đã được hoàn thành”, có nghĩa là một lần 'tất cả các trường hợp kiểm thử được viết dựa trên toàn bộ những hiểu biết nhất định về yêu cầu và kịch bản kiểm thử có thể được khám phá cho đến thời điểm cụ thể đó'. Gần như không thể 100% trường hợp sẽ được test trong lần đầu tiên.

Sẽ có các defects mà bạn sẽ tìm thấy trong các hành động ngẫu nhiên (nhưng có mục đích), trong các hành động hoàn toàn ngẫu nhiên (monkey test) và trong một số tình huống hiếm hoi. Có rất nhiều cơ hội bạn sẽ bỏ lỡ một vài trong số đó. Và tại một thời điểm nào đó bạn có thể bỏ lỡ những điều cơ bản thậm chí còn rất cơ bản, dù sao, bạn là con người mà. Nhưng ở đây, ít nhất là một bài kiểm tra trường hợp tốt và kiểm tra cấu trúc cách viết bài viết có thể giúp bạn tiết kiệm.

Thường xuyên hơn không, một nhân viên kiểm thử hoặc nhóm kiểm thử tiếp tục tạo thêm càng nhiều Testcase với các khoanh vùng hiện có khi họ khám phá sự thật hoặc suy nghĩ nhiều hơn về các yêu cầu.

Vâng, bây giờ một số bạn có thể nghi ngờ kiến thức của tôi về Kiểm thử phần mềm vì một số từ (đã trở thành một chuẩn mực trong Kiểm thử Phần mềm) chưa được tôi sử dụng. Kế hoạch kiểm tra (Test paln) phải không?

Hãy để tôi nói điều gì đó về điều này. Tôi tin tưởng mạnh mẽ vào nhu cầu của hầu hết các thông tin được đề cập trong Kế hoạch Kiểm tra, nhưng ghi lại tất cả ở cùng một nơi và bắt buộc phải có điều bắt buộc là điều tôi thấy có thể gây tranh cãi.

Dù sao, đó là một chủ đề riêng biệt để thảo luận. Để chia sẻ thông tin 'phù hợp với tất cả' về điều này rất khó khăn nhưng hãy để tôi thử. Hoặc là bạn, hoặc là bạn với Test lead của bạn hoặc Test lead của bạn chuẩn bị Test plan hoặc bạn ghi lại các thông tin yêu cầu ở những nơi khác nhau.

Thông tin nên được hoàn toàn đóng băng ở giai đoạn này:

• Phạm vi kiểm tra: Yêu cầu, tương thích ngược, nền tảng, thiết bị, v.v. • Người / Nhóm sẽ tiến hành kiểm thử • Tính toán effort test • Hạn chế: Mọi giả định hoặc giới hạn được chấp nhận trước. • Ngoài ra mọi người ghi lại các tiêu chuẩn đầu vào, tiêu chuẩn đầu ra, rủi ro, vv o Điều kiện bắt đầu test (Khi bắt đầu tiến hành kiểm thử): khi có một phần chức năng có khả năng để test. Rất ít dự án chờ đợi cho đến khi toàn bộ chức năng có khả năng được kiểm thử. Một khi luồng cơ bản được nhận định là đang hoạt động, quá trình kiểm thử sẽ được bắt đầu. o Điều kiện dừng test (khi nào dừng): Khi không có các bug như block, critical và major (bị ảnh hưởng) trong kiểm tra giai đoạn đầu có thể được dừng test. Hoặc ở giữa phase, khi có quá nhiều defects đang phải cần phải được test có thể được dừng lại bởi các bên liên quan thích hợp. o Rủi ro: Những rủi ro về mặt nghiệp vụ hoặc chức năng nếu quá trình kiểm thử không xảy ra theo kế hoạch đã được lập.

Sau giai đoạn thiết kế, nhóm phát triển bắt đầu với sự phát triển thực tế và kiểm thử đơn vị (UT) được tiến hành khi chúng được hoàn thành với yêu cầu kiểm thử của sự phát triển. Chúng có thể vượt qua các chức năng để thử nghiệm trong khối như và khi nó được thực hiện hoặc họ có thể vượt qua toàn bộ chức năng cùng một lúc.

Trong một kịch bản lý tưởng, review code chính thức và kiểm thử hộp trắng sẽ xảy ra trước khi chuyển qua các chức năng đã được phát triển cho Test. Lý tưởng là nhóm phát triển cũng nên tham khảo các Test case do Test team cung cấp ngoài yêu cầu và tài liệu thiết kế.

Như đã đề cập ở trên, việc bắt đầu giai đoạn này sẽ khác nhau giữa công ty với công ty, nhóm với nhóm.

Test team bắt đầu tiến hành test ngay khi một phần chức năng của yêu cầu đã phát triển xong và có khả năng test được hoặc khi toàn bộ yêu cầu đã được phát triển xong.

Hãy đi sâu hơn nữa trong giai đoạn này và nói về những nhiệm vụ quan trọng:

o Tester / Test team bắt đầu với vòng kiểm thử (kiểm thử thăm dò và tiến hành kiểm thử bởi các bộ test case đã được viết) và ghi lại lỗi. o Nhóm phát triển giải quyết các vấn đề đó theo mức độ ưu tiên. o Các bản build mới (code) được thực hiện trên môi trường mà quá trình kiểm thử đang diễn ra. o Với các lỗi đã được giải quyết sau đó được xác minh bởi Tester / Test team và được đánh dấu là Fixed o Chu kỳ này tiếp tục cho đến khi đạt được tiêu chí đầu ra. o Xin lưu ý rằng khi cần thiết, các lỗi này cũng được đánh dấu là không hợp lệ (invalid), trùng lặp (Duplicate) và cũng có thể được phân loại là Cải tiến (Enhancements). Một điều khác biệt giữa các công ty với công ty là có bao nhiêu round test được thực hiện. Giống như trong một số trường hợp, round test đầu tiên xảy ra trên các feature nhỏ khi chúng đã sẵn sàng, sau đó là một vòng kiểm tra đầu cuối trên môi trường khác khi tất cả các yêu cầu được phát triển. Nhưng cũng có công ty làm ba vòng kiểm tra thích hợp đầy đủ và thứ tư là sanity / smoke.

Việc đầu tiên trong quá trình kiểm thử nhiều vòng đó là kiểm thử các chức năng trên nhiều môi trường khác và thứ hai để thực hiện kiểm tra đầu tới cuối khi tất cả các điểm được phát triển. Vòng Sanity thường xảy ra để đạt được sự tự tin nhanh chóng một khi tất cả các story được phát triển và thử nghiệm một cách độc lập trong đợt release này.

Chuyên viên phân tích nghiệp vụ xem xét các chức năng được yêu cầu bằng cách đề cập đến kết quả test hoặc đề cập đến kết quả test cộng với việc kiểm tra các ứng dụng để có thể hiểu được về ứng dụng. Bước này một lần nữa chịu sự chi phối từ các hành động khác nhau giữa các công ty.

BA có thể xem xét phạm vi toàn bộ ứng dụng trong đợt release này trong một bước hoặc số lượng lớn. Tùy thuộc vào sự giống nhau, bước này có thể tiến hành trước hoặc sau khi tiến hành sanity lần cuối bởi team test.

7 bước trên diễn ra cho tất cả user story / yêu cầu phải được thực hiện trong phiên bản đặc biệt (Bàn giao). Một khi tất cả các các yêu cầu này được hoàn thành, việc phát hành được cho là sẵn sàng cho việc bàn giao sản phẩm tới khách hàng.

Nguồn dịch: http://www.softwaretestinghelp.com/practical-implementation-of-manual-testing/