Hế hế, hơn một năm viết blog rồi nhé!

Đúng ra thì sinh nhật 1 tuổi của blog là qua rồi, bài viết đầu tiên được “công khai” là một ngày cuối tháng 6 gì đó. Ấy thế mà mình lại quên mất, thặc là vô tâm quá đi mà :)) hôm nay bỗng vui vì lượt truy cập tăng vọt với con số kỉ lục từ trước đến giờ :))) mặc dù tính theo lượt khách ghé thăm thì vẫn lẹt đẹt như những ngày bình thường khác =)), nhưng vẫn vui nhé! kaka

loi-chuc-mung-sinh-nhat02-1

Read More »

Advertisements

Tự do và khám phá: Adhoc testing vs Exploratory testing

Vẫn là chủ đề lý thuyết nhàm cmn chán, nhưng mà vẫn phải học :v. Học rồi còn đi áp dụng, và trên thực tế là mình đã và đang sử dụng 2 loại này rồi nhé – không đùa tí nào :v. Bây giờ vấn đề là gõ lại cho nhớ và luyện khả năng diễn giải các ý cho dễ hiểu nữa. Về hai loại này theo mình có một vài điểm cần nhớ, chi tiết đọc tiếp nội dung phía dưới nha. Hi vọng bài viết sẽ giúp ích cho các bạn.

1. Adhoc testing

Adhoc testing là một loại kiểm thử không chính thức, với mục đích là tìm các “điểm chết” của hệ thống. Loại kiểm thử này thường không có kế hoạch thực hiện tức là bạn sẽ không cần tuân theo một kỹ thuật thiết kế test design nào để tạo test case cả. Và thực tế là chúng ta cũng sẽ không tạo và làm theo test case nào hết! Do đó, loại kiểm thử này yêu cầu rất cao về mức độ hiểu hệ thống của người thực hiện kiểm thử. Và tester sẽ thực hiện kiểm thử ứng dụng một cách ngẫu nhiên các trường hợp mà không sử dụng một tài liệu test case hay mô tả nghiệp vụ nào.

Adhoc testing không yêu cầu các tài liệu, kế hoạch hay quy trình. Vì mục đích của loại kiểm thử này là tìm lỗi thông qua hướng tiếp cận ngẫu nhiên, vì không dựa theo bất kỳ tài liệu nào, nên các lỗi tìm thấy sẽ không được ánh xạ tới các test case tương ứng như bình thường. Vì thế mà đôi khi sẽ rất khó để tái hiện lại lỗi.

Khi nào thì sử dụng Adhoc testing?

Adhoc testing có thể được thực hiện khi có một thời gian giới hạn nào đó cho các kiểm thử phức tạp. Thông thường Adhoc testing được thực hiện sau khi đã hoàn thành việc thực thi kiểm thử theo đúng quy trình. Nếu như có thời gian, thì có thể hoàn thành thực hiện Adhoc testing cho hệ thống. Adhoc testing sẽ hiệu quả hơn nếu người thực thi kiểm thử có kiến thức tốt về hệ thống đó.

Thực hiện Adhoc testing hiệu quả:

* Nắm chắc nghiệp vụ

Yếu tố then chốt quyết định phần lớn hiệu quả trong Adhoc testing đó là việc người thực thi kiểm thử hiểu nghiệp vụ của hệ thống đến đâu. Do đó, khi quyết định thực hiện Adhoc testing thì cần phải chắc chắc được rằng bạn đã thông suốt về các ngõ ngách của hệ thống, ứng dụng. Điều này giúp bạn có thể dễ dàng thực hiện được những trường hợp thực tế nhất, và có thể đoán được các vùng có khả năng xảy ra lỗi nhiều nhất.

* Kiểm tra các module chính

Cần xác định các chức năng quan trọng chính của hệ thống là đối tượng tập trung của Adhoc testing. Vì sao lại thế, đơn giản thôi vì chức năng chính quan trọng chính là cái mà người dùng sẽ sử dụng và tương tác nhiều nhất, thế mà lại để lọt lỗi trên đó thì sẽ là điều khó mà chấp nhận được! 😀

* Lưu lại các defect

Tất cả các lỗi tìm được từ Adhoc testing đều cần phải được lưu lại và gửi cho team dev để fix bug. Các lỗi hợp lệ cần được viết bổ sung và thêm vào trong bộ test case. Cái này thường là do viết test case thiếu, chưa bao phủ được các trường hợp.

Các defect tìm được này chính là những bài học kinh nghiệm, cần phải được xem xét và đánh giá nghiêm túc, rút kinh nghiệm cho các vòng test sau hay những trường hợp, sản phẩm có tính năng tương tự.

