Pairwise Technique

Bạn được giao test cho 1 chức năng hiển thi text or link của 1 website. Những text hay link đó được set up trong 1 trang configuration và có logic như sau:

– Type: Là 1 combobox gồm 2 giá trị: Link hay Text

– Level: Là 1 combobox gồm 2 giá trị: General hay Level. Nếu bạn chọn là General thì text box bên trái gồm Level A và Level B sẽ bị ẩn đi, bạn chỉ có thể nhập trong text box General. Ngược lại, khi chọn Level thì textbox General bị ẩn đi và 2 text box kia được nhập bình thường.

App1

Website có 200 link và 150 text, do vậy sẽ có 350 vị trí để chúng hiển thị trên website. Với mỗi text hoặc link thì bạn có thể set up nó hiển thi chung cho tất cả level (General) hoặc bạn có thể tùy chỉnh cho mỗi level theo link hoặc text mong muốn. Là 1 tester bạn hãy test và đảm bảo những link và text hiển thị chính xác trên website.

Theo bài toán trên, để đảm bảo việc testing cho chức năng đó hoạt động tốt thì ta sẽ phải test khoảng 350 trường hợp. Tuy nhiên, trong thực tế, chúng ta sẽ không có đủ thời gian để có thể kiểm tra được tất cả các trường hợp. Do vậy, để có thể tìm ra được nhiều nhất những lỗi có thể xảy ra trong 1 điều kiện cho phép về thời gian và chi phí thì ta phải tạo ra được một bộ test case hiệu quả nhất. Pairwise testing là một trong những kỹ thuật để giúp cắt giảm số lượng test case cần test và tăng tính hiệu quả cho những test case mà mình muốn kiểm tra.

Quay trở lại bài toán trên, có 2 vấn đề mình cần test cho chức năng này:

  1. Những setting trên configuration tool này có thể tạo ra được những link hay text thõa mản yêu cầu của website
  2. Sau khi chúng được tạo ra từ configuration thì 350 cái này có được hiển thị chính xác trên website hay không.

All singles

Để giải quyết vấn đề số 1 thì trong phương pháp Pairwise có 1 approach là All singles. Kỹ thuật này có nguyên tắc là mỗi giá trị mà bạn quan tâm (bạn nghĩ nó quan trọng) của 1 biến sẽ được bạn ưu tiên để test và đặt trong test case trước.

Với đề bài trên thì ta thấy mỗi link hay text sẽ được quyết đinh theo Type và Level. Với biến Level sẽ có 3 vùng giá trị: General, Level A, Level B. Với Type thì sẽ có 2 vùng giá trị đó là Link hoặc Text.

Do vậy tổng số khả năng có thể xảy ra bằng 3*2 = 6 khả năng.

Tuy nhiên, với việc áp dụng kỹ thuật All Singles, ta sẽ chỉ cần 3 test cases. Chúng sẽ được áp dụng như sau:

  1. Sắp xếp thứ tự các biến theo thứ tự giảm dần số giá trị: Ở đây thứ tự sẽ là Level (3) -> Type (2)
  2. Đặt các giá trị cho biến Level ở cột đầu tiên
STT Level Type
1 General  
2 Level A  
3 Level B  
  1. Với các giá trị ở biến Type, bạn sẽ có 2 giá trị là Link hay Text. Bạn sẽ sắp xếp các giá trị này tương ứng với các giá trị ở cột Level nhưng với thứ tự làm sao mà bạn nghĩ đó là những combine input tạo ra những test case mà khách hàng thường xài và có độ bao phủ nhiều nhất. Qua kinh nghiệm của mình với hệ thống, mình đã chọn cách sắp xếp như sau:
STT Level Type
1 General Text
2 Level A Link
3 Level B Link

Lợi ích của All singles là nó đã cắt giảm được số lượng TH cần phải kiểm tra từ 6 xuống còn 3. Nhưng một vấn đề của phương pháp này là có thể bị missed những combine input quan trọng trong thực tế. Ví dụ, trong thực tế rất nhiều người dùng Level là General và Type là Link, nhưng trong bảng trên thì mình đã thiếu kiểm tra TH đó. Do vậy, để khắc phục điều này thì ta sẽ thêm những TH đặc biệt đó vào trong bộ TCs.

Tuy nhiên, quay lại bài toán thực tế này, do bạn cần phải tạo 350 Link và Tex theo configuration tool này để hiển thị lên website. Cho nên, việc testing toàn bộ 6 khả năng là điều nên làm vì dù gì bạn cũng phải tạo 350 cái 😊, và vì lợi ích của việc covergare 100% sẽ đảm bảo bạn không bị thiếu bất kể khả năng nào.

