Làm thế nào để chuẩn bị cho việc viết Test Case và nâng cao năng suất của bạn

Khi một tester quyết định viết các test cases chất lượng cao và muốn nâng cao hiệu quả và năng suất của việc viết test case, có vài điểm chính giúp các tester đạt được những mục tiêu này.

Trước tiên, họ cần phải chuẩn bị kỹ năng chuyên môn và tâm lý với một số điểm chính cần thiết cho mỗi tester để thành công trong ngành công nghiệp CNTT. Điều này sẽ được coi là " Đầu vào " cho tester trước khi bắt đầu viết các test cases. Tiếp theo, họ cần phải hiểu các quality metric (chất lượng số liệu) tham gia dự án, được sử dụng như một công cụ để đánh giá hiệu suất của tester trong giai đoạn khác nhau của vòng đời phát triển phần mềm. Điều này sẽ được coi là " Kết quả đầu ra " cho tester sau khi hoàn thành việc viết test case.

Cuối cùng, tester cần biết bug được báo cáo như thế nào, các vấn đề được báo cáo và các báo cáo kiểm tra được chuẩn bị sao cho phù hợp với quy trình chuẩn và có thể hiểu được bởi các bên liên quan của dự án.

Prepare Yourself

1) Viết test case là một nghệ thuật, nó không chỉ là một công việc hay nhiệm vụ. Một phần hoặc một phân đoạn của một phần mềm có thể được thiết kế và phát triển, và nếu nó không được kiểm tra hoàn tất cho tất cả các kịch bản với cách tiếp cận thử nghiệm hiệu quả, nó sẽ là vô dụng và không đủ điều kiện để phát hành và sử dụng. Vì vậy, hãy coi mình là một người quan trọng trong dự án và coi hoạt động thử nghiệm của bạn là một nhiệm vụ quan trọng trong dự án .

2) Các niềm đam mê với thái độ tích cực, đó là cá nhân phải hết sức kiểm tra chất lượng trong suốt vòng đời dự án. Động lực thúc đẩy khả năng xây dựng đội ngũ và thái độ mang lại hiệu suất tuyệt vời trong việc viết test cases chất lượng. Hay hoạt động viết test là sự kết hợp của các phẩm chất chuyên nghiệp và cá nhân cho một mục đích chung là đạt được những kết quả tốt nhất như là kết quả cuối cùng của dự án.

3) Positive and negative test cases là một phần của việc viết test case, nhưng các tester nên có một thái độ bán tích cực để phá vỡ ứng dụng đang được kiểm tra thông qua tìm lỗi . Đây không phải là một tư tưởng tiêu cực, tránh trường hợp xác định lỗi của người nào đó sau khi giải phóng hoặc tránh tình huống mà hệ thống sẽ bị hỏng bởi một số người dùng của hệ thống.

4) Hiệu suất của Tester không được ước lượng dựa trên số lượng lỗi được xác định trong hệ thống đang được thử nghiệm, nhưng về khả năng viết các test cases thành công mà kết quả phát hiện ra các khuyết tật. Vì vậy, các test cases phải được viết sao cho phạm vi cover và truy xuất nguồn tối đa dựa trên ranh giới và phạm vi hệ thống.

5) Hiểu rõ về lĩnh vực ứng dụng. Ví dụ , thử nghiệm một trang web là dễ dàng hơn so với thử nghiệm một phần mềm tài chính phát triển cho thị trường chứng khoán được sử dụng bởi hàng ngàn người cùng một lúc. Chức năng trang web đơn giản có thể hiểu được bởi bất kỳ tester nào trong khi các điều khoản và chức năng tài chính không thể hiểu được bởi tất cả tester cho đến khi và trừ khi họ có nền tảng giáo dục thích hợp hoặc đào tạo hoặc có kinh nghiệm tên miền .

Vì vậy, khi tester đang được phân bổ cho một dự án mới, người đó nên tự đánh giá, cho dù họ có đủ điều kiện và có thể thực hiện công việc của họ theo mong muốn hay không. Nếu các yêu cầu về chức năng khó hiểu, cần phải báo cáo trước cho nhóm dự án để tránh những quan niệm sai lầm trong tương lai về hiệu quả và hiệu suất của tester. Nó sẽ được xử lý bởi người quản lý dự án hoặc người quản lý kiểm tra thông qua các kế hoạch và đào tạo phù hợp.

