Chuẩn bị cho việc viết Testcase và nâng cao hiệu quả test

Khi tester muốn viết được Testcase chất lượng và muốn nâng cao hiệu quả và năng suất của Test case thì có vài điểm quan trọng giúp các tester có thể đạt được những mục tiêu này.

Cần phải hiểu chỉ số chất lượng trong các dự án, các chỉ số này đượ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 testing life cycle. Điều này sẽ được coi là "đầu ra" cho một tester sau khi hoàn thành việc viết testcase.

Tester cần phải biết làm thế nào để report bug, chuẩn bị test report và các tài liệu để các bên liên quan của dựán có thể hiểu được dễ dàng.

1. Tester cần chuẩn bị

• Xác định test case cho các trường hợp bình thường và bất thường là một phần trong việc viết test case, nhưng các tester cần phải có một tư duy tích cực để phá vỡ các ứng dụng trong quá trình test để tìm kiếm lỗi. Việc này nhằm tránh trường hợp bug bị tìm thấy sau khi sản phẩm được bàn giao, hoặc bởi người dùng hệ thống.

• Hiệu quả của Tester không nên được ước tính dựa trên số lượng các lỗi được xác định ở hệ thống trong quá trình test, nhưng có thể đánh giá về khả năng thông qua việc viết các testcase sao cho nó bao quát được tối đa các trường hợp có thể phát sinh lỗi.

• Hiểu kĩ nghiệp vụ khi phát triển và kiểm thử ứng dụng. Ví dụ, khi test 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 đang được sử dụng bởi hàng ngàn người cùng một lúc. Một 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 tài chính và chức năng không thể dễ dàng hiểu được, trừ khi người tester có kiến thức, kinh nghiệm hoặc được đào tạo. Vì vậy, khi một tester được phân bổ vào một dự án mới, người tester ấy nên làm tự đánh giá xem họ có đủ điều kiện và có thể thực hiện công việc của mình theo sự mong đợi hay không. Nếu các yêu cầu chức năng là khó để hiểu được thì nó cần được chuyển đến nhóm dự án có kinh nghiệm để tránh hiểu lầm trong tương lai về hiệu quả và hiệu suất của tester. Việc này nên được thực hiện bởi Project Manager hoặc Test manager và cần được xác định trong quá trình lên kế hoạch, đào tạo.

• Project requirement và các loại test được biến đổi liên tục qua các dự án khác nhau. Một tester nên được chuẩn bị để có thể làm bất kỳ loại kiểm thử nào.

• Xác định các loại kiểm thử được thực hiện và kỹ năng cần thiết cho quá trình test. Ví dụ, một số dự án chỉ yêu cầu black box test và một số yêu cầu kĩ năng while box test. Các kiến thức về "scripting" hoặc kinh nghiệm "SQL" hoặc làm việc với một vài ngôn ngữ như HTML / XML vv, hoặc thậm chí là một hệ thống kiến thức về làm thế nào để cài đặt / gỡ rối cài đặt của phần mềm… là một số dự án yêu cầu cụ thể mà bạn phải tìm hiểu chính mình hoặc nhận đào tạo cho giống nhau.

• Đảm bảo rằng các trường hợp kiểm thử có thể bao hàm được các loại test như Performance testing, Security testing and Regression testing. Ví dụ, để đăng nhập vào các ứng dụng bằng cách sử dụng màn hình đăng nhập dưới đây:

  • Performance testing có thể được yêu cầu để kiểm tra xem các ứng dụng có ổn định hay không khi có khoảng 1000 người dùng đăng nhập vào hệ thống cùng một lúc, và các testcase nên được viết để cover được trường hợp tương tự như này.

  • Security testing có thể được yêu cầu để kiểm tra xem các ứng dụng có đúng là chỉ cho phép người dùng có quyền thích hợp và quyền được phép sử dụng hệ thống đăng nhập vào hay không, và các testcase cũng cần được viết cho các trường hợp này.

  • Regression testing có thể được yêu cầu để kiểm tra xem các chức năng chính và các tính năng quan trọng được làm việc đúng trên mỗi phiên bản bàn giao.