All pairs

Quay lại vấn đề thứ 2, mình cần test là đảm bảo 350 cái configuration này hoạt động chính xác trên website. Tuy nhiên, chẳng lẻ mình sẽ đi test hết cả 350 cái. Câu hỏi là làm sao cắt giảm số lượng test case cần test? Trong Pairwise thì có 1 approach là All Pairs. Nguyên tắc của approach này là mỗi giá trị của mỗi biến được phối với mỗi giá trị của những biến còn lại trong ít nhất một test case

350 configuration này sẽ được hiển thị ở 350 vị trí khác nhau. Áp dụng ‘Domain Partition’ta chọn được 10 vùng (Areas) mà 350 cái này tập trung nhiều giá trị có value nhất. Và để demo những cái hay của approach All pairs này, mình sẽ chỉ lấy 1 tập giá trị gồm 3 vùng (Area 1, Area 2, Area 3) làm ví dụ.

Tổng số khả năng có thể xảy ra Areas (3) * Level (3) * Type (2) = 18 khả năng

Đây là các bước tiến hành khi áp dụng approach này

  1. Sắp xếp các biến theo thứ tự giảm dần số giá trị của từng biến. Các cột sẽ có thứ tự sau: Areas, Level, Type
  2. Tính số dòng của bảng phối bằng cách lấy số giá trị của biến 1 * số giá trị của biến 2. Số dòng = Areas (3) * Level (3) = 9
  3. Trong cột đầu tiên, nhập từng giá tri của biến Areas theo số giá trị của biến Level, lưu ý để 1 dòng trống sau mỗi vòng. Ví dụ, nếu giá trị 1 của biến 1 là Area 1 và bộ giá trị của biến 2 là General, Level A, Level B thì đợt đầu sẽ 4 dòng, và trong cột đầu tiên sẽ là Area 1, Area 1, Area 1, 1 dòng trống.
  4. Trong cột thứ 2, liệt kê tuần tự các giá trị của biến 2. Ví dụ: vòng đầu tiên của cột thứ 2 sẽ là General, Level A, Level B
Areas (1,2,3) Level (General, Level A, Level B) Type (Text, Link)
1 General  
1 Level A  
1 Lvel B  
     
2 General  
2 Level A  
2 Lvel B  
     
3 General  
3 Level A  
3 Lvel B  
     
  1. Trong cột thứ 3, lấy từng giá trị của biến 3 (Type) phối với các tập giá trị của biến 1, khi đã phủ hết các trường hợp, ta tiếp tục phối với tập giá trị của biến 2
    1. Trong vòng đầu khi điền giá trị của biến 3, tôi nhập giá trị cho vòng đầu lần lượt là Text, Link, Text
Areas (1,2,3) Level (General, Level A, Level B) Type (Text, Link)
1 General Text
1 Level A Link
1 Lvel B Text
     
2 General  
2 Level A  
2 Lvel B  
     
3 General  
3 Level A  
3 Lvel B  
     

2. Tại vòng thứ 2, bộ giá trị sẽ là Link, Text, Link

Areas (1,2,3) Level (General, Level A, Level B) Type (Text, Link)
1 General Text
1 Level A Link
1 Lvel B Text
     
2 General Link
2 Level A Text
2 Lvel B Link
     
3 General  
3 Level A  
3 Lvel B  
     

Câu hỏi đặt ra là tại sao bộ giá trị không phải là Text, Link, Text?

Hãy quay lại dòng đầu tiên của cột 2 và cột 3: General đã phối với Text

Nếu như tại dòng 5, nếu ta chọn là Text nữa thì lúc này ta sẽ bị trùng với dòng đầu tiên. Do vậy, nếu chọn Link thì không những không bị trùng mà ta còn cover thêm 1 TH nữa. Ở đây là General-Link

3. Từ vòng 3 bạn có thể đặt kiểu sắp xếp nào cũng được. Lí do vì dù kiểu nào thì cũng sẽ tạo 1 bộ phối hợp lệ cả.

Như vậy, với cách phối này bạn đã có 1 bộ gồm 9 test case mà các giá trị của từng biến đã phối được với nhau.

Areas (1,2,3) Level (General, Level A, Level B) Type (Text, Link)
1 General Text
1 Level A Link
1 Lvel B Text
     
2 General Link
2 Level A Text
2 Lvel B Link
     
3 General Text
3 Level A Link
3 Lvel B Text
     