6) Không giới hạn khả năng: Các yêu cầu của dự án và các loại thử nghiệm sẽ được thực hiện khác nhau giữa các dự án. Một người thử nghiệm cần được chuẩn bị để làm bất kỳ loại thử nghiệm. Không giới hạn khả năng của bạn về kỹ năng và chuyên môn của bạn. Hãy chuẩn bị để có trách nhiệm và thách thức để viết và thực hiện các test cases cho bất kỳ loại thử nghiệm.

Nhiều người thử nghiệm cố gắng chấp nhận bản thân hoặc dự án mình là tester bằng tay hoặc tự động. Khi đến thử nghiệm hiệu suất, kiểm tra tải hoặc kiểm tra căng thẳng rất ít tester đang đảm nhận vai trò và tự chuẩn bị bằng cách đào tạo hoặc thu thập kiến ​​thức cần thiết. Vì vậy, là một người học nhanh chóng và sẵn sàng để có trách nhiệm và phát triển trong sự nghiệp của bạn.

7) Xác định các loại thử nghiệm được thực hiện và các kỹ năng cần thiết để kiểm tra AUT. Ví dụ , một số dự án chỉ yêu cầu thử nghiệm hộp đen và một số yêu cầu kỹ năng kiểm tra hộp trắng. Kiến thức về " kịch bản " hoặc kinh nghiệm trong " SQL " hoặc làm việc với " đánh dấu ngôn ngữ " như HTML / XML vv, hoặc thậm chí một kiến ​​thức hệ thống về cách cài đặt / khắc phục sự cố cài đặt phần mềm vv.. là một số yêu cầu cụ thể của dự án bạn Phải học bản thân hoặc được đào tạo giống nhau.

8) Đảm bảo rằng các test cases bao gồm các loại thử nghiệm Hiệu suất, kiểm tra an toàn và kiểm tra hồi quy. Ví dụ: để đăng nhập vào ứng dụng bằng cách sử dụng màn hình đăng nhập dưới đây:

• Có thể phải kiểm tra hiệu suất để kiểm tra xem ứng dụng có ổn định hay không khi hàng ngàn người dùng đăng nhập vào hệ thống cùng một lúc, và các test cases cần được viết để bao quát cho kịch bản này.
• Có thể yêu cầu thử nghiệm bảo mật để kiểm tra xem ứng dụng chỉ cho phép người dùng có quyền và quyền hợp lệ được phép sử dụng hệ thống và các test cases phải được viết để bao gồm các kịch bản này.
• Thử nghiệm hồi quy có thể được yêu cầu để kiểm tra xem các chức năng cốt lõi và các tính năng quan trọng đang làm việc đúng trên mỗi bản phát hành.

9) Đánh giá bài kiểm tra : Một trong những giai đoạn quan trọng nhất và bị xem nhẹ nhất trong bất kỳ quá trình phát triển và thử nghiệm phần mềm nào là " ĐÁNH GIÁ ". Khi một kế hoạch dự án bao gồm đủ thời gian phân bổ cho quá trình xem xét trên từng giai đoạn của quá trình phát triển dự án, các sản phẩm và kết quả đầu ra có chất lượng nhất mà chúng ta có thể mong đợi.

Ví dụ, trước khi bắt đầu viết các test cases, tester nên kiểm tra xem tài liệu "yêu cầu đặc điểm kỹ thuật" đã được xem xét và tất cả các điểm đánh giá được xem xét và cập nhật trong tài liệu. Nếu tổ chức tuân theo quy trình thích hợp và đã trưởng thành, tất cả các mẫu tài liệu cần phải có thông tin thay đổi này trong trang đầu tiên của chính tài liệu.

Vì vậy, tài liệu thử nghiệm nên được xem xét ít nhất 3 lần thông qua: i) Tự đánh giá ii) Đánh giá đồng cấp iii) Xem xét bởi những người khác về tính đầy đủ, phạm vi kiểm tra, truy xuất nguồn gốc và liệu các test có thể kiểm chứng được hay không.

10) Cuối cùng, hãy hiểu làm thế nào để estimate và lên kế hoạch cho các nhiệm vụ kiểm tra. Lên kế hoạch làm việc chỉ trong khoảng thời gian ước tính dự kiến ​​trong một ngày. Điều này có thể đạt được bằng cách bắt đầu và hoàn thành nhiệm vụ đúng giờ và để lại cho ngày với kế hoạch cho các nhiệm vụ ngày hôm sau.

Tránh ở lại muộn và nghỉ cuối tuần trong văn phòng. Ngày nay, các phương pháp quản lý dự án hiệu quả đã có sẵn và các dự án đang được thực hiện trong một môi trường Agile. Nếu sự kiện quan trọng không đạt được bởi các đội dự án, nó sẽ được coi như một quản lý dự án không hiệu quả chứ không phải là không hiệu quả từ các đội dự án.

