6 kỹ năng cơ bản mà mọi Tester cần có

0
15

Kiểm thử phần mềm hoặc QA là nền tảng tốt nhất cho những người mới tham gia vào ngành CNTT bất chấp những quan niệm sai lầm rằng đó là một công việc được trả lương thấp hơn hoặc thấp hơn.

Kỹ năng quan trọng nhất mà người kiểm tra cần là khả năng tìm lỗi . Và, nếu bạn là kiểu người thích tìm lỗi, thì bạn sẽ yêu thích và phát triển trong lĩnh vực này.

Phải nói rằng, có một vài kỹ năng có thể giúp bạn tìm ra lỗi và làm việc với các quy trình QA tốt hơn. 

Đây là bài viết sẽ hiển thị quy trình QA vì nó được theo dõi ở hầu hết các công ty và sẽ cung cấp cho những người thử nghiệm mới làm rõ về thử nghiệm.  

Cụ thể, bạn tìm hiểu quy trình và tiêu chuẩn tài liệu, công việc trước của người kiểm tra, kiểm tra dựa trên các ràng buộc, kiểm tra trong quá trình phát triển một phần và cuối cùng là quy trình đăng xuất.

1. Tài liệu dành cho Tester

Tài liệu là điều cần thiết để thử nghiệm. Hầu hết các công ty giao nhiệm vụ này cho người mới. Để thành công, bạn nên có vốn từ vựng tốt vì phần còn lại của những thứ như tiêu chuẩn tài liệu, v.v. không nằm trong tầm kiểm soát của bạn và phụ thuộc vào quy trình của nhóm và của công ty.

Ngoài ra, hãy chắc chắn rằng bạn thấy giá trị của quy trình tài liệu. Ưu điểm là rất nhiều – chúng giúp bạn theo dõi các thay đổi yêu cầu, theo dõi các bước kiểm tra, đăng nhập công việc của bạn, v.v.

2. Luyện thi

Trong tất cả các tài liệu có sẵn, những điều sau đây không thể bị bỏ qua. Đây cũng được gọi là tài liệu có thể giao được và là cầu nối sự hiểu biết của khách hàng, nhà phát triển và người thử nghiệm.

a) Kế hoạch kiểm tra: Biểu đồ luồng thử nghiệm từ đầu đến cuối .

Kế hoạch kiểm tra miêu tả phạm vi và các hoạt động của giai đoạn thử nghiệm. Được tạo bởi lãnh đạo QA, nhóm phải đóng góp và cập nhật về mọi thứ được viết trong kế hoạch kiểm tra.

Một số đội có nhiều cấp kế hoạch kiểm tra: Kế hoạch tổng thể và Kế hoạch khôn ngoan.

Một kế hoạch kiểm tra phải có:

  • Tên dự án và phiên bản
  • Mã định danh kế hoạch kiểm tra – Người tạo, bản nháp số, ngày tạo, v.v.
  • Giới thiệu – Tổng quan về dự án, mục tiêu và các ràng buộc
  • Tài liệu tham khảo – Danh sách tài liệu tham khảo được sử dụng làm đầu vào. (Đảm bảo bạn sử dụng các phiên bản chính xác và mới nhất)
  • Các mục kiểm tra – Mô-đun, phiên bản, phạm vi, ngoài phạm vi, v.v.
  • Phương pháp thử nghiệm / Chiến lược thử nghiệm tổng thể – Các công cụ để sử dụng, quy trình theo dõi lỗi, mức độ thử nghiệm để thực hiện, v.v.
  • Tiêu chí mục Pass / Fail – Hướng dẫn thực hiện kiểm tra
  • Tiêu chí đình chỉ và nối lại
  • Sản phẩm thử nghiệm – Trường hợp thử nghiệm, báo cáo thử nghiệm, báo cáo lỗi, số liệu thử nghiệm, v.v.
  • Kiểm tra chi tiết môi trường
  • Đội hình với thông tin liên lạc. cho mỗi mô-đun hoặc loại thử nghiệm
  • Dự toán kiểm tra – Thời gian và nỗ lực. Chi tiết ngân sách được bảo mật và bạn sẽ không tìm thấy chúng ở đây
  • Rủi ro và kế hoạch giảm thiểu
  • Phê duyệt
  • Hướng dẫn khác

