Nhìn nhận đúng đắn về Testing

Vai trò của bạn trong dự án là gì? Bạn là một PM? PTL? developer? hay là một tester? Từ vị trí của mình, bạn nghĩ công việc kiểm thử (testing) trong dự án nhằm mục đích gì?

Tôi đã làm việc với khá nhiều người, ở nhiều vị trí trong dự án. Dường như, họ không có một định nghĩa rõ ràng về công việc của Test team. Nhớ lại về những dự án mình đã làm việc, những bạn tester mà tôi đã có cơ hội chỉ bảo, hướng dẫn đến với nghề, chưa bao giờ tôi nói với họ một định nghĩa cụ thể nào đó về công việc mà họ đang và sẽ làm. Đâu đó trong quá trình thực hành và trưởng thành với nghề, họ có thể nhận thức được mình đang làm gì, và vô hình chung hình thành một khái niệm nhất định cho bản thân mình về công việc testing trong dự án.

Hãy giúp tôi, tự đặt cho mình câu hỏi: Testing là gì?

Tất nhiên, tôi không thể biết câu trả lời của bạn (trừ khi bạn sẵn lòng hồi đáp lại cho tôi). Thường thì sẽ có một vài quan điểm, nhưng việc nhận thức sai vấn đề có thể ảnh hưởng đến hiệu quả và mục đích công việc của bạn rất nhiều. Vì sao ư? Tôi sẽ chỉ cho bạn thấy.

Một trong số những nguyên nhân quan trọng của chất lượng test kém là thực tế, các kỹ sư phần mềm thường bắt đầu với một định nghĩa sai lầm. Họ có thể cho rằng:

Testing là quá trình chứng minh rằng lỗi không xuất hiện trong chương trình.

hoặc

Mục đích của testing là chỉ ra rằng chương trình đã thực hiện những chức năng dự định một cách chính xác.

hoặc

Testing là quá trình thiết lập sự tin cậy rằng một chương trình đã làm những gì mà nó phải làm.

Có gì sai không? Ừm, có vẻ không sai nhỉ! Nhưng thực ra, những định nghĩa này hoàn toàn ngược.

Khi bạn kiểm thử một chương trình, bạn cần thêm các giá trị cho công việc của mình. Thêm giá trị cho quá trình kiểm thử có nghĩa là làm tăng chất lượng hoặc độ tin cậy của chương trình. Tăng độ tin cậy của chương trình chính là tìm và loại bỏ lỗi.

Do đó, đừng test một chương trình chỉ để cho thấy chương trình đó có làm việc hay không, thay vào đó, bạn nên bắt đầu bằng một giả định, rằng chương trình đó có lỗi (tất nhiên rồi, đây thậm chí có thể gọi là thực tế ấy chứ) và do đó, testing là quá trình tìm ra lỗi nhiều nhất có thể.

Khi đó, một định nghĩa hợp lý sẽ là: Testing là một quá trình thực hiện một chương trình với mục đích tìm ra lỗi.

Nếu so sánh với các định nghĩa như trên đã đề cập, có vẻ như đây là một sự chơi chữ tinh tế, nhưng thực chất, nó tạo nên một sự khác biệt quan trọng trong công việc của bạn.

Đứng về khía cạnh tâm lý, con người thường có xu hướng tập trung vào vào một muc tiêu nào đó. Nếu mục tiêu của chúng ta là chứng mình rằng “lỗi không xuất hiện trong chương trình”, chúng ta sẽ vô thức hướng tới mục tiêu này. Chúng ta sẽ có xu hướng chọn ra những test data có khả năng thấp gây ra lỗi chương trình. Nhưng nếu mục tiêu là để “tìm ra lỗi”, chúng ta sẽ sử dụng những test data có khả năng cao hơn giúp tìm ra lỗi. Như vậy, với mục tiêu thứ hai, testing đã mang lại nhiều giá trị hơn mục tiêu đầu tiên.