Lưu ý : Hãy ghi nhớ, ngay cả đối với kiểm tra tự động , test cases nên được viết rõ ràng và xem xét lại ít nhất một lần, bao gồm hoàn toàn flow chức năng của ứng dụng được thử nghiệm. Bất kỳ công cụ kiểm tra tự động nào chỉ có thể ghi và thực hiện các test cases thành công khi các test cases thủ công được xác định và ghi rõ ràng.

Quality Metrics(Chỉ số chất lượng)

Đây là một hoạt động quan trọng trong các giai đoạn kiểm thử phần mềm. Nhóm test cần phải nhận thức đầy đủ các số liệu thử nghiệm khác nhau được sử dụng để đạt được mục tiêu của dự án. Hiệu suất của tester không được đánh giá chỉ dựa trên giai đoạn thực hiện thử nghiệm nhưng từ tất cả các chỉ số đo được thu thập từ phân tích yêu cầu, viết bài kiểm tra, thực hiện, báo cáo lỗi và cuối cùng là giai đoạn báo cáo thử nghiệm.

Tìm dưới vài số liệu kiểm tra quan trọng sau bởi hầu hết các tổ chức cho năng suất của tester và hiệu quả của các giai đoạn thử nghiệm. Cũng như xem các metrics hữu ích khác được sử dụng trong các giai đoạn thử nghiệm:

1) Hiệu quả test trung bình

• Số Bug mỗi tháng người tester nỗ lực .
• Tính là trung bình (Tổng số lỗi trong quá trình test / nỗ lực thử nghiệm trong tháng người).
• Được tính sau mỗi lần phát hành nội bộ cũng như sau khi hoàn thành test.
• Giới hạn chấp nhận: nên nhỏ hơn 50

2) Mật độ trung bình của defect khách hàng

• Lỗi báo cáo của khách hàng sau khi giao hàng Vs tổng số nỗ lực thử nghiệm trong tháng con người.
• Được tính là trung bình (Tổng số lỗi sau khi gửi / effort test của trong man months.
• Được tính sau khi phát hành bên ngoài và hoàn thành dự án.
• Giới hạn chấp nhận: nên nhỏ hơn 1

3) Kiểm tra chức năng Failures

• Số lỗi kiểm tra chức năng fail / Tổng số ca kiểm tra chức năng thực hiện.
• Được tính hàng tháng hoặc hai tuần.

4) Bugs với mức độ nghiêm trọng Level 1

• Tổng số lỗi được xác định với mức độ nghiêm trọng 1 (blocker).
• Không thể tiếp tục thử nghiệm phần mềm do vấn đề chặn.
• Được tính trên cơ sở hàng tuần.

5) Bugs với mức Độ nghiêm trọng 2

• Tổng số lỗi được xác định với mức độ nghiêm trọng 2 (các lỗi chính).
• Không thể tiếp tục kiểm tra tính năng do lỗi chính, nhưng có thể tiếp tục với các phần khác của hệ thống.
• Được tính trên cơ sở hàng tuần.

6) Bugs với mức độ nghiêm trọng Level 3

• Tổng số lỗi được xác định với mức độ nghiêm trọng 3 (lỗi nhỏ).
• Có thể tiếp tục kiểm tra vì lỗi đã xác định là nhỏ và không ngừng kiểm tra.
• Được tính trên cơ sở hàng tuần.

7) Bugs với mức độ nghiêm trọng 4

• Tổng số lỗi được xác định với mức độ nghiêm trọng 4 (vấn đề về mỹ phẩm).
• Thử nghiệm có thể được hoàn thành mà không có bất kỳ vấn đề như các lỗi xác định được liên quan đến mỹ phẩm và được cố định cho phiên bản kế tiếp.
• Được tính trên cơ sở hàng tuần.

Bug Report

Cơ chế báo cáo lỗi phải được kiểm soát với quá trình kiểm tra đã trưởng thành để duy trì chất lượng ứng dụng. Cần phải có quá trình leo thang phù hợp với đúng người được ủy quyền để biết tình trạng, mức độ nghiêm trọng và mức độ ưu tiên của lỗi. Có rất nhiều công cụ báo cáo lỗi miễn phí và thương mại có sẵn như Bugzilla, Mantis ... rất hiệu quả trong cơ chế theo dõi vấn đề và có thể được tích hợp dễ dàng với bất kỳ công cụ quản lý kiểm tra nào được sử dụng trong dự án.

