Kiểm thử phần mềm - Đặt câu hỏi!

Để thực hành thử nghiệm tốt, nhiệm vụ quan trọng nhất là đặt câu hỏi đúng, đúng thời điểm và đúng đối tượng.

Trong thực tế, sớm hơn một QA được tham gia vào quá trình phát triển phần mềm của một hệ thống mới hoặc nâng cấp một phần mềm hiện tại. Để bắt đầu lập kế hoạch, người phân tích thử nghiệm nên hỏi nhiều câu hỏi ngay từ giai đoạn tìm hiểu yêu cầu để khám phá, bóc tách các giả định ẩn, yêu cầu không hoàn chỉnh / mâu thuẫn, môi trường thử nghiệm...

Giao tiếp chéo trong nhóm ngay từ khi bắt đầu một dự án là chìa khóa để thực hiện kiểm tra hiệu quả và kịp thời. Một người phân tích thử nghiệm tốt sẽ không bao giờ ngần ngại bỏ qua câu hỏi về yêu cầu chưa đủ chi tiết hoặc nếu thiếu sự rõ ràng về ngôn ngữ được sử dụng.

Một yêu cầu là nơi mà đội ngũ QA có thể đóng vai trò để đảm bảo yêu cầu được soạn thảo theo cách mọi người dễ dàng hiểu. Việc QA tham gia trong quá trình phân tích yêu cầu có thể giúp tạo ra một tài liệu yêu cầu toàn diện mà không có bất kỳ khoảng trống nào. Việc mô tả của nhóm thử nghiệm từ đầu dự án có thể thực sự thu hẹp khoảng cách hiểu biết về yêu cầu giữa nhóm dự án, nhóm kỹ thuật và kinh doanh.

Các tài liệu không diễn tả tất cả mọi thứ, và đưa ra các giả định trong quá trình đánh giá tác động là sai lầm tồi tệ nhất mà một người phân tích thử nghiệm có thể thực hiện. Phân tích tài liệu yêu cầu hoặc đặc tả chức năng có thể phát sinh n số truy vấn. Những phần này cần được phân loại theo nhóm để có thể giải quyết chúng.

Câu hỏi cũng có thể được phân loại tùy thuộc vào từng phần mà họ phụ trách. Nó có thể liên quan đến đặc điểm kỹ thuật hoặc tác động của khách hàng hoặc tác động giao diện hoặc rủi ro và lập kế hoạch dự án. Một QA làm việc hiệu quả luôn quan tâm đến tổng thể lớn hơn và sau đó là biết mục tiêu thúc đẩy một dự án / nâng cao hoặc giữ cho mình chủ động được thông báo về lập kế hoạch và thời gian. Nhận thức được điều này sẽ giúp những người thử nghiệm lên kế hoạch cho công việc của họ hiệu quả hơn.

Phân loại các truy vấn trên cơ sở ai có thể trả lời những gì:

• Project Sponsor / Project Manager - Bất cứ điều gì liên quan đến tầm nhìn đằng sau sự phát triển mới là điều mà nhà tài trợ hoặc PM sẽ biết. Ví dụ - Mục tiêu của việc xây dựng một sản phẩm mới hoặc thay đổi một hệ thống hiện có là gì? Mục đích của nó là gì? Sự thay đổi nào có lợi cho người dùng? Bất cứ điều gì liên quan đến kế hoạch dự án tổng thể cũng ngồi với người đứng đầu thay đổi.
• Cộng đồng người dùng thực tế / Nhóm làm việc với người dùng thực tế - Có thể không thể nói chuyện với cộng đồng người dùng thực tế trong mọi trường hợp nhưng mọi thứ liên quan đến trải nghiệm người dùng luôn có thể được đưa ra cho các nhóm giao dịch với họ. Người phân tích thử nghiệm phải biết điều gì là quan trọng nhất đối với người dùng thực tế để thiết kế đúng kịch bản. Các phần của hệ thống quan trọng nhất đối với khách hàng là gì, các vấn đề khiến khách hàng sử dụng hệ thống là gì? Câu trả lời cho những điều này có thể tạo thuận lợi cho việc sản xuất một thiết kế thử nghiệm toàn diện.
• Test Manager / Lead - Trong một nhóm lớn, một nhà phân tích thử nghiệm có thể không có quyền truy cập trực tiếp vào tất cả các thông tin. Trong một kịch bản như vậy anh / cô ấy cũng có thể có câu hỏi cho test lead. Môi trường thử nghiệm, các công cụ kiểm tra và quản lý tự động, các thủ tục báo cáo, bằng chứng kiểm tra, chu kỳ kiểm tra vv cần phải được đồng ý như một phần của kế hoạch kiểm thử.
• Nhóm phát triển - Bất kỳ thứ gì mang tính kỹ thuật hoặc liên quan đến một phần code cụ thể đều liên quan đến developer. Ví dụ - Phần nào của cide đang thay đổi? Tác động của việc giới thiệu một trường mới trên một biểu mẫu web là gì? Những thông tin này giúp người kiểm tra xác định và giới hạn bộ kiểm thử hồi quy.
• Kiến trúc sư giải pháp - Bất kỳ câu hỏi nào về tương tác thành phần, trung gian, dịch vụ web, cơ sở dữ liệu phải lý tưởng cho người chuyển đổi các yêu cầu chức năng thành các sản phẩm thiết kế mà nhóm phát triển sử dụng để xây dựng code.
• Nhóm hỗ trợ - Khi một thay đổi được thực hiện cho một giải pháp hiện có được sử dụng bởi một cộng đồng người dùng rộng, đầu vào từ nhóm trợ giúp cũng chứng tỏ có giá trị. Họ biết những vấn đề mà một khách hàng phải đối mặt khi sử dụng một hệ thống.

Cái gì đó có thể trông giống như một thay đổi nhỏ trên giao diện người dùng thực sự có thể có tác động rộng hơn trên các thành phần khác; một QA phải nhận thức được điều này để đảm bảo phạm vi kiểm tra tối đa. Các câu hỏi như - Giao diện người dùng thay đổi như thế nào trên một trang của trang web ảnh hưởng đến các thông số trên trang kết nối, tác động của “trường mới trong biểu mẫu” trên phần còn lại của giao diện có thể sử dụng các chế độ khác nhau để chuyển dữ liệu đến các thành phần khác (các phương thức chuyển giao này có thể là các XML, thông điệp, các bảng cơ sở dữ liệu, v.v.). Văn bản thông báo lỗi là gì, lược đồ phông chữ & định dạng theo sau các ứng dụng / trang web / sản phẩm là gì và phù hợp với việc xây dựng thương hiệu sản phẩm / trang web / ứng dụng, dữ liệu hợp lệ cho một trường trên trang web là gì? quyền truy cập hoạt động? Đây có thể trông rất cơ bản nhưng thường thiếu thông tin từ các thông số kỹ thuật.

6 Lời khuyên cho người kiểm thử phần mềm khi đặt câu hỏi

1. Học hỏi từ trẻ em

Đặt câu hỏi là quan trọng, nhưng mọi người sợ nó. Tại sao chúng ta nên miễn cưỡng đặt câu hỏi? Thông thường, đó là do một trong hai lý do sau:

Chúng tôi lo lắng chúng tôi sẽ trông ngu ngốc. Khi chúng tôi đặt câu hỏi, chúng tôi đang nói với mọi người rằng chúng tôi không biết điều gì đó. Đặt câu hỏi có thể khiến bạn dễ bị tổn thương. Chúng tôi tin rằng chúng ta "nên" biết mọi thứ. Điều này đặc biệt đúng với những người có nhiều kinh nghiệm hơn. Chúng tôi có xu hướng giả định mọi thứ và nói: “Tôi đã là người thử nghiệm trong mười hai năm. Tôi có thể tự mình tìm ra điều này. ” Trẻ em làm điều ngược lại. Họ không quan tâm những gì mọi người nghĩ về họ. Họ chỉ đặt câu hỏi mà không xấu hổ, và nếu câu trả lời của bạn không thỏa mãn sự tò mò của họ, họ sẽ tiếp tục hỏi cho đến khi họ nhận được câu trả lời họ hiểu (hoặc cho đến khi bạn mệt mỏi khi trả lời).

