10 điều Người kiểm thử KHÔNG nên làm

1)      Đừng để các nhà phát triển truy cập vào máy thử nghiệm của bạn.  Một điều cần nhớ là hệ thống kiểm tra của bạn phải mô phỏng máy của người dùng. Nếu phần mềm đang thử nghiệm được cài đặt bằng gói cài đặt, việc yêu cầu nhà phát triển thả tệp thực thi vào máy sẽ đưa máy của bạn từ cấu hình tiêu chuẩn sang cấu hình không chuẩn. Nếu trình cài đặt không dọn sạch tệp cũ hoặc không cài đặt tệp mới hơn do sự khác biệt về phiên bản thì hiện tại bạn đang thử nghiệm thứ gì đó sẽ không được tìm thấy trong trường. Không có gì bạn làm từ thời điểm đó trở đi có thể được coi là hợp lệ. Nếu có thể khôi phục hệ thống từ trạng thái trước đó (tức là sử dụng phần mềm sao lưu như Ghost hoặc sử dụng Windows để tạo điểm khôi phục) thì bạn nên an toàn nhưng tốt nhất nên sử dụng máy khác. Trên thực tế, sử dụng hình ảnh ảo của máy thử nghiệm của bạn sẽ là một ý tưởng hay. Điều này cho phép nhà phát triển truy cập vào những gì bạn đang sử dụng, chỉnh sửa nó bao nhiêu tùy thích và xóa kết quả cuối cùng hoặc khôi phục lại phiên bản trước của hình ảnh ảo.

2)      Không truy cập phần mềm với tư cách là người dùng không phù hợp - Kiểm tra tất cả là vì người dùng. Thông thường, những người dùng khác nhau có quyền truy cập khác nhau. Quản trị viên có thể làm những việc mà hầu hết người dùng thông thường không thể. Việc kiểm tra với tư cách quản trị viên vì bạn cần phải là người dùng quản trị viên để thực hiện tác vụ kiểm tra trước là sai. Cách tốt nhất là tạo người dùng có quyền truy cập phù hợp trong phần mềm đang được thử nghiệm (nếu nó hỗ trợ khả năng này). Trên máy tính, luôn truy cập phần mềm với tư cách người dùng thích hợp (Quản trị viên hoặc Người dùng chuẩn). Nếu bạn sử dụng hệ thống với tư cách là người dùng mạng, hãy đăng nhập bằng Network Standard và Network Administrator. Có thể phần mềm không quan tâm bạn thuộc loại người dùng nào (điện thoại và máy tính bảng thường không hỗ trợ loại người dùng) nhưng nhiều hệ thống cung cấp cho bạn khả năng điều chỉnh quyền truy cập vào các chức năng. Luôn sử dụng đúng người dùng, quy trình làm việc phù hợp, v.v.

3)      Không sử dụng/kiểm tra hệ thống một cách ngẫu nhiên.  Luôn có một kế hoạch, ngay cả khi nó không được ghi chép đầy đủ ở cấp độ trường hợp thử nghiệm. Ngay cả khi bạn “chỉ đang thực hiện một số thử nghiệm đặc biệt”, bạn vẫn nên biết mình đã làm gì. Sẽ lãng phí rất nhiều thời gian khi tìm ra một vấn đề mà bạn không thể tái hiện lại vì bạn không nhớ mình đã làm gì. Windows và phần mềm khác cho phép bạn ghi lại các bước của mình để bạn có thể xem mình đã làm gì. Các ghi chú về các bước bạn đã thực hiện hoặc kế hoạch cấp cao hoặc danh sách các chức năng cần kiểm tra cũng sẽ hữu ích để tìm ra cách bạn đến được vị trí hiện tại khi gặp sự cố.