Giả sử ta có thêm một biến nữa thì sao?
Lúc này ta chỉ cần phối giữa cột Level-Variable 4 và sau đó tới Type-Variable 4. Bảng phối vẫn vừa vặn cho tất cả trường hợp như sau

Areas (1,2,3) Level (General, Level A, Level B) Type (Text, Link) Variable 4 (X, Y)
1 General Text X
1 Level A Link Y
1 Lvel B Text X
       
2 General Link Y
2 Level A Text X
2 Lvel B Link Y
       
3 General Text Y
3 Level A Link X
3 Lvel B Text Y
       

Tuy nhiên, nếu ta tiếp tục có thêm biến Variable 5 thì bảng đó sẽ không còn phù hợp nữa.

Areas (1,2,3) Level (General, Level A, Level B) Type (Text, Link) Variable 4 (X, Y) Variable 5(M, N)

 

1 General Text X M
1 Level A Link Y N
1 Lvel B Text X M
         
2 General Link Y N
2 Level A Text X M
2 Lvel B Link Y N
         
3 General Text Y N
3 Level A Link X M
3 Lvel B Text Y N
         

Có thể thấy theo bảng này, cột Level và Type các giá trị đã được phối đầy đủ với các biến của Variable 5. Tuy nhiên, có 1 chút không đúng ở cột Variable 4. X chỉ được phối với M, tương tự cho Y với N. Để khắc phục điều này ta sẽ thêm 2 test case khác ở dưới những dòng trống. Một bảng hoàn chỉnh sẽ có giá trị như sau:

Areas (1,2,3) Level (General, Level A, Level B) Type (Text, Link) Variable 4 (X, Y) Variable 5(M, N)

 

1 General Text X M
1 Level A Link Y N
1 Lvel B Text X M
      X N
2 General Link Y N
2 Level A Text X M
2 Lvel B Link Y N
      Y M
3 General Text Y N
3 Level A Link X M
3 Lvel B Text Y N

Khi bạn muốn test tất cả các trường hợp có thể xảy ra, chúng sẽ là 3*3*2*2*2=72 trường hợp. Nhưng khi áp dụng all-pairs bạn đã cắt giảm từ 72 xuống còn 11.

Tuy nhiên, khi áp dụng phương pháp này, bạn hãy lưu ý trong thực tế có những combination khác và sẽ được khách hàng sử dụng thường xuyên hơn những combination trên bảng phối trên. Do vậy, cách tốt nhất là có thể thêm một số trường hợp đó vô trong bộ test case của mình. Trong kinh nghiệm thực tê của mình thì có thể thêm từ 5-10 test case nữa cần kiểm tra. Do đó, tổng số test case có thể có từ 15-20. Tuy nhiên, nó vẫn là hiệu quả hơn khi bạn phải test 72 trường hợp phải không nào.

Tester nên nói gì trong Daily Standup Meeting

Hey, mọi người trong chúng ta đều chắc hẳn đã tham gia standup meeting. Một buổi meeting sẽ kéo dài khoảng 15 phút. Vậy có ai cảm thấy chán vì không biết nói gì hay là cảm thấy áp lực và lo lắng nếu như sếp bất chợt hỏi đến mình. Thật ra, mình cũng vậy và mình cũng có những câu hỏi đó cho bản thân. Thế nên, vào một buổi sáng thứ 7 đẹp trời, mình quyết định google để tìm ra cách khắc phục cho vấn đề này. Nào, hãy đi xem mình tìm ra được thứ gì có ích cho bạn không nhé. ^^

Điều đầu tiên thì hãy tìm hiểu Daily Standup Meeting là gì và nó được sinh ra vì lí do gì?

  1. Daily standup meeting là gì?

Daily standup meeting là một meeting mà người tham dự phải đứng và được kéo dài trong thời gian tối đa 15 phút. Đối tượng tham gia là tất cả các thành viên trong team.

  1. Vậy nó sinh ra vì mục đích gì?

  • Chia sẻ những khó khăn đang ngăn cản công việc của mình

Trong công việc của bạn hằng ngày, bạn sẽ có những yêu cầu từ phía khách hàng hoặc Product Owner, và khi thực hiện những yêu cầu đó, sẽ có những khó khăn ngăn cản công việc của bạn lại và bạn không thể làm tiếp nếu không có sự giúp đỡ của những người khác. Đó là lí do vì sao có sự xuất hiện của Daily Meeting. Nó sẽ là nơi bạn nêu những trở ngại bạn đang đối mặt và tìm sự giúp đỡ của những thành viên khác trong team. Ví dụ như trong trường hơp của mình mới đây, mình có 1 yêu cầu phải tạo data test khoảng 2100 items. Nếu mình cắm đầu giải quyết thì chắc chắn tốn rất nhiều time và công sức, nhưng khi mình nêu vấn đề này ra trước team thì mọi người đã discuss và cho mình ít nhất 2 giải pháp.

  • Kết quả sau một meeting là mọi người rời khỏi với một năng lượng tích cực và tìm ra giải pháp cho những vấn đề đó

