Testing and Automation Testing in Software Development

Trong thế giới ngôn ngữ lập trình, hẳn các bạn đã biết và làm quen với những ngôn ngữ như C, C++, C#, VB, Delphi, ASP.NET…! Và cũng có thể các bạn đã từng làm hoặc mới nghe nói đến các tools như: QuickTestProfessional, TestComplete, RanoRex, LoadRunner, hoặc CodedUITesting (Visual Studio 2010 Ultimate version). Các tools đó là gì, chúng làm gì hay liên quan gì đến thế giới lập trình phần mềm?
Trong số dân IT chúng ta hầu như ai cũng đã từng develop hay sở hữu một hoặc vài sản phẩm nhỏ do chính tay chúng ta viết – thật tự hào. Và đối với cá nhân chúng ta, khi bắt tay vào làm phần mềm thì hầu như chỉ quan tâm đến cái mục đích chính của sản phẩm như - nó sẽ được sử dụng như thế nào, có phù hợp với yêu cầu của người dùng hay không, có đẹp mắt hay không…! Chứ chúng ta ít khi quan tâm đến quy trình mà chúng ta viết ra sản phẩm đó. Nhắc đến quy trình có rất nhiều mô hình được áp dụng ngày nay như WaterFall (Mô hình thác nước), Agile (Mô hình băm nhỏ một dự án thành nhiều giai đoạn con)… Nhưng dù áp dụng mô hình nào đi chăng nữa, thì chúng đều phải có các khâu: Requirement->Design->Coding->Testing->Deployment.
Mỗi khâu trong quy trình phát triển phần mềm đều có mức độ quan trọng riêng của nó, và đối với các công ty phần mềm, doanh nghiệp phần mềm, và các công ty phần mềm nước ngoài thì quy trình chính là điều kiện bắt buộc để đảm bảo chất lượng sản phẩm phần mềm trước khi đưa nó vào triển khai sử dụng.
Mục tiêu của bài viết này mình muốn giới thiệu cũng như chia sẻ với các bạn các kiến thức, những kinh nghiệm về Automation Testing – để support chúng ta trong giai đoạn testing cho phần mềm. Dĩ nhiên, rồi dần dần các bạn cũng sẽ phải làm cho một doanh nghiệp phần mềm lớn, hoặc chính các bạn cũng sẽ trở thành ông chủ của một công ty phần mềm trong tương lai. Nên mình hy vọng rằng, hãy có một cái nhìn tích cực hơn về vấn đề Testing và chất lượng của sản phẩm trước khi đưa chúng đến tay End User, chứ không đơn thuần chỉ coding.
Để đi sâu hơn một chút về Testing, mình xin đưa ra vài khái niệm (thường gặp) về Testing trong quá trình làm phần mềm (Thực tế thì mình chưa bao giờ đóng vai trò là một Tester cả)
Những khái niệm về Testing:
Unit Testing: mỗi khi phát triển một module, function… các bạn đều phải thực hiện Unit Test. Đối với các testers, họ sẽ thực hiện việc Unit Test theo các test cases đã viết sẵn như: Login sai 3 lần thì account đó có bị lock hay không? Hoặc Login xong thì redirect tới đúng Page hoặc Window mong muốn hay không v.v. Còn đối với Developer làm Unit Test có vẻ khác một chút, họ phải thực hiện code Unit Test Script (dùng Nunit hoặc Junit tools), mục đích để kiểm tra xem các Functions, Modules thuộc tầng BO hoặc DAO có thực hiện đúng không? Ví dụ: Kiểm tra xem hàm SaveCustomer có save được vào DB hay không, chúng ta phải tạo một object Customer, khởi tạo data ban đầu rồi gọi hàm SaveCustomer trong Unit Test Script và thực hiện việc Assertion (đánh giá, một function của Unit Test) để so sánh giá trị trả về của hàm SaveCustomer (Actual Output) và giá trị bạn tự giả định là Save thành công (Expected Result).
Integration Testing: Việc testing này được thực hiện mỗi khi các modules, functions, các components được tích hợp lại với nhau, và việc testing để đảm bảo xem các modules hoặc các functions đó có thực hiện đúng so với một bản design tổng thể ban đầu chúng ta làm hay không.