4)      Đừng chỉ ném khuyết điểm “qua hàng rào ”. Luôn đảm bảo rằng bạn đã ghi lại vấn đề tốt nhất có thể. Hãy rõ ràng nhất có thể và bao gồm ảnh chụp màn hình, video, nhật ký, quy trình công việc, v.v. Mục này đi cùng với mục trước đó. Nếu bạn biết mình đang làm gì, việc bao gồm thông tin về lỗi đó sẽ giúp nhà phát triển dễ dàng tìm ra nơi tìm mã cho vấn đề. Sử dụng hình ảnh ảo để thử nghiệm cũng là một ý tưởng hay vì bạn chỉ cần tạm dừng nó và giao hình ảnh cho nhà phát triển. Sau đó, họ có thể tìm ra trạng thái của máy và cố gắng khắc phục sự cố cụ thể. Họ có thể lấy các kết xuất lõi và ngăn xếp cuộc gọi để xem những gì đã được thực hiện và thông tin nào được lưu trữ trên hệ thống. Trong khi nhà phát triển đang sử dụng hình ảnh ảo của bạn, bạn có thể sử dụng hình ảnh khác. Điều này cho phép bạn tiếp tục làm việc trong khi vấn đề đang được xem xét. Nếu nhà phát triển cần hình ảnh trong vài ngày, bạn không cần phải chờ đợi và có thể tiếp tục thử nghiệm.

5)      Đừng buồn nếu lỗi bạn nêu ra bị từ chối . Có nhiều khía cạnh cho thấy mức độ quan trọng của một lỗi và với tư cách là người kiểm tra, bạn không phải lúc nào cũng có tất cả thông tin cần thiết để đưa ra quyết định. Nhân viên hỗ trợ, người quản lý sản phẩm, v.v. thường có ý tưởng tốt hơn về cách sử dụng chức năng đó, tần suất truy cập chức năng đó và mức độ nghiêm trọng nếu nó không hoạt động như quảng cáo. Nếu bạn vẫn cảm thấy khuyết điểm đó là quan trọng trong khi những người xung quanh bạn thì không, có lẽ bạn cần phải giải thích rõ hơn về bản thân. Hãy thực hiện một giải pháp khác cho vấn đề. Hành vi là gì? Tại sao nó lại có hại? Tác động chức năng xuôi dòng là gì nếu không được sửa chữa? Công ty có thể phải trả giá bao nhiêu nếu không được sửa chữa?

6)      Đừng nghĩ rằng hiệu suất không quan trọng khi lần đầu tiên thử nghiệm chức năng mới.  Nếu bạn thấy hệ thống lúc này hoạt động chậm, khi bạn là người duy nhất trong hệ thống thì khi sử dụng hết công suất sẽ như thế nào? Báo cáo mọi hành vi không nhất quán và tình trạng chậm hệ thống trong quá trình thực hiện. Nếu tổ chức của bạn không có yêu cầu hoặc mục tiêu về hiệu suất thì nguyên tắc chung là hệ thống sẽ phản hồi trong vòng 2-4 giây. Đôi khi câu trả lời là hệ thống đang bận thu thập thông tin để cung cấp cho bạn. Kiểm tra với nhóm hiệu suất của bạn nếu bạn có hoặc với nhóm yêu cầu của Chủ sở hữu sản phẩm. Với tư cách là người ủng hộ khách hàng, người kiểm thử nên xác định các vấn đề về hiệu suất có thể xảy ra càng sớm càng tốt để có thể khắc phục chúng.