2. Exploratory testing

Exploratory testing, bao gồm các hoạt động khám phá, tìm hiểu và học hỏi. Chủ yếu nhấn mạnh vào khả năng kiểm thử tự do, đi kèm với trách nhiệm của người kiểm thử. Trong Exploratory testing, các test case cũng không được tạo ra khi tiến hành kiểm thử. Tuy nhiên là ta có thể ghi ra một vài ý tưởng chính sẽ được thực hiện trước khi bắt tay vào làm. Exploratory testing tập trung vào việc thăm dò khám phá ứng dụng hơn việc thực thi dựa trên các hoạt động như các loại kiểm thử khác.

* Ưu điểm

Loại kiểm thử này sẽ rất hữu ích trong trường hợp các tài liệu yêu cầu chưa được cung cấp đầy đủ hoặc có rất ít thông tin.

Liên quan đến quá trình tìm hiểu, giúp tìm ra được nhiều lỗi hơn so với các bước kiểm thử thông thường.

Tìm ra được các lỗi nhỏ mà có thể bị bỏ qua bởi các kỹ thuật kiểm thử khác

Mở rộng khả năng tưởng tượng các tình huống bằng cách thực hiện nhiều hơn các trường hợp kiểm thử.

Đi sâu vào các phần chức năng nhỏ nhất của ứng dụng và bao phủ được các yêu cầu chức năng

Loại kiểm thử này bao phủ được nhiều loại kiểm thử và nhiều loại các kịch bản và trường hợp kiểm thử khác nhau.

Khuyến khích sự sáng tạo và khả năng phán đoán

Có thể tạo ra các ý tưởng mới trong quá trình thực hiện kiểm thử.

* Nhược điểm

Loại kiểm thử này phụ thuộc rất nhiều vào kỹ năng của người thực hiện kiểm thử

Do đó, sẽ dễ bị hạn chế bởi vùng kiến thức của tester

Không phù hợp với dự án có nhiều thời gian cho việc thực thi kiểm thử.

Khi nào thì thực hiện Exploratory testing?

Có thể thực hiện Exploratory testing nếu như:

  • Nhóm kiểm thử có những tester nhiều kinh nghiệm
  • Early iteration is required (Dự án có yêu cầu lặp sớm)
  • Đây là một ứng dụng quan trọng
  • Hoặc có những tester mới tham gia vào nhóm.

3. So sánh nho nhỏ giữa Adhoc testing và Exploratory testing

Adhoc testing Exploratory testing
Bạn cần phải hiểu và nắm được ứng dụng trước khi thực hiện Adhoc testing. Với Exploratory testing thì bạn sẽ tìm hiểu ứng dụng trong khi thực hiện test.
Với Adhoc testing, tài liệu không phải là yếu tố quan trọng cần thiết, Adhoc testing được thực hiện bình thường mà không cần tài liệu đặc tả cụ thể nào. Ngược lại, với Exploratory testing, tài liệu là một yếu tố cần thiết để ghi lại chi tiết các thông tin trong khi thực hiện kiểm thử.
Adhoc được thực hiện để nâng cao mức độ hoàn thiện hướng tới sự hoàn hảo của việc kiểm thử ứng dụng. Exploratory testing thiên về hướng học hỏi, tìm hiểu ứng dụng hơn.
Người thực hiện Adhoc testing cần có kiến thức về quy trình thực hiện khi thực hiện kiểm thử. Với Exploratory testing thì từ đây sẽ giúp cho người thực thi có kiến thức về ứng dụng thông qua các kết quả test.

Các bạn có thể tham khảo thêm thông tin ở đây nhé, bài viết tiếng Việt mình có tìm được và cũng từ những link này ra thôi nhưng mà chất lượng bài dịch không tốt lắm, nên mình nghĩ là mình tự làm còn hơn. haha 😀 Mặc dù mình dịch thì cũng lủng củng thôi, nhưng mà mình sẽ hiểu ý hơn (chỉ sợ sai :v) . Hi vọng nhận được sự góp ý của các bạn! 😀

Tham khảo:

https://www.softwaretestingclass.com/difference-between-adhoc-testing-and-exploratory-testing

https://www.guru99.com/adhoc-testing.html

https://www.guru99.com/exploratory-testing.html

 

Smoke testing và Sanity testing là cái gì vậy?

Làm gì cũng vậy, để có tay nghề tốt, bên cạnh việc thực hành, làm việc liên tục chúng ta cũng cần phải học hỏi để tiếp thu các kiến thức mới, không ngừng nâng cao tầm kiến thức hơn nữa. Nâng cao chất lượng rồi thì cũng cần nâng cả số lượng nữa. Điều này có nghĩa là làm tốt rồi cần làm nhanh nữa :)) Lý thuyết vẫn được mọi người nói là thế.