Regression Testing (Important for Automation Testing) : Bạn biết rằng, trong suốt giai đoạn phát triển phần mềm bạn thường xuyên phải thay đổi functions, hoặc modules nào đó, để cho phù hợp với yêu cầu thực tế. Hoặc sau khi deliver sản phẩm cho khách hàng, khách hàng yêu cầu chúng ta thay đổi 1 module, hoặc một function…, thì sau khi các bạn change requirements, các bạn phải thực hiện lại việc Testing, và dĩ nhiên nếu làm bằng tay, các bạn sẽ mất rất nhiều công sức và thời gian và có thể còn không chính xác.
Automation Testing và tại sao?
Đặt vấn đề: Các bạn đang làm trong một dự án lớn cho một cty lớn. Dự án của các bạn có khoảng 5 testers. Và vấn đề ở đây là khách hàng yêu cầu các bạn (testers) thực hiện việc testing cho sản phẩm với các data của việc test sẽ do chính khách hàng cung cấp. Khách hàng gửi cho các bạn một file excel với tổng số row data cho việc test là 20.000 rows. (Đây là một ví dụ, nhưng nó thực tế trong chính dự án mình đang làm lại lên tới gấp đôi con số trên – nên các bạn có thể hơi ngạc nhiên vì sao lại nhiều data như vậy).
Yêu cầu của bài toán testing: Với mỗi một row data nhập vào hệ thống (sản phẩm các Developer của chúng ta đang code), hệ thống sẽ tính toán và phải đưa ra một giá trị chính xác với giá trị khách hàng cung cấp. Ở đây, khách hàng cung cấp cho các bạn cả Input Data, Expected Result, việc còn lại bạn sẽ phải lấy Output data trên sản phẩm các bạn đang làm để compare với Expected của khách hàng.
Test case: Chỉ gồm các bước như nhập dữ liệu vào textboxes, comboboxes, clicking on some buttons, rồi lấy kết quả trên màn hình, so sánh với Expected Result của khách hàng, rồi mark vào report là Pass or Fail.
Manual Testing: 5 Testers của chúng ta sẽ phải hì hục ngồi nhập từng row data mà khách hàng provided vào hệ thống (trên UI), Lúc đầu rất hào hứng vì việc test đó không có gì khó khăn, nhưng việc đó cứ lặp đi lặp lại đến chán ngắt, buồn ngủ => có người nhập đúng các Input data, nhưng lại lấy sai Actual Output. Có người nhập sai cả Input Data…!
Mình estimate như sau: Cứ 5 phút thì một tester làm xong một case (một row) và đưa ra được report là pass hay fail. Một ngày 5 testers sẽ làm được: 5 người *((8h * 60 phút)/5 phút một row) = 480 cases. Vậy phải mất 41,6 ngày làm việc thì 5 testers của chúng ta mới kết thúc được 20.000 rows data.
Các bạn nghĩ sao, liệu các testers có chăm chỉ làm 1 ngày 8h hay không? Liệu cứ sau 5p họ có xong một test case (row) hay không? Và liệu họ có bị buồn ngủ và làm nhầm hay không? Con số mình estimate ở bên trên chỉ là estimate. Chứ còn thực tế, nhỡ tester ốm thì sao, nhỡ về lấy chồng thì sao? Hoặc nhỡ xin nghỉ việc đi du lịch thì sao???
Thêm một vấn đề cực kỳ quan trọng nữa, sau 41,6 ngày làm việc chăm chỉ, các testers cũng complete được report và gửi cho khách hàng review. Sau khi xem xong report, khách hàng rất rất khen ngợi tinh thần và kết quả làm việc của testers của chúng ta. Nhưng rất tiếc, chúng ta đã thực hiện việc test trên một module đã bị Developers của chúng ta code sai. Các con số sai lệch không nhiều nhưng bắt buộc chúng ta phải fix cái module sai đó. Hoặc sau khi test xong, chúng ta lại develop thêm một module nhỏ nữa và sẽ tích hợp với module cũ.
Kết quả là chúng ta lại phải thực hiện việc test lại với 20.000 bản ghi data chuẩn kia. (Xin chia buồn với các testers xinh đẹp, thôi cố gắng thu xếp chồng con rồi ở lại Overtime với các anh Developers ga lăng).
Automation Testing: Trên đầu topic, mình đã nêu ra vài Automation test tools! Nhưng trước hết Automation Testing là gì? Là một software program dùng để chạy một cách tự động thay thế các thao tác testing bằng tay.
Ưu điểm của Automation Testing: Nó chạy thay thế testers và không biết mệt, không có chuyện ốm đau, không có chuyện phải dừng để chát, ăn quà vặt, hay để đi WC. Chúng có thể chạy liên tục ngày đêm, một khi chạy đúng được 1 case, thì chúng ta yên tâm rằng Script sẽ chạy đúng những gì chúng ta yêu cầu.
Những gì chúng ta cần viết scripts cho bài toán trên: Viết các script code để giả lập việc nhập dữ liệu vào Textboxes, chọn một item trong combobox, click vào một checkbox, hoặc click vào Button. Và chúng ta cũng phải viết scripts để lấy dữ liệu Output từ một textbox, label, hoặc datagrid… để so sánh với Expected của khách hàng. Chúng ta cũng phải viết các scripts để compare dữ liệu, và đưa ra kết quả là Pass hay Fail.
Và cuối cùng chúng ta sẽ để cho Script của chúng ta chạy đêm ngày – còn chúng ta sẽ ngồi đọc báo, học thêm sách technical, hoặc học tiếng anh, đi uống trà đá. . Còn các em testers xinh đẹp sẽ đỡ vất vả hơn rất nhiều, dĩ nhiên các em ý sẽ yêu quý chúng ta hơn!