7)      Đừng báo cáo lỗi mà không kiểm tra xem nó đã được xác định chưa.  Đối với mỗi khiếm khuyết được nêu ra, một lượng công việc nhất định cần phải được thực hiện trước khi ai đó nhận ra rằng vấn đề đã được biết và/hoặc được xác định. Số lượng quy trình càng lớn và nhóm càng lớn thì càng cần nhiều nỗ lực lãng phí. Thực hiện một lượng nhỏ nghiên cứu trước khi phát hiện lỗi sẽ đảm bảo giảm thiểu thời gian lãng phí. Trên mã mới hoặc trong môi trường Agile, hãy kiểm tra với nhà phát triển, nếu không hãy xem kho lưu trữ quản lý lỗi hoặc kiểm tra với những người thử nghiệm hoặc trưởng nhóm kiểm tra của bạn. Một sự lãng phí thời gian khác là khi bạn nêu ra khuyết điểm của một thứ được coi là “hành vi được mong đợi”. Đưa ra một khiếm khuyết mà cuối cùng sẽ được khắc phục cũng làm lãng phí thời gian của mọi người. Nếu các yêu cầu hoặc trường hợp sử dụng không đủ rõ ràng, hãy xác nhận với nhóm yêu cầu hoặc chủ sở hữu sản phẩm về điều gì sẽ xảy ra.

8)      Đừng giữ thông tin cho riêng mình.  Nhóm của bạn sẽ được hưởng lợi từ bất kỳ điều gì bạn biết về phần mềm đang được thử nghiệm. Nếu có thông tin chi tiết mà bạn tìm hiểu về cách định cấu hình phần mềm, cài đặt phần mềm trên nền tảng thử nghiệm, điều chỉnh hệ điều hành, v.v., hãy ghi lại những điều này và chia sẻ chúng với nhóm của bạn. Bất cứ điều gì bạn học sẽ làm cho nhiệm vụ kiểm tra trở nên dễ dàng hơn đối với những người khác. Rất có thể họ cũng sẽ chia sẻ một số thông tin hữu ích cho bạn và bạn có thể hưởng lợi từ sự chăm chỉ của họ. Lưu trữ thông tin trên trang SharePoint, trang web, bảng thông báo hoặc bất cứ nơi nào mọi người trong nhóm có thể truy cập.

9)      Đừng giữ nguyên hiện trạng.  Bất cứ điều gì bạn có thể làm để cải thiện khả năng kiểm tra của nhóm đều mang lại lợi ích. Sử dụng ảo hóa, sử dụng tự động hóa thử nghiệm, sử dụng tập lệnh. Mọi việc tốn ít thời gian hơn sẽ giúp bạn có nhiều thời gian hơn để làm những việc khác. Nếu bạn tìm thấy điều gì đó mà bạn nghĩ có thể mang lại lợi ích cho nhóm hoặc công ty, hãy chuyển thông tin đó lên chuỗi. Hãy thảo luận vấn đề này với những người thử nghiệm đồng nghiệp, trưởng nhóm thử nghiệm và Người quản lý để xem liệu bạn có thể áp dụng những điều gì không và nếu có thì bằng cách nào. Và nếu bạn thực sự hoàn thành tất cả các bài kiểm tra được giao, hãy xem mục cuối cùng

10)   Không ngừng học hỏi.  Nếu bạn có thể tìm ra những điều bạn cần biết để có thể làm công việc của mình tốt hơn hoặc có thể thăng tiến trong công ty, hãy tận dụng mọi thời gian rảnh rỗi mà bạn có để học. Tham gia các khóa học. Đọc blog, xem vlog và hội thảo trên web. Rất nhiều công ty và nhóm cung cấp chương trình đào tạo về các chủ đề có thể giúp bạn tiến lên phía trước. Đôi khi, bạn có thể đăng ký một hội thảo trên web và nhận được liên kết để xem nó khi rảnh rỗi thay vì khi họ muốn phát sóng nó. Sách trắng từ các trang web liên quan đến thử nghiệm, phần mềm thử nghiệm, v.v. đều có sẵn và có thể đọc ngoại tuyến khi bạn đi/đi làm về hoặc trong khi ăn trưa. Có rất nhiều hội thảo âm thanh, podcast và sách nói mà bạn có thể nghe khi đang lái xe hoặc khi đang đi dạo trong ngày.

Source: https://www.linkedin.com/pulse/10-things-testers-should-do-micheal-schoonbaert