• Test Case Review: Một trong những phần quan trọng nhất và là giai đoạn dễ bị bỏ qua nhất của việc phát triển phần mềm và testing life cycle là "REVIEW". Khi plan của project phân bổ đủ thời gian cho việc review trên từng giai đoạn phát triển thì sẽ nhìn thấy hiệu quả và chất lượng ở đầu ra. Ví dụ, trước khi bắt đầu viết testcase, tester nên kiểm tra các tài liệu“requirements specification” được review 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 công ty đang tuân theo một tiêu chuẩn nào đó riêng thì tất cả các mẫu tài liệu phải có thay đổi thông tin này trong trang đầu tiên của tài liệu. Vì vậy, các tài liệu test cần được xem xét lại ít nhất 3 lần qua:

  • i) Tự review

  • ii) review trong nhóm

  • iii) Đánh giá của người khác về tính đầy đủ, khả năng cover, các testcase có khả năng test được hay không

• Hiểu cách làm thế nào để ước lượng và lên kế hoạch test. Bắt đầu và hoàn thành task cần đúng giờ theo thời gian trong schedule. Tránh việc overtime trong ngày hoặc cuối tuần. Nếu các phần việc chính không đạt được theo schedule thì việc này sẽ đánh giá hiệu quả của việc quản lý dự án chứ không chỉ là hiệu quả của đội dự án.

Lưu ý: Ngay cả đối với kiểm tra tự động, testcase cần phải được viết rõ ràng và xem xét lại ít nhất một lần, cover được hầu hết chức năng của ứng dụng. Bất kỳ test tool tự động nào cũng có thể record và thực hiện testcase thành công chỉ khi các testcase được viết rõ ràng.

2. Quality Metrics

Đây là một hoạt động quan trọng trong các giai đoạn kiểm thử phần mềm.Testing team phải hoàn toàn nhận thức được các chỉ số test khác nhau để đạt được mục tiêu dự án. Hiệu năng của tester không chỉđược đánh giá dựa trên việc thực hiện tes mà còn từ tất cả các số liệu kiểm thử(test metric)được thu thập từ việc phân tích yêu cầu, việc viết và thực hiện testcase, báo cáo lỗi. Tìm thấy bên dưới vài số liệu thử nghiệm quan trọng tiếp theo là hầu hết các tổ chức cho năng suất tốt hơn các xét nghiệm và hiệu quả của các giai đoạn thử nghiệm.

Các test metric quan trọng:

• Trung bình hiệu quả test (Average Testing Efficiency)

  • Số bug cuả một người trong 1 tháng
  • Cách tính= Total bugs during testing/ testing effort in man months(Tổng số bug / công lao động trong 1 tháng)
  • Tính toán sau mỗi bả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 được: nên nhỏ hơn 50

• Trung bình mật độ lỗi tìm thấy từ phía khách hàng (Average Customer Defect Density)

  • Lỗi báo cáo bởi khách hàng sau khi bàn giao với tổng testing efforts của một man month
  • Cách tính=Total bugs after delivery / testing effort in man months (Tổng số bug sau khi bàn giao / công lao động trong 1 tháng)
  • Dùng để tính sau khi bàn giao cho khách và dự hán hoàn thành
  • Giới hạn chấp nhận được: nên nhỏ hơn 1

• Test chức năng fail (Functional Test Failures)

  • Cách tính = Number of failed functional test cases / Total number of executed functional test cases (Số test case fail / Tổng số testcase thực hiện)
  • Được tính hàng tháng hoặc hai tuần 1 lần

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

  • Tổng số các lỗi được xác định với mức độ nghiêm trọng level 1 (blocker)
  • Tester không thể tiếp tục test phần mềm khi có blocker
  • Được tính hàng tuần