Trong tất cả các dự án thử nghiệm, các thủ tục chuẩn cần phải được tuân theo để có cơ chế báo cáo tình trạng trực tuyến trên cơ sở hàng ngày. Mọi lỗi / vấn đề đăng nhập và báo cáo trong các hệ thống theo dõi lỗi này ngay lập tức phải gửi một email tới các cơ quan tương ứng sẽ giúp họ lên kế hoạch và hành động phù hợp.

Test Report

Ngoài các báo cáo lỗi được đưa lên, đăng nhập và leo thang trong hệ thống báo cáo lỗi, báo cáo thử nghiệm là một trong những tài liệu quan trọng nhất để biết tình trạng thử nghiệm và các chỉ số quan trọng khác được xác định và tính toán trong khoảng thời gian báo cáo thử nghiệm. Dưới đây là một báo cáo thử nghiệm đơn giản:

Phần kết luận

Quá trình chuẩn bị cho việc viết các test cases không chỉ là phân bổ các nguồn lực trong dự án mà còn có một vài yêu cầu quan trọng như chuẩn bị cho chúng ta như là một thử nghiệm đủ điều kiện và hiểu được các chỉ số chất lượng được theo dõi trong suốt vòng đời thử nghiệm và ngay cả sau khi phát hành.

Vì vậy, theo quy trình, tiêu chuẩn, quy trình và tuân thủ chặt chẽ các chỉ số chất lượng với niềm đam mê, có thể tự động mang lại hiệu suất thử nghiệm tuyệt vời, năng suất và chất lượng kiểm tra trong bạn, điều này sẽ trở thành thói quen trong cuộc sống nghề nghiệp của bạn.

Các yếu tố chất lượng này có thể tự phân tích hoặc nhóm được phân tích bằng cách hỏi một vài câu hỏi sẽ cho biết liệu chúng ta đang đi đúng hướng và tiến trình trong mục tiêu đạt được cách tiếp cận hiệu quả trong việc viết và thực hiện bài kiểm tra:

• Bạn đã trải qua các yêu cầu chức năng / yêu cầu của người dùng / tài liệu về trường hợp sử dụng kinh doanh?
• Tài liệu yêu cầu chức năng đã được xem xét lại và cập nhật đúng với ý kiến ​​nhận xét chưa?
• Bạn đã nhận được các nguyên mẫu màn hình cho tất cả các tính năng cần được kiểm tra?
• Bạn có cảm thấy thoải mái bằng văn bản các test cases có thể kiểm chứng và truy xuất được trong suốt vòng đời thử nghiệm?
• Bạn có yêu cầu thiết lập kỹ năng và kiến ​​thức miền để kiểm tra ứng dụng đang được kiểm tra?
• Bạn có cần đào tạo hoặc kiến ​​thức kỹ thuật cần thiết để thực hiện các test cases?
• Bạn có lịch trình để viết, xem xét và thực hiện các test cases, bao gồm thời gian để chuẩn bị các tài liệu có chất lượng?
• Bạn có các đồng nghiệp để xem xét các test cases của bạn và một chuyên gia có thẩm quyền đối tượng để kiểm tra tính đầy đủ và phạm vi của các tính năng và chức năng để được kiểm tra?
• Bạn có đủ các test cases cho tất cả các yêu cầu chức năng?
• Bạn có đủ các test cases để thực hiện, kiểm tra tải và kiểm tra an ninh không?
• Bạn có đủ các test cases để thử nghiệm cài đặt và hồi quy?
• Bạn có chú trọng vào contact các issues hoặc báo cáo lỗi không?
• Công cụ theo dõi lỗi được định cấu hình đúng với sự cho phép được yêu cầu cho tất cả không?
• Bạn có cảm thấy thoải mái khi theo dõi tất cả các quy trình được xác định trong kế hoạch kiểm thử?
• Bạn đang tham gia vào tất cả các cuộc họp đánh giá và có cơ hội nói chuyện với đội ngũ phát triển hoặc quản lý?
• Năng suất và hiệu quả của bạn đã cải thiện hay bạn cần thực hiện bất kỳ biện pháp nào giống nhau?

Có rất nhiều câu hỏi tương tự như các xét nghiệm có thể tự hỏi mình để phân tích tự cải thiện, tùy thuộc vào loại dự án hoặc tổ chức họ đang làm việc với. Điều quan trọng nhất là tất cả các hoạt động này không nên được tuân theo chỉ để làm theo các quy trình nhưng nên được thực hiện như thói quen hàng ngày của bạn mà có thể được thực hiện mặc dù chỉ PASSION FOR TESTING.

Bài viết được tham khảo tại: http://www.softwaretestinghelp.com/how-to-prepare-yourself-for-test-case-writing/