Quay trở lại vấn đề ban đầu khi tại sao bạn lại ngán và chán khi tham gia meeting. Mình nghĩ vì sau khi kết thúc meeting, bạn không biết mình sẽ làm gì tiếp theo, và rắc rối hiện tại của mình thì ai giải quyết đây? Do vậy, trong buổi meeting, bạn phải dũng cảm nói ra vấn đề của mình và sẵn sàng để người khác có thể làm tiếp cho bạn công việc đó. Mục tiêu là các thành viên khác trong team biết những khó khăn, từ đó giúp đỡ và điều chỉnh plan sao cho phù hợp với mục tiêu cuối cùng của cả đội.

Vậy có những cách nào để trình bày những vấn đề của mình trong buổi meeting

  1. Xác định và mô tả vấn đề ngắn gọn, dễ hiểu

Một buổi meeting chỉ kéo dài 15 phút và có rất nhiều người tham gia gồm manager, team leader, developer, tester, … Do đó, nếu bạn mô tả vấn đề dài dòng, tràng giang đại hải thì sau khi nói xong, người nge không những không hiểu bạn đang nói gì mà bạn còn không tìm ra được giải pháp cho bạn nữa. Không những vậy, bạn đang gián tiếp làm lãng phí thời gian của những người khác. Cho nên, để có thể trình bày tốt, bạn nên chuẩn bị trước cho buổi meeting đó. Sau đây là một số tips mà bạn có thể áp dụng ngay:

  • Chuẩn bi những thứ cần nói trước 15 phút
  • Liệt kê những thứ đó thành những gạch đầu dòng ra một tờ giấy
  • Dựa trên những gạch đầu dòng đó, sắp xếp độ ưu tiên theo thứ tự: Urgen <-Critical <- Normal <- Small

Ví dụ dưới đây là 3 thứ mình sẽ nói trong buổi meeting và sắp xếp thứ tự nói từ trên xuống dưới:

  • Hiện tại để verify con critical bug này thì em cần fix con bug small này trước vì con small này đang ngăn cản việc test cho con critical kia.
  • Hôm qua, như discuss thì hiện tai em đã hoàn thành test cho con user story này rồi, có ai có ý thêm gì cho việc testing không? Nếu không có thì em có thể move nó qua Acceptance Test được không?
  • Con critical bug trên Production em đã hiểu vấn đề nó gặp phải, tuy nhiên, em cần viết một cái script query xuống DB, bên dev có ai có thể giúp em được?
  1. Nêu vấn đề, đối tượng có thể giúp bạn giải quyết vấn đề sau đó chứ không nên đi quá xa và chi tiết

Standup meeting không phải là nơi đưa ra quyết định và giải quyết vấn đề. Nó chỉ là nơi vấn đề được nêu ra và những người liên quan tới vấn đề đó. Đó là lí do vì sao một daily-meeting chỉ kéo dài 15 phút. Do vậy, khi gặp phải những vấn đề có độ phức tạp cao hay phải trình bày trong thời gian dài, thì trong daily meeting bạn nên trình bày sơ lược, giới hạn đối tượng liên quan và sắp xếp một cuộc meeting khác ngay sau đó.

Ví dụ

  • Cho regression test vào ngày mai như plan, bên QA team cần xác định những test case nào sẽ chạy cho đợt build săp tới. Do vậy, sau daily standup meeting thì QA team sẽ có buổi meeting cho vấn đề này
  • Hiện trên con critical bug này, Dev đang fix. Tuy nhiên, vì nó ảnh hưởng nhiều chức năng nên QA sẽ có meeting riêng với DEV để đưa ra những case có thể bị ảnh hưởng

Tóm lại, để bạn cảm thấy việc tham dự một daily standup meeting trở nên vui vẻ và hiệu quả thì hãy biến nó thành nơi có lợi cho mình, giúp mình có thể chia sẽ những khó khăn và tìm được sự giúp đỡ của những đồng nghiệp trong team. Và để làm được nó thì hãy chuẩn bị trước thứ mà mình muốn nói, đối tượng mà mình muốn tìm kiếm sự giúp đỡ và hãy lưu ý Daily Standup Meeting chỉ có kéo dài 15 phút, cho nên hãy sử dụng nó làm sao thật hữu ích cho bản thân mình.