• Bugs với mức độ nghiêm trọng Level 2

  • Tổng số các lỗi được xác định với mức độ nghiêm trọng level 2 (major bugs)
  • Tester không thể tiếp tục test phần bị lỗi nghiêm trọng này nhưng vẫn có thể test những phần khác của hệ thống
  • Được tính hàng tuần

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

  • Tổng số các lỗi được xác định với mức độ nghiêm trọng level 3(minor bugs- lỗi nhẹ)
  • Tester có thể được tiếp tục khi các lỗi được xác định là nhỏ và không làm dừng việc test
  • Được tính hàng tuần

• Bugs với mức độ nghiêm trọng Level 4(cosmetic issues)

  • Tổng số các lỗi được xác định với mức độ nghiêm trọng level 4 (cosmetic issues- liên quan đến các vấn đề thẩm mỹ)
  • Việc test có thể hoàn thành mà không có trở ngại, bug được xác định là cosmetic issue có thể thể fix trong lần sau
  • Được tính hàng tuần

3. Bug Reporting

Cơ chế report bug phải được kiểm soát trong suốt quá trình test để duy trì chất lượng ứng dụng. Việc báo cáo này là cần thiết cho những người có liên quan biết về tình trạng, mức độ nghiêm trọng và ưu tiên của các bug. Có rất nhiều tool report miễn phí và có sẵn như Bugzilla, Mantis vv, mà là rất hiệu quả trong việc theo dõi bug và có thể được tích hợp dễ dàng với bất kỳ test management tool nào được sử dụng trong dự án.

Trong mỗi project test, các tài liệu cần phải được theo dõi hàng ngày. Mỗi bug / issue cần được log lên và report trong các hệ thống theo dõi bug email nên ngay lập tức được gửi đến người report và những người liên quan để giúp họ lập kế hoạch và có những hành động phù hợp.

4. Test Reports

Ngoài việc report bug thì việc làm test report cũng là một trong những tài liệu rất quan trọng để biết được trạng thái test và các chỉ số quan trọng được tính toán

Dưới đây là một báo cáo thử nghiệm đơn giản:

5. Kết luận

Quá trình chuẩn bị cho việc viết testcase không chỉ là chỉ là phân bổ nguồn lực trong dự án, nhưng có vài yêu cầu quan trọng như chuẩn bị đủ các kĩ năng của bản thân, hiểu chỉ số chất lượng đang được theo dõi trong suốt quá trình test và thậm chí sau khi bàn giao.

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

• Đã nghiên cứu qua hết các tài liệu functional requirements/user requirements/business use case hay chưa
• Tài liệu functional requirements đã được cập nhật theo comment chưa
• Đã nhận được đầy đủ các screen prototypes cho tất cả các tính năng để test chưa?
• Tester có đầy đủ kĩ năng và kiến thức chuyên ngành đối với ứng dụng sẽ test hay ko
• Tester có cần được đào tạo hoặc thêm kiến thức kỹ thuật cần thiết nào để thực hiện test không
• Đã lên schedule cho việc viết testcase, review và thực hiện testcase, trong đó bao gồm cả thời gian để chuẩn bị tài liệu chưaBạn có đồng nghiệp để xem xét trường hợp thử nghiệm của bạn và một chuyên gia về vấn đề ủy quyền để kiểm tra tính đầy đủ và độ bao phủ của các tính năng và chức năng để được kiểm tra?
• Testcase đã có đủ trường hợp cho tất cả các yêu cầu chức năng chưa
• Đã có đủ test cases cho performance, load testing và security testing chưa
• Đã có đủ test case cho installation và regression testing chưa?
• Tool để log bug đã được phân quyền cho tất cả những người liên quan chưa
• Test plan đã phù hợp chưa
• Tester có được tham gia vào tất cả các cuộc meeting và có cơ hội thảo luận với dev và manager hay ko

Có rất nhiều câu hỏi tương tự mà tester có thể đặt ra để phân tích tự cải tiến, tùy thuộc vào loại dự án hoặc tổ chức mà họ đang làm việc. Điều quan trọng nhất là tất cả các hoạt động này không chỉ là làm khi bắt đầu dự án mà cần phải được thực hiện như thói quen hàng ngày.

Nguồn: http://www.softwaretestinghelp.com