Tất nhiên là như thế rồi, cái đó ai chẳng biết, nhưng bên cạnh đó mình cũng rất để ý đến những kiến thức cơ bản. Bạn khẳng định bạn làm cái này rất tốt, cái kia rất tốt, có nhiều kinh nghiệm abc này nọ, nhưng mà đến khi phỏng vấn họ hỏi bạn mấy kiến thức cơ bản, bạn lại cứ ú ớ không giải thích được, giải thích được nhưng mà lại lộn chỗ này xộn chỗ kia thì họ đếch tin vào mấy dòng quảng cáo trong CV của bạn nữa đâu Hehe.

Read More »

Cơ bản về Embedded và ứng dụng

Mình đã muốn viết về chủ đề này khá lâu rồi, vì công việc hiện tại của mình đang liên quan đến mảng này. Thực ra mảng embedded (nhúng) này nó cũng khá là rộng, và mình thì cũng mới biết và làm việc với một phần nhỏ liên quan đến nó thôi. Liên quan đến các ứng dụng web, hay di động thì mọi người chắc là ai cũng quen thuộc rồi. Các bài viết chia sẻ, kiến thức cũng rất nhiều. Nhưng về kiểm thử phần mềm liên quan đến embedded thì lại chưa nhiều lắm, nó khá là đặc thù và theo quan sát cộng với tầm hiểu biết hạn hẹp của mình thì không nhiều công ty làm chuyên sâu cái này, mà công ty nào làm về mảng này thì hầu như các công ty đó phải có tiềm lực khá là mạnh.

Read More »

Các trường hợp kiểm thử OTP

Quay trở lại với chuỗi bài “How to” – làm như thế nào,  bên cạnh các bài viết liên quan đến Selenium và những thứ linh tinh trong đời sống thường ngày của mình, mình bổ sung chuỗi bài viết này để luyện tập các kỹ năng của bản thân liên quan đến chuyên môn kiểm thử, rèn luyện lối tư duy, dịch và diễn giải cho dễ hiểu nhất từ các bài toán cụ thể trong thực tế.

Những bài toán thực tế – có thể là bạn sẽ gặp rất nhiều nhưng như mình đã nói đâu đó trong các bài viết trước đây, gặp nhiều thậm chí cảm thấy rất quen thuộc, tuy nhiên nếu chỉ nghĩ mà không ghi lại hoặc lưu trữ đâu đó thì trước sau gì cũng bị gió thổi bay, không thì cũng tự bốc hơi mà thôi, chưa kể đến việc thiếu sót mà trong suy nghĩ bạn khó có thể nhận ra. Rồi kể cả việc có kiến thức kỹ năng, nhưng không được luyện tập nó cũng sẽ tự mai một đi.

HYUh

Read More »

Nóng như thế này, thì làm sao phải…

Mấy hôm nay thời tiết thất thường, mưa, nắng, giông, gió… oi bức khó chịu, làm cho con người cũng cảm thấy khó chịu như thời tiết. Cảm giác vừa mới tắm xong nhưng mà vừa khô đã thấy dính dính nháp nháp người rồi -.- không lẽ lại vào tắm lại :v

Mặc dù vậy thì việc làm vẫn phải làm thôi, thời tiết mặc thời tiết chứ. Mình còn thấy vui vui vì chiều tối cuối tuần mà mưa thì sẽ được bơi bể trong nhà. Chẳng là bọn mình đã kịp mua vé tháng cho 30 buổi bơi bể ngoài trời, hôm nào mưa thì sẽ dùng được vé ngoài trời cho bể trong nhà. Mà bể trong nhà thì nước trong veo – cảm giác sạch sẽ mà lại ít người, không sợ va vào người bơi ngược chiều, mỗi tội nó sâu hơn bể ngoài trời, làm mình thỉnh thoảng run run khi đến đoạn sâu :v

Kết quả hình ảnh cho bơi

Read More »

Xử lý Authentication Popup Window sử dụng Selenium WebDriver

Bạn có thể gặp Authentication popup này khi thực hiện truy cập vào một trang ứng dụng hay địa chỉ nào đó, ở đây bạn cần phải nhập tên đăng nhập và mật khẩu đúng để có thể thực hiện tiếp các thao tác, tác vụ tiếp theo trên trang đó. Loại popup này không phải là popup thông thường được sinh ra từ java-script của ứng dụng đó, mà là một loại hộp thoại của trình duyệt, do đó mà Selenium không thể thực hiện với cách mà chúng ta vẫn làm là sử dụng sendKey() được.

Auth_popup_1

Read More »