Cách tìm ra lời giải thích tốt nhất cho 1 con bug

Hey, trong số chúng ta – những người tester, khi tìm ra một điều bất thường của softwate thì thường tạo ra bug ngay lập tức. Vậy có ai đã bị trường hợp Dev kêu lại và hỏi 1 câu rằng:

Anh không nghĩ nó là bug, anh không bị trong một số trường hợp a, b, c này?

Mình đã gặp trường hợp này rất nhiều lần và rất lúng túng để tìm ra 1 lời giải thích tốt nhất. Lí do mình nghĩ đơn giản là vì mình chưa thực sự tìm ra được root cause của vấn đề và viết được một mô tả chính xác lỗi mà con bug đó gặp phải.

Vậy thì giải pháp là gì?

Trong cuốn sách Lesson Learn in Software Testing (James bach), ông ta đề xuất 1 phương pháp mà mình cảm thấy hay để tìm ra được 1 good explantion. Đó là phương pháp ‘Abductive inference’ – Mình không biết phải dịch tiếng viêt thế nào 😛 (dịch từ google nó hơi gớm 😊)

Đại khái ý của phương pháp này gồm những ý sau:

  1. Thu thập data
  2. Thu thập những data quan trọng
  3. Tiếp tục thu thập data, nhưng data đó phải đáng tin
  4. Hiểu được cause and effect cho từng loại data đó
  5. Tìm được 1 best explantion cho mỗi data
  6. Thu thập những data có những giải thích khác nhau
  7. Trong số những lời giải thích, tìm cách phản biện và loại bỏ những giải thích mà không logic đi
  8. Đưa ra 1 lời giải thích hợp lí nhất nhưng lưu ý nó phải đại diện cho những data quan trọng mà bạn thu thập được

Với phương pháp này bản thân mình thấy ưu điểm của nó bạn sẽ nhìn 1 vấn đề trên nhiều góc nhìn khác nhau, đồng thời có sự suy luận, phân tích cho những phỏng đoán để tìm ra một good explantion. Tuy nhiên, nhược điểm của cái này thì mất khá nhiều thời gian cho thu thập data và investigation. Nhưng nhìn chung, mình cảm nhận nó hay và sẽ follow nó ^^.

Big salary is much more important than job satisfaction

As the society grows, money is becoming more important nowadays. Having money may not make you happy, but having no money will make you miserable. Thus, most people believe that the wage is the main factor of making the decision for a career. However, in my opinion, I strongly believe job satisfaction is more important than big salary.

Firstly, I think life is too short to be wasted in only earning money without any satisfaction. For example, you work average 8 hours per day. It also means the time working accounts for one third in your life. If you just work for money then you cannot feel happy. However, job satisfaction will keep you happy every minute. For instance, researchers spent their life in research since they are passionate and feel happy about what they do. Their work’s purpose is to become famous, not to become rich.

Secondly, in my point of view, job satisfaction will help you enjoy life. Enjoyment doesn’t mean that you have a big bank balance; but it means you are satisfied with your current work. If you are not satisfied then in fact you are wasting your talent. Maybe when starting, you won’t earn much, but at least you are happy with it. It will be beneficial for you in a long term, particularly, for your own career path.

To sum up, balancing between salary and job satisfaction is better. However, I strongly believe that job satisfaction is more important because it will help you enjoy life and promote your career path.

Tại sao Testing là cần thiết? Testing để làm gì?

  1. Tại sao Testing là cần thiết? Testing để làm gì?

Khi mình đưa ra câu hỏi này tới một số người thì câu trả lời sẽ là có và cần thiết. Và họ đưa ra một số lí do như:

  • Nếu không test thì ai là người đảm bảo những yêu cầu của khách hàng chạy đúng.
  • Lỡ những chức năng đó implement sai hoàn toàn so với yêu cầu từ ban đầu thì sao.

Nhưng theo suy nghĩ của mình thì một câu hỏi đúng hơn là:

Ảnh hưởng như thế nào khi không có Testing?

Một ví dụ là sự cố Note 7 – Vì một lỗi dễ gây cháy do pin mà SamSung phải thu hồi toàn bộ sản phẩm và cho khai tử dòng điện thoại này.

2017-08-31_2132

Hay như gần đây là gần đây là mã độc WannaCry, nó đã khai thác một lỗ hổng trên phần mềm Windows và từ đó chiếm quyền điều khiển máy tính và dữ liệu của user. Hậu quả là các bệnh viện ở Anh không thể truy cập hồ sơ bệnh án, hay như Đức, nó đã tấn công và gây ảnh hưởng tới hệ thống đường sắt.