Kết quả? Trẻ em học những điều mới rất nhanh chóng.

Vì vậy, lấy một mẹo từ trẻ em và đừng bỏ qua các vấn đề khi bạn đang bối rối; hỏi cho đến khi bạn hiểu. Bước đầu tiên trong việc học hỏi những câu hỏi là đủ can đảm để hỏi.

2. Giải quyết vấn đề gốc

Một khi bạn sẵn sàng hỏi, bạn cần đặt câu hỏi đúng. Thường thì các câu hỏi mà chúng tôi nghĩ là nông cạn và không giải thích nguyên nhân gốc — ví dụ: “Bạn có biết một công cụ quản lý kiểm tra tốt không?”

Đặt câu hỏi này và bạn có thể nhận được câu trả lời nhưng có thể đó là câu trả lời mà người bạn đang yêu cầu tìm thấy đã giải quyết được vấn đề của họ. Bạn đang cố gắng giải quyết vấn đề của mình.

Thay vào đó, tìm ra những gì bạn thực sự muốn nhận được từ một câu trả lời, và sau đó đặt câu hỏi.

3. Thêm bối cảnh khác

Ngoài nguyên nhân gốc rễ, bối cảnh giải thích các câu hỏi — ai, cái gì, khi nào, ở đâu, tại sao và như thế nào.

Vì vậy, thay vì chỉ hỏi về một công cụ quản lý thử nghiệm tốt, hãy thêm ngữ cảnh bằng cách cho biết bạn đã gặp phải vấn đề trong bao lâu, những gì bạn đã tìm thấy trong nghiên cứu nền mà bạn đã làm, những gì bạn đã thử xa và cách nó hoạt động, và bạn sẽ làm gì với câu trả lời.

Một cuộc điều tra tốt hơn sẽ là:

Nhóm của tôi gồm ba người hiện đang sử dụng bảng tính Excel để quản lý các trường hợp thử nghiệm và nó hoạt động tốt. Tuy nhiên, nhóm của tôi sẽ phát triển đến 10 người trở lên và có thể được phân phối, vì vậy tôi đang tìm kiếm một công cụ quản lý thử nghiệm mới.

Tôi muốn một công cụ miễn phí dựa trên web hoạt động với cả Mac và Windows và có thể liên kết các yêu cầu kiểm tra và các trường hợp kiểm tra.

Tôi đã thử Bugzilla, nhưng tôi không có máy chủ để cài đặt phần mềm và tôi cần một thứ dễ sử dụng hơn và thân thiện hơn.

Bạn có thể cho tôi một số gợi ý khác không?

Yêu cầu này tốt hơn nhiều vì nó đưa ra bối cảnh xung quanh các câu hỏi. Với yêu cầu này, bạn sẽ có nhiều khả năng nhận được loại câu trả lời mà bạn muốn.

4. 5 câu hỏi tại sao

Hỏi “Tại sao?” 5 lần là một hoạt động phân tích nguyên nhân phổ biến. Đó là một kỹ thuật hỏi câu hỏi lặp đi lặp lại được sử dụng để khám phá các mối quan hệ nhân quả và có hiệu quả nằm bên dưới một vấn đề.

Dưới đây là một ví dụ:

Xe sẽ không khởi động. (Vấn đề)