Vấn đề thứ hai với định nghĩa như là “Testing là quá trình chứng minh rằng lỗi không xuất hiện trong chương trình” là điều không thể đối với hầu hết các chương trình, kể cả với những chương trình nhỏ.

Một lần nữa, các nghiên cứu tâm lý đã chỉ ra rằng, con người thường làm việc kém đi khi họ được yêu cầu thực hiện một công việc mà theo họ là không thể làm được. Ví dụ, nếu bạn được yêu cầu giải đố ô chữ trên tờ New York Times trong 15 phút (ô chữ của New York Times rất nổi tiếng và được ưa chuộng, thông thường là ô chữ 15×15, các số vào Chủ nhật là ô chữ 21×21), chúng ta sẽ hầu như không thu được kết quả gì sau 10 phút vì hầu hết chúng ta sẽ bỏ cuộc khi cho rằng việc này là không thể. Tuy nhiên, nếu bạn được yêu cầu làm việc này trong 4 giờ, có thể chúng ta sẽ có kết quả nhất định sau 10 phút. Định nghĩa về testing như một quá trình “tìm ra lỗi” có trong chương trình khiến nó trở thành một nhiệm vụ có-thể-thực-hiện-được, do đó vượt qua khỏi vấn đề về tâm lý.

Vấn đề thứ ba với định nghĩa kiểu: “Mục đích của testing là chỉ ra rằng chương trình đã làm những gì nó phải làm” là thực tế, một chương trình làm đúng những gì yêu cầu vẫn có thể có lỗi. Nhưng lỗi cũng xuất hiện khi chương trình không làm đúng như mong muốn. Hoặc khi chương trình làm những việc không được yêu cầu, lỗi cũng có thể tồn tại. Chúng ta sẽ nhìn nhận sâu sắc hơn về lớp lỗi nếu chúng ta xem xét việc kiểm thử chương trình là một quá trình tìm lỗi hơn là một quá trình chứng minh rằng một chương trình sẽ làm đúng những điều mà nó được yêu cầu.

Tóm lại, kiểm thử chương trình nên được nhìn nhận một cách thích hợp là quá trình tìm ra những lỗi tiềm tàng (mà mình giả định là tồn tại) trong một chương trình. Đương nhiên, bạn cũng muốn sử dụng kiểm thử chương trình để thiết lập mức độ tin cậy cho việc chương trình sẽ làm đúng những việc mà nó phải làm và không làm những việc mà nó không nên thực hiện, nhưng mục đích này chỉ đạt được tốt nhất sau khi đã được kiểm tra kỹ càng để tìm ra lỗi.

Tại sao các Developer là Tester “dỏm” và làm sao khắc phục?

5 lý do khiến các developer là không phải Tester “trời sinh”

1.Con nhà mình – Con nhà người ta

Khi đứng trong một căn phòng đông người, nếu ai đó bước lên và hỏi: “Ai trong đây có đứa con xấu xí?” 95% sẽ im lặng. Nhưng nếu hỏi rằng: “Ai trong đây có một người bạn có đứa con xấu xí?” thì số người giơ tay sẽ rất rất rất nhiều.

Hiện tương tương tự xảy ra với các developer khi được yêu cầu test những dòng code của chính mình. Họ có xu hướng không thể nhận ra lỗi sai của mình, trong khi nếu đó là của người khác, họ không những có thể tìm ra, xác định lỗi mà còn sửa được chúng.

2. Developer thường đơn giản hóa những vấn đề phức tạp

Các Dev thường tập trung vào việc biến những bài toán phức tạp với những yêu cầu rối mù thành những task nhỏ và có thể hành động được (actionable), rồi lại “dịch” chúng thành những dòng code nhỏ. Ví dụ, đề bài yêu cầu tạo ra một nút bấm để người dùng đăng ký dung trial, họ sẽ chuyển những yêu cầu đó thành các dòng và biến cái nút đó trở nên dùng được.

Testing thì hoàn toàn ngược lại. Task của một tester cần phải lấy những tính năng đơn giản và suy nghĩ về những kịch bản phức tạp mà có thể làm “sập” hết mọi thứ chỉ vì bugs.

