Helpex - Trao đổi & giúp đỡ Đăng nhập

Hãy trở thành một người kiểm tra phần mềm năng suất hơn

Hãy tưởng tượng tình huống này: Một nhóm chỉ còn vài ngày nữa là bản phát hành khi một vài tính năng cuối cùng đã có mặt trên máy chủ. Nhóm thử nghiệm đào sâu và bắt đầu tìm ra lỗi. Các vòng kết nối phát hiện lỗi, sửa lỗi, xây dựng lại và kiểm tra lại đang diễn ra vài giờ trước khi phát hành. Mọi thứ có vẻ không tốt.

Khi mọi thứ chậm lại trong một bản phát hành, lỗi ban đầu hầu như luôn hướng về người thử nghiệm. Thật không may, đây là cách nó hoạt động trong nhiều tổ chức (không lành mạnh). Kaizen , khái niệm cải tiến liên tục của người Nhật, có thể giúp tránh những vấn đề này vào phút cuối.

Làm thế nào để trở thành một người kiểm tra phần mềm năng suất hơn

Một lý do có thể cho sự tắc nghẽn kiểm tra đó là hệ thống quản lý kiểm tra và cách người kiểm tra và người quản lý sử dụng chúng. Cách sử dụng điển hình của các hệ thống này trông giống như sau:

  • Người thử nghiệm dành một phần ba đầu tiên của bản phát hành để ghi lại các ý tưởng thử nghiệm

  • Mỗi ý tưởng thử nghiệm được chia nhỏ thành một nhóm bước cụ thể, với một số khẳng định trong quá trình thực hiện

Xem ví dụ dưới đây:

Ví dụ về ý tưởng thử nghiệm
Hãy trở thành một người kiểm tra phần mềm năng suất hơn

Kiểu tài liệu trên không thực hiện tốt công việc minh họa cách kiểm tra được thực hiện và nó không tốt trong việc giúp mọi người tìm ra lỗi. Vậy làm cách nào để các nhóm có thể nhận được tài liệu tốt hơn để thúc đẩy năng suất? Chúng ta sẽ nói về hai phương pháp - loại bỏ thông tin không cần thiết và khái quát hóa. Đối với mỗi biến thể nhỏ về dữ liệu hoặc thay đổi trong các bước cần thực hiện, một ý tưởng thử nghiệm mới sẽ được ghi lại. Cuối cùng, phần mềm thay đổi và các bước này không còn phù hợp nữa, dẫn đến rất nhiều công việc bị lãng phí. Có thể thanh tìm kiếm chuyển đến một trang khác trong phần mềm, có thể một công cụ lọc mới được thêm vào thanh tìm kiếm làm phức tạp bài kiểm tra hoặc có thể dữ liệu kiểm tra đó không còn phù hợp nữa. Về lý thuyết, bài kiểm tra đó nên được sử dụng bởi bất kỳ ai trong tòa nhà. Nhưng, bây giờ nó giống như một khoản cho vay thu lãi theo hình thức kỳ hạn.

Tài liệu thử nghiệm có thể làm chậm năng suất trong hai cách

  1. Thời gian dành cho việc tạo tài liệu mới có thể đã được dành để thử nghiệm

  2. Thời gian dành cho việc tham khảo tài liệu có thể ít hơn

Tăng tốc người kiểm tra là vấn đề hack các phần của tài liệu hiện không tăng thêm giá trị.

Ít nhất một nửa thông tin trong 'ví dụ về ý tưởng thử nghiệm' ở trên là vô ích hoặc có thể được trình bày ở một định dạng khác, để thu gọn vấn đề bảo trì. Nếu ai đó đang kiểm tra một trang web, họ không cần được yêu cầu mở trình duyệt và điều hướng đến trang đó. Nếu một người cần biết điều đó, thì họ không nên thử nghiệm phần mềm hoặc giao tiếp của nhóm thực sự tồi tệ.

Phần hiển nhiên khác là khái quát hóa. Mọi người có thể và thực hiện tạo các trường hợp thử nghiệm cho mọi hoán vị của dữ liệu tồn tại. Điều này thường hữu ích khi ghi lại các thủ tục thiết lập. Nhưng phần lớn, mức độ chi tiết cao này sẽ làm chậm nhóm nghiên cứu trong tương lai vì tốn nhiều thời gian để tạo, bảo trì và sử dụng. Hầu hết chúng có thể được thay thế dễ dàng bằng một định dạng như thế này:

Ví dụ về ý tưởng kiểm tra ít chi tiết hơn

  • Trình duyệt: Chrome, IE9, 10, FireFox
  • Giá trị ngày: quá khứ, tương lai, tập hợp con trong phạm vi tốt
  • Định dạng ngày: mm / dd / yy, mm / dd / yyyy, dd / mm / yy, các định dạng không hợp lệ do bạn chọn

Người thử nghiệm sử dụng định dạng này có thể lấy những gì trước đây có thể đã đi vào 10 'trường hợp thử nghiệm' riêng lẻ trở lên và đúc kết thành một, tạo ra một câu chuyện dày đặc thông tin hơn về cách một thứ gì đó có thể được kiểm tra. Điều này giới thiệu một số thay đổi rất cần thiết về cách phần mềm sẽ được kiểm tra, đồng thời làm cho hầu hết các khía cạnh của gánh nặng tài liệu trở nên nhanh hơn và hữu ích hơn.

Câu hỏi 'làm thế nào để ai đó biết được những bài kiểm tra nào đã được đề cập' sẽ xuất hiện tiếp theo. Đây là câu trả lời. Trong khi thử nghiệm thay đổi trường ngày mới, một người có thể nói “đã thử nghiệm với các giá trị ngày 3/2/81, 03/02/81 và 3/2/1981 bằng Internet Explorer 10 và Chrome”. Lưu ý rằng việc thực hiện như vậy sẽ vượt qua các bước kiểm tra rõ ràng và giúp chia sẻ câu chuyện về cách phần mềm đã thực sự được kiểm tra. Nó cũng cho phép những người thử nghiệm trong tương lai biết loại tính năng nào đã có trong quá khứ và nơi nó có thể cần được mở rộng.

Có rất nhiều yếu tố ảnh hưởng đến năng suất của người thử nghiệm. Đôi khi những thứ đó nằm trong nhóm thử nghiệm, đôi khi vấn đề nằm trong tài liệu và đôi khi thử nghiệm chỉ là điều cuối cùng xảy ra trong bản phát hành. Chủ động về những gì được ghi lại và cách nhóm sử dụng hệ thống quản lý có thể tránh được tác động năng suất đó.

7 hữu ích 0 bình luận 4.9k xem chia sẻ

Có thể bạn quan tâm

loading