b) Kịch bản thử nghiệm:

Một dòng con trỏ về ‘những gì cần kiểm tra’ dựa trên từng yêu cầu và thường được ghi lại và theo dõi thông qua bảng tính.

Hầu hết chúng chứa:

  • Tên mô-đun / Thành phần / chức năng (đăng nhập, quản trị viên, đăng ký, v.v.)
  • ID kịch bản là để tham khảo (Ví dụ: TS_Login_001)
  • Mô tả kịch bản – ‘Kiểm tra những gì’ Ví dụ: Xác thực nếu đăng nhập cho phép người dùng có thông tin đăng nhập hợp lệ để đăng nhập thành công
  • Tầm quan trọng của kịch bản – Ưu tiên trong trường hợp không đủ thời gian – Cao / Trung bình / Thấp
  • ID yêu cầu – Để truy xuất nguồn gốc

c) Các trường hợp thử nghiệm:

Các trường hợp kiểm tra chính xác cho kết quả kiểm tra chính xác. Bảng tính vẫn là phương tiện phổ biến để viết trường hợp thử nghiệm, đặc biệt là cho người mới bắt đầu, mặc dù một số công ty điều chỉnh các công cụ quản lý kiểm tra. Cơ sở để viết trường hợp thử nghiệm là tài liệu SRS / FRD / Req. Nhưng, nó thường không đủ, vì vậy bạn sẽ phải sử dụng rất nhiều giả định và thảo luận với các nhóm BA / Dev.

Viết các trường hợp kiểm tra hiệu quả là trình độ quan trọng nhất mà người kiểm tra phải có. Thông thường, tất cả các trường hợp thử nghiệm được phân loại là dương / âm. Trường hợp thử nghiệm tích cực là đưa ra đầu vào hợp lệ và nhận được kết quả tích cực. Trường hợp kiểm tra tiêu cực là đưa ra đầu vào không hợp lệ và nhận được thông báo lỗi chính xác.

Để biết thêm thông tin về những điều này, hãy kiểm tra:

Một số thuộc tính phổ biến mà tất cả các trường hợp thử nghiệm có là:

  • ID kịch bản – Lấy từ tài liệu kịch bản thử nghiệm
  • ID trường hợp thử nghiệm – Để nhận dạng và theo dõi duy nhất. Ví dụ: TC_login_001
  • Mô tả thử nghiệm – Giải thích ngắn gọn về điều kiện thử nghiệm được thử nghiệm
  • Các bước thực hiện – Chi tiết từng bước hướng dẫn cách kiểm tra
  • Dữ liệu thử nghiệm – Dữ liệu được cung cấp cho các bước kiểm tra
  • Kết quả mong đợi – Kết quả như mong đợi
  • Kết quả thực tế – Phản hồi của AUT khi chạy thử
  • Trạng thái – Đạt / Không đạt / Không chạy / Chưa hoàn thành / Bị chặn – Mô tả kết quả của bài kiểm tra
  • Nhận xét – Để biết thêm chi tiết
  • Được thực hiện bởi – Tên của người kiểm tra
  • Ngày thực hiện – Ngày chạy thử nghiệm
  • ID khiếm khuyết – Khiếm khuyết được ghi lại trong trường hợp thử nghiệm, trong trường hợp thử nghiệm thất bại
  • Chi tiết cấu hình – Hệ điều hành, Trình duyệt, Nền tảng, thông tin thiết bị (tùy chọn)

3. Quy trình kiểm tra – Những bài kiểm tra để thực hiện?

Có một số lượng lớn các loại thử nghiệm, nhưng không phải tất cả chúng đều có thể được thực hiện trên AUT đó. Thời gian, ngân sách, tính chất kinh doanh, tính chất của ứng dụng và mối quan tâm của khách hàng là những nhân tố chính trong việc lựa chọn những thử nghiệm cần làm trên ứng dụng.