3. Tập trung vào những “kịch bản lạc quan”

Một lần nữa, các developer luôn suy nghĩ về cách khiên mọi thứ xảy ra, hoặc đạt được kết quả mà họ muốn thông qua những dòng code. Trong khi đó, với testing, chúng ta cần phải xác định và tìm ra những lúc mà mọi thứ không làm việc trơn tru như chúng ta mong muốn.

Một phần quan trọng của testing là tìm ra điểm yếu của hệ thống và trong hệ thống để có thể sửa chúng. Phần lớn developers đều quan tâm đến việc giải quyết vấn đề chứ không phải vẽ ra thêm vấn đề. Chính điều này khiến họ không thể có tư duy của tester: phá hoại thay vì xây dựng.

4. Bỏ qua những chi tiết nhỏ trong tổng thể

Tester có xu hướng tìm những thứ có thể bẻ gẫy pattern. Coder lại có xu hướng tìm hoặc tạo ra pattern.

5. Thiếu kiến thức End-to-end và góc nhìn của người dùng

Phần lớn các doanh nghiệp đều không bỏ ra nhiều thời gian hay nỗ lực để khiến giúp các developer hiểu được người sử dụng sản phẩm của họ. Các developer luôn chỉ làm việc họ được thuê để làm: viết code và phát triển sản phẩm mới, và câu chuyện về việc thấu hiểu khách hang lại được để lại cho Quản lý Sản phẩm.

Vậy nên chẳng lạ gì khi nhiều lần các developers không thể biết được các mà người dùng của họ sử dụng hệ thống. Do đọ họ sẽ không dành thời gian để dự đoán những nguy cơ có thể xảy ra khi người dùng sử dụng hệ thống của họ

Trở thành một developer-tester giỏi?

Rõ ràng là chẳng developer nào giỏi test tự nhiên. Tuy nhiên, vẫn có nhiều cách để thay đổi điều đó.

1. Ngừng xem testing là “bới lông tìm vết”

Một đội giỏi đòi hỏi cả developer và tester phải test. Bước đầu tiên để trở thành tester giỏi hơn là quên đi thực tế rằng bạn đang “test”. Test không phải là một công việc “ghê gớm”, và cũng không phải là một công việc dễ dàng. Nếu bạn muốn trở nên giỏi test, hãy bắt đầu bằng việc xem việc này là nghiêm túc, y như những công việc thường ngày khác của bạn và đảm bảo bạn dành đủ thời gian cho việc test.

2. Thấu hiểu những điểm yếu và giới hạn của mình với tư cách một developer

Nhận thức được “điểm mù” của chính mình là tiền đề cho việc phát triển. Biết được điểm mạnh và yếu của mình sẽ giúp bạn làm việc tốt hơn. Nếu có điều gì bạn cần học hỏi them, hãy học. Nếu bạn cần nhờ ai đó giúp đỡ, hãy mạnh dạn nhờ. Chẳng có gì là đáng xấu hổ khi nhờ người khác tư vấn hay giúp đỡ.

3. Lên kế hoạch code theo những khó khăn bạn gặp phải

Test đòi hỏi việc lên kế hoạch để đảm bảo bạn đang làm đúng và không bị “lạc đề”. Dưới đây là một số ví dụ:

• Đừng test code của chính mình: như đã nói, developer luôn làm tốt nhất khi test của người khác, và cũng hãy nhờ người khác test những dòng code của chính bạn.
• Trước khi test, hãy NGHĨ! Hãy nghĩ về cả những kịch bản tốt và xấu, nghĩ về cách mà người dùng sẽ sử dụng hệ thống, phân tích sản phẩm và tìm xem những điểm yếu.
• Có checklist: Hãy đảm bảo rằng bạn sẽ viết ra những gì mà bạn muốn test trước khi bắt đầu để đảm bảo bạn không lỡ mất điều gì quan trọng một khi bạn vào việc.