CHƯƠNG 1 CÁC YẾU TỐ CƠ BẢN CỦA KIỂM THỬ - TÂM LÝ HỌC VỀ KIỂM THỬ

Trong phần này, chúng ta sẽ thảo luận về các yếu tố tâm lý khác ảnh hưởng đến kiểm thử và thành công của nó. Các mục tiêu này bao gồm các mục tiêu rõ ràng để kiểm thử, sự hợp lý và sự cân bằng của tự kiểm thử và kiểm thử độc lập, thông tin rõ ràng, và phản hồi về khiếm khuyết.

1. Kiểm thử độc lập - ai là người kiểm thử?

• Nếu chúng ta đang xây dựng một cái gì đó chúng ta đang làm việc tích cực để giải quyết các vấn đề trong thiết kế và nhận ra một sản phẩm không đáp ứng được một số nhu cầu. Tuy nhiên, khi chúng tôi kiểm thử hoặc xem xét một sản phẩm, chúng tai cần tìm kiếm các khiếm khuyết trong sản phẩm để có đánh giá tốt nhất.
• Giả sử bạn chuẩn bị một bữa ăn để tham dự cuộc thi dành cho các đầu bếp. Bạn chọn menu, thu thập các thành phần, nấu thức ăn, đặt bàn, và phục vụ bữa ăn. Nếu bạn muốn giành chiến thắng, bạn làm mỗi công việc như bạn có thể. Giả sử bạn là một trong những giám khảo đánh giá các bữa ăn cạnh tranh nhau. Bạn kiểm tra tất cả mọi thứ, bao gồm thực đơn, các thành phần, các phương pháp được sử dụng, thời gian và ngân sách trợ cấp, lựa chọn các thành phần, sự sang trọng của thiết lập bàn ăn và phục vụ, và cái nhìn và hương vị của bữa ăn. Để phân biệt giữa các đầu bếp cạnh tranh, bạn sẽ khen ngợi mọi khía cạnh tốt của buổi trình diễn nhưng bạn cũng sẽ lưu ý mọi lỗi và lỗi của mỗi đầu bếp. Vì vậy, cũng như với phần mềm kiểm thử: xây dựng phần mềm đòi hỏi một tư duy khác nhau so với kiểm thử phần mềm.
• Chúng ta không nói là người kiểm thử không thể là lập trình viên hoặc lập trình viên không thể là người kiểm thử, mặc dù họ thường là những vai trò riêng biệt. Trên thực tế, các lập trình viên là những người kiểm thử - họ kiểm thử các thành phần mà họ xây dựng, và sự tích hợp của các thành phần vào hệ thống. Đầu bếp tốt sẽ quan trọng như các giám khảo khi cạnh tranh về công việc của mình, để ngăn ngừa và khắc phục lỗi và khiếm khuyết trước khi ai đó thông báo cho họ. Vì vậy, với suy nghĩ đúng đắn, lập trình có thể kiểm thử mã của riêng họ; thực sự các lập trình viên kiểm thử mã của họ và tìm ra nhiều vấn đề, giải quyết chúng trước khi ai đó nhìn thấy mã của họ có vấn đề. Nhân viên phân tích nghiệp vụ nên xem lại yêu cầu riêng của họ. Kiến trúc sư hệ thống nên xem xét thiết kế riêng của họ. Tuy nhiên, tất cả chúng ta đều biết rằng rất khó để tìm ra những sai lầm của mình. Vì vậy, các nhà phân tích nghiệp vụ, kiến trúc sư và lập trình thường dựa vào những người khác để giúp họ kiểm thử sản phẩm của họ. Người này có thể là một nhà phân tích, nhà thiết kế hoặc nhà phát triển đồng nghiệp. Một người sẽ sử dụng phần mềm có thể giúp kiểm thử nó. Các nhà phân tích nghiệp vụ làm việc theo yêu cầu và thiết kế có thể thực hiện một số kiểm thử. Chuyên gia kiểm thử - người kiểm thử chuyên nghiệp - thường tham gia. Trên thực tế, kiểm thử có thể liên quan đến một loạt những người mỗi khi thực hiện một mức độ kiểm thử khác nhau. Điều này cho phép kiểm thử độc lập hệ thống.
• Trong giai đoạn đầu của dự án, việc đánh giá các yêu cầu và tài liệu thiết kế của người khác không phải là tác giả sẽ giúp tìm ra các khiếm khuyết trước khi bắt đầu viết mã và giúp chúng ta xây dựng đúng phần mềm. Sau khi mã hóa, phần mềm có thể được kiểm thử một cách độc lập. Mức độ độc lập này tránh được sự thiên vị của tác giả và thường có hiệu quả hơn trong việc tìm kiếm các khiếm khuyết và thất bại.
• Một số mức độ độc lập có thể được xác định, liệt kê ở đây từ mức thấp nhất đến mức độ độc lập cao nhất:
  • Các bài kiểm thử của người tạo ra chính modul, sản phẩm đó.
  • Các bài kiểm thử của một người khác trong cùng một nhóm, chẳng hạn như lập trình viên khác.
  • Các bài kiểm thử của một người từ một nhóm tổ chức khác, chẳng hạn như đội kiểm thử độc lập.
  • Các bài kiểm thử được thiết kế bởi một người từ một tổ chức hoặc công ty khác, chẳng hạn như kiểm thử bên ngoài hoặc xác nhận bởi cơ quan bên ngoài.
