Mình hay đùa rằng việc tìm bug giống như truy tìm tội phạm và người kiểm thử giống như thám tử vậy. Và muốn tìm được “tội phạm” của mình, trước hết người kiểm thử viên cần biết đặc điểm nhận diện của chúng, khoanh vùng những chỗ khả nghi, và truy tìm theo đầu mối. Mỗi loại bug khác nhau sẽ có những đặc thù khác nhau. Trong bài viết hôm nay, mình sẽ giới thiệu cho các bạn một số loại bug phổ biến cùng những đặc điểm đặc trưng của chúng. Nào, hãy cùng mình tìm hiểu nhé.
Test Web hay Test Website là việc kiểm tra trang web hay ứng dụng web của bạn nhằm đảm bảo chúng hoạt động theo một tiêu chuẩn chất lượng nhất định. Đó là một quá trình bao gồm nhiều hoạt động khác nhau, nhưng mục tiêu chính luôn giống nhau – phát hiện càng nhiều lỗi càng tốt và phát triển các phương pháp nhằm ngăn chặn chúng trong tương lai.
Kiểm thử phần mềm là một quá trình điều tra. Người kiểm thử đưa phần mềm qua rất nhiều bài kiểm tra để phát hiện bất kỳ lỗi ẩn nào, hành vi không đoán trước hoặc sự không nhất quán về chức năng. Sau mỗi lần kiểm tra, người kiểm thử sẽ gửi một báo cáo chi tiết giúp các nhà phát triển khắc phục các sự cố đã phát hiện, duy trì phần mềm không có lỗi và đảm bảo phần mềm chạy như dự định. Hiện nay có nhiều phương pháp kiểm thử phần mềm, nhưng phổ biến nhất vẫn là Black-box Testing, White-box testing, Grey-box testing. Bằng các cách tiếp cận khác nhau, các phương pháp này giữ cho code sạch và kiểm tra chức năng một cách hiệu quả.
Bài viết này hãy cùng mình tìm hiểu về Những phương pháp này là gì, Chúng được sử dụng để làm gì, Sự khác biệt giữa chúng, cũng như tìm ra điểm mạnh và điểm yếu của từng phương pháp kiểm thử. Nào hãy cùng bắt đầu nhé!
Trong quá trình kiểm thử phần mềm, việc thiết kế các bộ dữ liệu kiểm thử (test data) đóng vai trò quan trọng để đảm bảo tính toàn vẹn và độ tin cậy của phần mềm. Thiết kế các bộ dữ liệu kiểm thử hiệu quả giúp tăng độ chính xác của kết quả kiểm thử và giảm thiểu những rủi ro tiềm ẩn trong quá trình sử dụng phần mềm.
Để thiết kế các bộ dữ liệu kiểm thử, ta cần phải hiểu rõ yêu cầu và chức năng của phần mềm cần kiểm thử. Dựa trên đó, ta có thể thiết kế các bộ dữ liệu kiểm thử đa dạng, phong phú và đầy đủ các trường hợp kiểm thử. Các bộ dữ liệu kiểm thử cần bao gồm các trường hợp kiểm thử cơ bản và các trường hợp kiểm thử đặc biệt.
Ở phần 1 mình đã giới thiệu về kiểm thử mobile là gì, phân loại các loại mobile app và việc lập chiến lược kiểm thử trên mobile. Trong bài viết này, mình xin giới thiệu danh sách kiểm tra – checklist cho mobile app. Checklist này sẽ cung cấp cho người kiểm thử cách tiếp cận từng bước kiểm tra để đảm bảo chất lượng sản phẩm trước khi phát hành ra thị trường.
Ngành công nghiệp ứng dụng di động đang phát triển với tốc độ chưa từng thấy. Điều này đã dẫn đến sự gia tăng đáng kể số lượng ứng dụng sẵn có để người dùng cuối tải xuống. Các ứng dụng dành cho thiết bị di động đóng vai trò quan trọng trong việc thay đổi cách mọi người làm việc, giao tiếp, mua sắm cũng như tương tác với nhau. Vì vậy, để sản phẩm của bạn nổi bật giữa đám đông, khi người dùng tiếp tục tải xuống hàng nghìn ứng dụng mỗi ngày, là một thách thức lớn. Sản phẩm của bạn phải đảm bảo chất lượng, đẹp mắt và đáp ứng được nhu cầu sử dụng của người dùng.
Với vai trò là một nhà kiểm thử phần mềm, bạn cần thực hiện những danh mục kiểm thử gì? Các công cụ, thiết bị nào có thể hỗ trợ kiểm thử? Các bước lập kế hoạch là gì? Hãy cùng mình tìm hiểu qua bài viết này nhé.
Functional testing và phi chức năng là cách tiếp cận phổ biến nhất để phân loại các loại kiểm thử phần mềm khác nhau. Hai loại này đề cập đến bản chất của quá trình thử nghiệm và chính xác những gì đang được thử nghiệm. Có hai điều cần biết về functional testing và phi chức năng nếu bạn chưa từng tìm hiểu sâu về hai loại kiểm thử này trước đây.
Thứ nhất, sự phân chia giữa functional testing và phi chức năng không cố định. Đối với một số loại kiểm thử, việc phân loại chúng không phải là điều dễ dàng.
Thứ hai, cả functional testing và phi chức năng đều cần thiết cho sự thành công của dự án kiểm thử phần mềm của bạn, mặc dù theo những cách khác nhau.
Bước vào lĩnh vực IT có thể rất khó khăn. Để làm việc tốt trong nghề này bạn cần sẵn sàng và mong muốn học hỏi, không ngừng cải thiện kỹ năng của mình và có mục tiêu trở thành một chuyên gia trong lĩnh vực của mình. Đây không phải là con đường sự nghiệp dễ dàng, nhưng nó rất đáng giá.
Mình không học CNTT, cũng không bắt đầu công việc kiểm thử phần mềm. Mình học qua những đồng nghiệp của mình, qua những buổi chia sẻ, đào tạo training của những người đi trước. Một câu nói mà mình rất thích khi bắt đầu theo đuổi con đường này:
**If not you, but who?**
**If not now, but then?**
Nếu bạn có hứng thú với nghề kiểm thử phần mềm, hãy tự mình tìm hiểu và đưa ra quyết định nhé. Bởi “Không phải bạn thì là ai? Không phải bây giờ thì khi nào?”
Khi bạn là một tester mới trong một công ty phần mềm (yeah, giống mình), bạn có thể đối mặt với một số thử thách trong những ngày đầu. Bạn cần tìm hiểu quy định công ty, quy trình dự án, làm quen đồng nghiệp mới. Bạn biết đấy, nó chẳng dễ dàng gì. Tuy nhiên, bạn sớm sẽ học được chúng, điều khó khăn nhất còn chưa đến. Bạn có thể sẽ tham gia vào một dự án đầu tiên – với rất nhiều những ràng buộc, các module, các component cần bạn test nhanh chóng, nhưng phải chất lượng. May mắn ra bạn sẽ được cung cấp tài liệu hoặc mockup, nhưng nếu không – thì đây là thời điểm bạn cần tới Kiểm thử thăm dò – Exploratory testing.
Tìm bug và viết báo cáo về bug phát hiện là một trong những công việc quen thuộc của mọi kiểm thử viên. Một bug được báo cáo hiệu quả thì cơ hội được sửa chữa của nó sẽ cao hơn. Report bug là một kỹ năng, và để trở thành một kiểm thử viên chuyên nghiệp thì bạn cần nắm được kỹ năng này. Bài viết này mình sẽ giới thiệu về quy trình viết bug report cũng như các mẹo để có một report hiệu quả và chuyên nghiệp.