2017-08-31_2133

Trong 1 phạm vi nhỏ hơn là trong quá trình sản xuất phần mềm thì chi phí một lỗi khi phát hiện trong giai đoạn đầu là Tìm hiểu Requirement sẽ chỉ bằng 1/100 lần chi phí khi phát hiện trên môi trường Production.

2017-08-31_2135

Những ví dụ trên chứng tỏ, vai trò của testing rất quan trọng. Nó không chỉ tiết kiệm tiền thậm chí cả mạng sống.

2. Vậy vai trò của testing là gì?

Có nhiều khái niệm về vai trò cùa Testing, nhưng theo mình nghĩ thì Testing phải đảm bảo những yếu tố sau:

  • Tìm ra những lỗi của phần mềm và đảm bảo những lỗi này phải được fixed trước khi Release cho khách hàng.

Với yếu tố này thì cần chú ý rằng những bug đó phải được fixed. Khi bạn là 1 tester, bạn tự hào mình có thể tìm ra được 100 bugs về 1 chức năng nào đó, nhưng tới ngày Release cho khách hàng, 100 bugs đó vẫn chưa được fix thì chất lượng của phần mềm có cải thiện không?

Câu trả lời là không! Nó không hề cải thiện bất kì chút nào như trước khi bạn phát hiện ra những bug đó.

Do vậy, chất lượng của phần mềm chỉ được cải thiện khi khách hàng dùng phần mềm và không tìm ra được những lỗi mà tester đã tìm ra.

  • Gia tăng độ tự tin cho phần mềm.

Sau quá trình Testing kết thúc, nó sẽ đảm bảo những chức năng hoạt động như requirements và đồng thời sẽ đảm bảo hạn chế những tình huống bất ngờ như Crash màn hình hoặc quăng exception tới user chẳng hạn. Qua đó, làm tăng độ tự tin cho phần mềm.

  • Cung cấp thông tin cho những bên liên quan tới phần mềm (stackholder), từ đó có thể đưa ra quyết định cho phần mềm trong những tình huống cụ thể.

Trong quá trình sản xuất phần mềm, tester chỉ là mắt xích trong quá trình đó. Có rất nhiều bên liên quan khác nhau như Development Team, BA hoặc Khách hàng. Cũng như vậy, có nhiều thời điểm cần đưa ra quyết định cho phần mềm, chẳng hạn như khi nào Release lên customer testing environemnt, khi nào lên Production. Do vậy, những thông tin mà tester cung cấp sau khi quá trình testing kết thúc, sẽ giúp họ đưa ra những quyết định đúng đắn.

  • Ngăn ngừa lỗi cho phần mềm.

Cần phân biệt khái niệm Ngăn ngừa (Prevent) với Tránh (Avoid). Trong quá trình testing, bạn không phải là người viết ra yêu cầu, bạn chỉ là người test cho những yêu cầu đó. Cho nên, xác xuất bạn bị hiểu lầm là điều có thể xảy ra. Thứ hai, có khi bạn test trên những môi trường không giống khách hàng (Vì họ chạy thực tế, có rất nhiều yếu tố liên quan như: phần mềm tương tác, network, cấu hình máy, …). Do vậy quá trình Testing chỉ đảm bảo ngăn ngừa lỗi chứ không thể tránh chúng được.

3. Testing tới khi nào là đủ?

Giả sử bạn được giao test cho một fearture mới nào đó. Câu hỏi đặt ra là bạn sẽ test đến khi nào? Tới khi nào bạn nghĩ cái feature đó đã đủ chất lượng để giao cho khách hàng?Câu trả lời theo quan điểm của mình là nó phải thỏa mãn 2 thứ.

Trước tiên phải đảm bào từng requirement mà khác hàng đề cập phải chạy được và hoạt động tốt. Giả sử trong 1 thời gian cho phép, thì đầu tiên phải đảm bảo những case positive hoạt động tốt.

Thứ hai nó phải thõa mãn một số tiêu chí để chúng ta có thể đo lường được. Ví dụ như số lượng bug tìm được cho cái Feature đó đã được fixed bao nhiêu phần trăm hay tổng thời gian Testing cho cái feature đó mất khoảng bao lâu rồi.

Những quan điểm trên của mình về sự cần thiết của Testing là những ý kiến chủ quan. Mọi người có thể bàn bạc và thảo luận bằng cách gửi ý kiến ở phía dưới nhé.

PS: Một phần mềm không có tester thì có được không? 😉

Decision Table Technique