Tại sao? Pin đã chết. Tại sao? Máy phát điện không hoạt động. Tại sao? Vành đai phát điện đã bị hỏng. Tại sao? Các vành đai phát điện đã sử dụng vượt ngưỡng tuổi thọ của nó. Tại sao? Chiếc xe không được duy trì theo lịch trình dịch vụ được đề nghị. Bởi vì bạn tiếp tục hỏi tại sao, cuối cùng bạn đã có một câu trả lời cung cấp nguyên nhân gốc rễ.

5. Hỏi vịt cao su

Này, đừng cười.

Tôi đang nói về một kỹ thuật gỡ lỗi được gọi là vịt cao su, nơi một lập trình viên bị kẹt trên một vấn đề sẽ giải thích dòng code của mình bằng cách xếp hàng vào một con vịt cao su ở bàn làm việc của anh ấy trong khi anh ấy đang gỡ lỗi code.

Thông thường, lập trình viên sẽ tự tìm ra câu trả lời cho vấn đề khi anh ta dành thời gian giải thích vấn đề to với một đối tượng vô tri vô giác.

Mặc dù nó thường là một kỹ thuật lập trình, ý tưởng cũng được áp dụng trong kiểm thử phần mềm. Tất nhiên, bạn có thể giải thích vấn đề cho đồng nghiệp của bạn để bắt đầu suy nghĩ của bạn thay vào đó, nhưng yêu cầu vịt cao su giữ bạn khỏi làm gián đoạn đồng nghiệp của bạn - và nó nghe có vẻ thú vị hơn.

6. Dừng lại và suy nghĩ

Giả sử ai đó đến gặp bạn với một vấn đề. Trước khi nhảy vào để giải quyết nó, hãy chắc chắn rằng bạn hiểu đầy đủ những gì đang diễn ra. Michael Bolton đề xuất bốn từ đơn giản để sử dụng để tạm dừng và tham gia tư duy phê phán của bạn: huh, thực sự, và, và như vậy?

Bolton định nghĩa những từ “tạm nghỉ” này có nghĩa là:

Chờ đã ... huh? Tôi có nghe đúng không? Nó có nghĩa là những gì tôi nghĩ rằng nó có nghĩa là? Um ... thật sao? Điều đó có phù hợp với kinh nghiệm và sự hiểu biết của tôi về thế giới như hiện tại hay không? Một số cách giải thích thay thế hợp lý cho những gì tôi vừa nghe hoặc đọc là gì? Làm thế nào chúng ta có thể bị lừa bởi nó? Chỉ một giây ... và? Thông tin bổ sung nào có thể bị thiếu? Tôi có thể phỏng đoán ý nghĩa nào khác? OK ... vậy sao? Một số hậu quả hoặc phân nhánh của những diễn giải đó là gì? Những gì có thể làm theo? Chúng ta làm gì - hoặc nói, hoặc hỏi - tiếp theo? Khi bạn mất một giây để tạm dừng và nói huh, thực sự, và, hoặc như vậy, thông tin liên lạc chảy dễ dàng hơn và bạn có thể thu thập suy nghĩ của bạn trước khi cố gắng đến một giải pháp.

Cuối cùng

Cựu cầu thủ bóng đá, huấn luyện viên, và nhà phân tích Lou Holtz nói, “Tôi chưa bao giờ học bất cứ điều gì nói chuyện. Tôi chỉ học được những điều khi tôi đặt câu hỏi. ”

Đặt câu hỏi đóng một vai trò quan trọng trong công việc hàng ngày của chúng tôi là người kiểm thử phần mềm. Nó không phải là dễ dàng - thực sự, nó có thể là một trong những kỹ năng khó khăn nhất để làm chủ — nhưng nó đáng để nỗ lực bởi vì bạn càng hỏi nhiều, bạn càng học nhiều.

Dành thời gian thực hành đặt câu hỏi hay. Nó sẽ giúp bạn trở thành người thử nghiệm tốt hơn.

Nguồn: https://www.testingexcellence.com/software-testing-ask-questions/ https://www.stickyminds.com/article/6-tips-software-testers-asking-questions