Ví dụ : Nếu đó là một cổng thương mại trực tuyến, thì kiểm tra căng thẳng và kiểm tra tải là bắt buộc. Tuy nhiên, một số loại thử nghiệm không nên bỏ qua là:

  • Kiểm tra hộp đen
  • Kiểm tra hộp màu xám
  • Kiểm tra đơn vị (Nếu có)
  • Thử nghiệm hội nhập
  • Kiểm tra tích hợp tăng dần
  • Kiểm tra hồi quy
  • Thử nghiệm chức năng
  • Thi lại
  • Kiểm tra vệ sinh
  • Kiểm tra khói
  • Kiểm tra chấp nhận
  • Kiểm tra khả năng sử dụng
  • Kiểm tra khả năng tương thích
  • Kết thúc thử nghiệm
  • Thử nghiệm Alpha
  • Thử nghiệm beta

4. Thử nghiệm ở giai đoạn phát triển một phần

Nói chung, với các công ty cấp trung và khởi nghiệp, thời gian và nguồn lực có hạn. Những người thử nghiệm ở đây có thể bắt đầu quá trình thử nghiệm của họ trước khi tích hợp mô-đun, điều đó có nghĩa là chúng tôi có thể đang thực hiện các thử nghiệm tích hợp đơn vị và trung gian.

Điều quan trọng cần lưu ý là kết quả từ các giai đoạn này không thể được tính là chính xác, vì vậy bạn có thể phải lập kế hoạch cho một thử nghiệm hộp đen tổng thể một khi mọi thứ đã sẵn sàng. Bỏ qua phần đó có thể chứng minh tốn kém và thử nghiệm, không hiệu quả.

5. Tài liệu báo cáo lỗi

Thực tế, đây là tài liệu QA quan trọng nhất bạn từng làm.

Sau đây là các trường báo cáo lỗi tốt phải có:

  • ID khiếm khuyết – Thường là số sê-ri
  • Mô tả lỗi – Giải thích một dòng về vấn đề
  • Vị trí – Mô-đun / khu vực của AUT nơi tìm thấy sự cố
  • Xây dựng số – Phiên bản và mã xây dựng số.
  • Các bước để tạo lại – Danh sách các bước dẫn bạn đến vấn đề
  • Mức độ nghiêm trọng – Đặt mức để mô tả mức độ nghiêm trọng của vấn đề – Thấp, trung bình, cao, chặn, v.v.
  • Ưu tiên – Được đặt bởi các nhà phát triển để xác định thứ tự lỗi sẽ được sửa (P1, P2, P3, v.v. P1- cao nhất)
  • Được chỉ định cho – Chủ sở hữu của khiếm khuyết tại thời điểm đó
  • Báo cáo bởi – Tên của người kiểm tra
  • Trạng thái – Trạng thái khác nhau để biểu thị giai đoạn vòng đời lỗi
    • Mới – Lỗi được tìm thấy và chỉ được báo cáo
    • Mở – Xác thực bởi khách hàng tiềm năng QA
    • Đã chỉ định – Đã gửi cho nhà phát triển để chỉ định cho nhà phát triển tương ứng
    • Đang tiến hành / Công việc đang tiến triển – Dev bắt đầu làm việc với nó
    • Đã sửa / giải quyết – Nhà phát triển đã hoàn thành công việc trên nó
    • Đã xác minh / Đã đóng – Nhóm QA đã kiểm tra lại và tìm thấy lỗi đã được sửa
    • Thử lại – Nhóm QA không đồng ý với độ phân giải của Dev và tiếp tục xử lý lỗi để làm lại
    • Sao y – Lỗi tương tự đã tồn tại
    • Trì hoãn – Lỗi hợp lệ nhưng sẽ được sửa trong các bản phát hành sau
    • Không hợp lệ – Không phải là lỗi hoặc không thể tái tạo hoặc không có đủ thông tin

6. Quá trình đăng xuất

Đăng xuất và gửi tài liệu cuối cùng là nhiệm vụ của lãnh đạo / quản lý QA. Tuy nhiên, nhóm phải gửi các tài liệu trên (Kịch bản thử nghiệm, Trường hợp thử nghiệm và tài liệu nhật ký lỗi) để đánh giá và kiểm toán lần cuối.

Hãy chắc chắn rằng, bạn đã đọc lại tất cả chúng và gửi các phiên bản cuối cùng.

Tham khảo khóa học Testing tại Hà Nội

LEAVE A REPLY

Please enter your comment!
Please enter your name here