Hôm nay mình sẽ nói tiếp tới 1 kỹ thuật thường hay dùng trong Black Box Testing đó là Decision Table Technique. Kỹ thuật này giúp xác định những kịch bản test cho những Business Logic phức tạp.

  1. Mình sẽ bắt đầu bằng 1 ví dụ như sau

Bạn được giao test cho 1 application tính toán discount cho khách hàng nhân dịch khuyến mãi. Điều kiện khuyến mãi như sau:

  • Nếu là 1 khách hàng (KH) mới thì được giảm 10%
  • Nếu là khách hàng hiện thời thì được giảm 15%

Câu hỏi đặt ra là với 2 điều kiện này thì bạn sẽ cần phải test bao nhiêu trường hợp để đảm bảo logic hoạt động đúng như requirement, không bị miss bất kì khả năng nào?

Decision Table đề xuất 1 cách đó là lập bảng khả năng. Nó sẽ trông như thế này 🙂

Conditions    Rule 1 Rule 2 Rule 3 Rule 4
KH mới (15%)
KH hiện thời (10%)

Như các bạn thấy, với 2 điều kiện thì có tất cả 4 khả năng có thể xảy ra. Và với mỗi  khả năng sẽ có 2 giá trị True or False. Ta đánh nó tương ứng vào các ô.

Conditions    Rule 1 Rule 2 Rule 3 Rule 4
KH mới (15%) T T F F
KH hiện thời (10%) T F T F

Một qui tắc để tính được số trường hợp khả năng là 2n. Với n là số điều kiện.

Từ bảng khả năng, ta có thể xác định giá trị Output tương ứng với từng trường hợp như bảng dưới đây.

Conditions    Rule 1 Rule 2 Rule 3 Rule 4
KH mới (15%) T T F F
KH hiện thời (10%) T F T F
Actions/Outcomes
Discount 15% Y Y
Discount 10% Y Y

Hãy phân tích 1 chút về bảng trên. Với Rule 2, khi KH chỉ chọn option là KH mới thì Output sẽ là được discount 15%. Điều đó cũng tương đương khi KH chỉ chọn option là KH hiện thời. Nhưng nếu KH chọn cả 2 option (Rule 1) hoặc không chọn option nào (Rule 4) thì sao? Những mô tả này hoàn toàn không được đề cập khi ta đọc yêu cầu từ ban đầu.

 Do vậy bảng decision cho phép ta nhìn thấy những những thiếu sót và mơ hồ trong mô tả.

Để khắc phục trường hợp trên, ta có thể đặt câu hỏi với ngưới viết ra requirment để hỏi họ xem sẽ quyết định như thế nào trong những trường hợp mô tả chưa rõ như thế.

Giả sử nếu họ muốn hiện một thông báo tới người dùng trong 2 trường hợp đó thì ta sẽ có 1 bảng decision như sau:

Conditions    Rule 1 Rule 2 Rule 3 Rule 4
KH mới (15%) T T F F
KH hiện thời (10%) T F T F
Actions/Outcomes
Result Error message 15% 10% Error message

Như vậy với kỹ thuật này ta có thể đi qua xét tất cả các khả năng có thể xảy ra bằng cách phối các điều kiện lại với nhau và phát hiện thiếu sót từ sớm.

2. Bài học kinh nghiệm

Ví dụ mình đưa ra chỉ có 2 điều kiện nên việc lập bảng có vẻ dễ nhưng bạn hãy tưởng tượng trong thực tế có những requiment có từ 9 hoặc 10 điều kiện thì sao? Nếu áp dụng 1 cách cứng nhắc thì bạn sẽ có 29 và 210 khả năng phải xét. Nó sẽ không khả thi và bất hợp lí khi phải xét hết tất cả khả năng như vậy, đăc biệt khi bạn chỉ có 1 thời gian cho phép.

Một số lưu ý khi lập bảng:

  • Đừng giả định phải phối hết tất cả các điều kiện.
  • Chỉ chọn lọc và ưu tiên lấy nhưng điều kiện quan trong nhất để phối.
  • Xem xét những thứ cần test hoặc không cần test cho từng giai đoạn thời gian khác nhau

Và tùy vào từng trường hợp cụ thể nên áp dụng nhiều kỹ thuật khác để tạo ra một bộ test data hợp lí và vừa đủ.

Black Box Testing

Blog này mình viết ra để note lại những kiến thức mình research về Black Box Testing, cũng như muốn rèn luyện khả năng trình bày. Rất mong các bạn góp ý để mình có thể trao đổi và cũng cố kiến thức với nhau nhé.

