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”

JavaScript : Compare two arrays

Conditions :

  • You have a arrays by structure with following :

array1 : [

{“Name” : “John”, “Age”: “24”},

{“Name”: “Kata”, “Age”: “25}

]

  • You have another arrays by structure with following:

array1 : [

{“Name”: “Kata”, “Age”: “25}

{“Name” : “John”, “Age”: “24”},

]

Expected : You want to compare equals 2 this arrays

Solution : You should have a flag to check equals or not.

var checkEquals = function compareEquals(array1, array2){

var flag = false;

for(var i = 0; i < array1.length; i++){

for(var j = 0; j < array2.length; j++){

if (array1[j].Name.toUpperCase() === array2[i].Name.toUpperCase()) {
flag = true; break;
} else {  flag = false;}}

if (flag === false) return true;}

return false;

}

ExtJS : Ajax asynchronous vs synchronous request

Ajax is used for get data to client side. It’s special helpful in case get data at runtime.

The structure:

Ext.Ajax.request({
    url: '/controller/GetData',
    params: {
        id: 1
    },
    timeout: 30000,
    method: GET or POST,
    async: isAsync // Synchronous or Asynchronous
    success: function(response){
        var text = response.responseText;
        var result = Ext.JSON.decode(text);
        // do something here .....
    },
    failure : function(response){
       // do something when wrong ....
   },
})

The issue of myself

On Friday this week, I had a small meeting with the team leader. The main point discussion that is he want me to improve code skills. By his way, He suggests me search and deep learning about CaseWhere project, that’s a project which we are doing. And understanding the main concepts it working.

The issue when I recognise is up 4 years of university to now, I don’t try my best and seriously to do anything about my jobs. Whatever I do, I always finish it to get the high score and prove my friend that I am a good man or a superstar.

But, if I still do this, I can’t develop my career. I recognised that up to now, I had a scare in my mind. The scare maybe begins when I was young. I always wanted to make parents fun and proud of me. So, I often created pressure for myself do well everything.

The answer for that issue is I need to find a right motivate and the good feeling about jobs. Because, when I do this, I will have a funny to overcome the scare in head and learn anything to improve my skills

And last, the sentences in a film that I like:

Follow excellence…Success will chase you

The things make me thinking

Have a hard word day.!

My finger so tired when I code all of the day. But I feel so good because I love my job day by day.

Today, I have learned the lesson “Any” in LINQ. A.Thien always teaches knowledge for me and recommend me should curious everything. I feel ashamed when heard that, but it makes me serious look myself.

The thing makes me thinking

“Am I have invest all of my power for improve code?”