• Tuy nhiên, cần lưu ý rằng sự độc lập không nhất thiết là yếu tố quan trọng trong nhất việc kiểm thử. Các nhà phát triển biết làm thế nào để kiểm thử và họ như những đầu bếp tốt, tự phê bình, có ưu điểm bởi sự thông thạo với sản phẩm của mình và tự hào về công việc đi kèm với tính chuyên nghiệp thực sự. Những người phát triển như vậy có thể tìm ra nhiều khiếm khuyết trong mã của riêng họ. Một số phương pháp luận phát triển phần mềm nhấn mạnh vào các nhà phát triển thiết kế các bài kiểm thử trước khi họ bắt đầu viết mã và thực hiện những bài kiểm thử liên tục khi họ thay đổi mã. Cách tiếp cận này thúc đẩy việc kiểm thử sớm và phát hiện khiếm khuyết sớm, có hiệu quả về chi phí. Hãy nhớ rằng, kiểm thử độc lập có thể được thực hiện ở bất kỳ mức độ kiểm thử nào và việc lựa chọn mức độ độc lập phụ thuộc vào rủi ro trong bối cảnh cụ thể.

2. Tại sao chúng ta đôi khi không hòa nhập với phần còn lại của đội?

• Tách vai trò của người kiểm thử từ nhà phát triển vai trò cũng được thực hiện để giúp tập trung nỗ lực và cung cấp những lợi ích của việc đào tạo và kiểm thử tài nguyên chuyên nghiệp. Trong nhiều tổ chức, các giai đoạn kiểm thử trước đó được tiến hành bởi các nhà phát triển, các nhà tích hợp và các giai đoạn sau một cách độc lập, hoặc bởi nhóm kiểm định chuyên môn hoặc bởi khách hàng. Tuy nhiên, sự tách biệt này có thể dẫn đến các vấn đề cũng như lợi thế. Lợi thế về sự độc lập và tập trung có thể bị mất nếu mối quan hệ giữa các đội trở nên xấu đi, như chúng ta sẽ thấy.
• Mỗi tổ chức và từng dự án sẽ có những mục đích và mục tiêu riêng.
• Các bên liên quan khác nhau, chẳng hạn như khách hàng, nhóm phát triển và quản lý của tổ chức sẽ có những quan điểm khác nhau về chất lượng và có mục tiêu riêng của họ. Vì con người và dự án được định hướng bởi các mục tiêu, nên các bên liên quan có quan điểm mạnh nhất hoặc có ảnh hưởng lớn nhất đối với một nhóm sẽ xác định một cách có ý thức hay tiềm thức những mục tiêu đó. Mọi người có xu hướng sắp xếp kế hoạch của họ với những mục tiêu này. Ví dụ, tùy thuộc vào mục tiêu, người kiểm thử có thể tập trung vào việc tìm ra lỗi hoặc xác nhận rằng phần mềm hoạt động. Nhưng nếu một bên liên quan ít có ảnh hưởng hơn trong quá trình thực hiện dự án nhưng có nhiều ảnh hưởng hơn khi giao sản phẩm, có thể có một sự đụng độ về việc kiểm thử có đáp ứng các mục tiêu của nó hay không. Một người quản lý có thể muốn xác nhận rằng phần mềm hoạt động và nó là 'đủ tốt' nếu điều này được xem như một cách để cung cấp càng nhanh càng tốt. Một người quản lý khác có thể muốn kiểm thử tìm ra càng nhiều khiếm khuyết càng tốt trước khi phần mềm được phát hành, sẽ mất nhiều thời gian hơn và sẽ cần thời gian để sửa chữa, kiểm thử lại và kiểm thử hồi quy. Nếu không có mục tiêu rõ ràng và tiêu chí xuất cảnh để kiểm thử mà tất cả các bên liên quan đã đồng ý, thì có thể tranh luận, trong quá trình kiểm thử hoặc sau khi phát hành, về việc kiểm thử "đủ" đã được thực hiện hay không.
• Nhiều người trong chúng ta thấy khó khăn đón nhận những lời đóng góp về công việc của mình. Chúng ta thường tin rằng chúng ta đã làm hết sức mình để tạo ra sản phẩm (tài liệu, mã, kiểm thử, bất cứ điều gì) là chính xác và đầy đủ. Vì vậy, khi ai đó nhận ra một lỗi, một sai lầm chúng ta đã thực hiện, chúng ta có thể thấy khó chịu về người đó, đặc biệt là nếu chúng ta đang ở dưới áp lực thời gian. Tất cả chúng ta đều mắc sai lầm và chúng ta đôi khi bị khó chịu, thất vọng hoặc chán nản khi ai đó chỉ ra chúng . Vì vậy, khi là người kiểm thử chúng tôi chạy một bài kiểm thử mà (từ quan điểm của chúng tôi) là một bài kiểm thử tốt mà tìm thấy khiếm khuyết và thất bại trong phần mềm, chúng ta cần phải cẩn thận với phản ứng của người khác . Chúng ta thỏa mãn, tất nhiên, khi chúng ta đã tìm thấy một "good bug"! Nhưng các nhà phân tích, nhà thiết kế, phát triển, quản lý dự án và khách hàng phản ứng lại như thế nào? Những người xây dựng sản phẩm có thể phản ứng phòng thủ và nhận thấy báo cáo này khiếm khuyết như những lời chỉ trích cá nhân chống lại sản phẩm và chống lại tác giả. Các người quản lý dự án có thể khó khăn để giữ dự án. Các khách hàng có thể mất niềm tin vào sản phẩm vì có thể thấy lỗi. Bởi vì việc kiểm thử có thể được coi là hoạt động phá hoại, chúng ta cần quan tâm báo cáo về các khiếm khuyết và thất bại một cách khách quan và lịch sự nhất có thể. Nếu người khác xem công việc của chúng ta là xây dựng trong việc quản lý rủi ro sản phẩm, chúng ta cần phải cẩn thận khi chúng ta đang xem xét và khi chúng ta đang kiểm thử.
  • Truyền đạt những phát hiện về sản phẩm theo cách trung lập, thực tế mà không cần chỉ trích người tạo ra nó.Ví dụ, viết báo cáo sự cố khách quan và thực tế và xem xét các phát hiện:
    • Đừng hăng hái - bạn cũng không hoàn hảo!
    • Không đổ lỗi - bất kỳ sai lầm nào cũng có thể là của nhóm chứ không phải chỉ là một cá nhân.
    • Có tính phê phán và thảo luận về khuyết điểm và cách bạn sẽ tìm ra nó.
  • Giải thích rằng bằng hiểu biết về điều này bây giờ chúng ta có thể làm việc xung quanh nó hoặc sửa chữa nó để hệ thống tốt hơn cho khách hàng:
    • Nói những gì bạn thích và những gì đã làm việc, cũng như những gì đã không là.
    • Cho thấy rủi ro là gì một cách trung thực - không phải mọi thứ đều được ưu tiên cao.
    • Không chỉ nhìn thấy mặt bi quan – cần khen ngợi cũng như chỉ trích.
    • Hiển thị những rủi ro đã được phát hiện và những lợi ích của việc rà soát hoặc kiểm thử.
  • Bắt đầu với sự hợp tác chứ không phải là trận đánh. Nhắc nhở mọi người về mục tiêu chung của hệ thống là làm chất lượng tốt hơn:
    • Hãy lịch sự và hữu ích, hợp tác với đồng nghiệp của bạn.
    • Cố gắng hiểu cảm giác của người kia và tại sao họ phản ứng như cách họ làm.
    • Xác nhận rằng người khác đã hiểu những gì bạn đã nói và ngược lại.
    • Giải thích cách bài kiểm thử hoặc đánh giá giúp người tạo ra sản phẩm đó.
    • Cũng đưa ra công việc của bạn để được xem xét.