Nhân duyên  vì sao mình lại chọn chủ đề này vì bởi mình đã làm tester được 18 tháng. Bỗng một ngày đẹp trời, tự dưng đặt câu hỏi là mình làm về nó nhưng thực sự đã biết nó như thế nào chưa? Câu hỏi đó khiến mình muốn tìm hiểu 1 trong những phương pháp kiểm thử phần mềm phổ biến nhất. Đó là Black Box  Testing.

Nội dung mình muốn trình bày sẽ gồm những phần sau đây:

  1. Nó là gì?
  2. Lợi ích và bất lợi khi dùng phương pháp này
  3. Một số techniques của Black Box Testing (BBT) hay dùng trong dự án thực tế

Nào chúng ta hãy tìm hiểu phần 1, xem nó là cái gì nhé.

  1. Nó là gì?

    1.Definition
    Như hình vẽ trên, bạn nhìn thấy là 1 hộp màu đen, bạn không thể nhìn thấy bên trong là gì, không biết có gì trong đó. Giống như đôi mắt của tester, tuy không thể biết trong nó là gì nhưng dựa vào nó thì có thể tìm ra được lỗi. Nó còn được biết với tên gọi là Behaviour Testing. Vì nó dựa hoàn toàn vào yêu cầu và mô tả chức năng của phần mềm để thực hiện.

  2. Lợi ích và bất lợi khi dùng phương pháp này

    1. Lợi ích

      Vì nó dựa hoàn toàn vào yêu cầu và mô tả chức năng của phần mềm để thực hiện nên nó có những lợi ích như sau:

      • Test được thực hiện từ góc nhìn của user hoặc là tester nên có thể dùng phần mềm khách quan từ quan điểm của 1 end user.
      • Dẫn tới là tránh được sự ngộ nhận hoăc thiếu sót từ developer.
      • Không cần biết ngôn ngữ lập trình hoặc cách mà phần mềm thực hiện như thế nào.
      • Có thể viết test case và test được sớm khi requirement hoàn thiện.
    2. Bất lợi

      Do nó dựa hoàn toàn vào yêu cầu và mô tả chức năng của phần mềm để thực hiện nên nó có những bất lợi như sau:

      • Nếu requirement không rõ ràng thì có thể design test case bị sai hoặc rất khó để design test case.
      • Chỉ có thể test trên 1 số lượng data nên sẽ không cover hết tất cả các trường hợp.
  3. Một số techniques của BBT hay dùng trong dự án thực tế

    1. Boundary Value Analyst (BVA)

      2.BVA
      Technique dựa vào 1 thống kê đó là lỗi (Faults) thường xuất hiện ở những vùng biên của dữ liệu. Do vậy, nếu ta test những giá trị tại vùng này thì có thể tìm ra lỗi. Nói cách khác ta chỉ cần test trên 2 giá trị tại 2 bên biên. Như trong hình bạn có thể thấy có 2 vùng giá trị. Teachnique qui định chỉ cần lấy giá trị chấm bi vàng và chấm bi hồng để làm test data.Một ví dụ khác, bạn có 1 textbox cho phép nhập tuổi của user. Yêu cầu qui định giá trị hợp lệ trong khoảng từ 1 đến 100.
      3.BVA
      Trong ví dụ này, ta có thể thấy ta có 2 biên: Là cận dưới = 1 và cận trên = 100. Do đó ta có 4 giá trị cần kiểm tra đó là:

      Min value -1 0
      Min value 1
      Max value 100
      Max value + 1 101
    2. Equivalence Partitioning (EP)

      Nó giúp cắt giảm 1 số lượng lớn input có khả năng xảy ra thành 1 bộ input data nhỏ nhưng hiệu quả hơn. Nó chia input data thành các class và chỉ lấy 1 giá trị đại diện để test cho mỗi class.  Vì nó giả định nếu 1 cái work đúng thì tất cả giá tri trong cùng lớp đó sẽ work đúng.Lấy ví dụ tương tư như BVA , nhưng với EP ta sẽ chỉ có 3 phân vùng (partition) như sau:
      4.EP
      Do đó ta có 3 giá trị cần kiểm tra đó là:

      Partition Value
      Parition 1 < 1
      Partition 2 1 – 100
      Partition 3 > 100

      Một ví dụ thực tế với dự án mà mình đang work. Đó là bạn có 1 yêu cầu nhập 1 description trên 1 textbox với qui đinh là từ 1 tới không quá 400 kí tự.

      Áp dụng cả 2 techniques ta sẽ có 1 bộ test case như sau:
      6.BVA+EP

Continue reading “Black Box Testing”