• Công việc của chúng ta là người đánh giá và người kiểm thử để cung cấp cho mọi người một cách rõ ràng và khách quan thông tin và để làm điều này chúng ta đi tìm lỗi, khai thác lỗ hổng và các thất bại. Những người sẽ làm cho các nhà phê bình và người kiểm thử giỏi có mong muốn và khả năng tìm ra vấn đề, và điều này đúng cho dù kiểm thử là công việc chính của họ hoặc là một phần của vai trò là một nhà phát triển. Những người này xây dựng kinh nghiệm về những sai sót có thể xảy ra và được đặc trưng bởi sự tò mò, sự chuyên nghiệp, mắt phán đoán và chú ý đến chi tiết. Tuy nhiên, trừ khi chúng ta có những kỹ năng giao tiếp và giao tiếp tốt, lịch sự, hiểu biết về người khác và có thái độ tốt đối với bạn bè, đồng nghiệp, khách hàng, người quản lý và phần còn lại của nhóm, chúng ta sẽ thất bại như những người kiểm thử vì không ai lắng nghe chúng ta.
• Người kiểm thử và người lãnh đạo kiểm thử cần phải có kỹ năng giao tiếp tốt
• Thông tin thực tế về các khiếm khuyết, tiến bộ và rủi ro một cách xây dựng. Đối với tác giả của phần mềm hoặc tài liệu, thông tin lỗi có thể giúp họ nâng cao kỹ năng của họ, nhưng chỉ khi nó được cung cấp theo cách có thể giúp họ.
• Khi xem xét hoặc kiểm thử, chúng ta cần thông tin một cách khách quan, nhưng các loại thông tin khác cũng hữu ích: "Điều này xảy ra; làm thế nào tôi cảm thấy về nó; đây là điều đúng; đây có thể là sai; đây là cách chúng ta có thể giải quyết vấn đề ". Là một phần của việc cung cấp đánh giá rủi ro, chúng ta có thể giúp các nhà quản lý và khách hàng đưa ra các quyết định dựa trên rủi ro dựa trên chi phí và thời gian tác động của một khiếm khuyết. Nếu chúng tôi kiểm thử và tìm ra một lỗi mà sẽ có giá $ 15 000 để sửa chữa và kiểm thử lại / hồi quy kiểm thử, nó có giá trị sửa chữa? Nếu nó sẽ gây ra một tác động kinh doanh của $ 50 000 trong môi trường thực mà khách hàng có thể muốn lỗi đó đáng lẽ đã sửa. Nếu nó có một tác động kinh doanh tiềm năng là $ 10 000 nhưng bất kỳ sửa chữa là khó khăn để làm và có thể có tác động bất lợi ở nơi khác, tốt hơn là không nên sửa chữa. Bằng cách cung cấp cho nhóm thông tin về khiếm khuyết theo những điều mà họ thấy hữu ích, chúng ta có thể giúp họ đưa ra quyết định đúng đắn về việc khắc phục hoặc không khắc phục được các vấn đề. Nói chung chúng ta nói rằng các khiếm khuyết được tìm thấy và cố định trong quá trình kiểm thử sẽ giúp tiết kiệm thời gian và tiền bạc sau đó và giảm rủi ro, vì vậy chúng ta cần chứng minh rằng đó là trường hợp theo thứ tự để kiểm thử được đánh giá.