Kỹ thuật phân tích yêu cầu sử dụng công cụ Mindmup

Nội dung của bài gồm 3 phần chính sau:

Phân tích yêu cầu trong kiểm thử phần mềm là gì?

Tại sao phân tích yêu cầu quan trọng với QA (Tester) ?

Áp dụng phân tích yêu cầu sử dụng Mindmup ?

1 - Phân tích yêu cầu là gì?

Phân tích yêu cầu là 1 khâu trong quy trình kiểm thử của 1 QA Mục đích của phân tích yêu cầu là giúp QA trả lời được các câu hỏi

• Input của hệ thống là gì?

• Những quá trình cần xử lý trong hệ thống, hay hệ thống phần mềm sẽ phải xử lý những cái gì?

• Đầu ra: kết quả xử lý của hệ thống là gì?

• Những ràng buộc trong hệ thống, chủ yếu là mối quan hệ giữa đầu vào và đầu ra như thế nào ?

• Đối tượng sử dụng sản phẩm?

2 - Tại sao phân tích yêu cầu quan trọng với QA ?

Dựa vào định nghĩa có thể thấy phân tích yêu cầu là khâu rất quan trọng trong quy trình kiếm thử

Input của việc phân tích này chính là bản đặc tả yêu cầu từ phía BA của dự án cộng với bản thiết kế về sản phẩm, hay đôi khi bạn không có cả 2 tài liệu trên mà vẫn phải phân tích yêu cầu, lúc này QA cần vận dụng kinh nghiệm của mình hoặc dựa trên một số hệ thống có sẵn để tham khảo

Giả sử thế này, QA nhận được một bản spec và tiến hành viết Test case luôn mà không tiến hành phân tích, đi sâu tìm hiểu spec >> Liệu rằng QA đó có khả năng viết được 1 bản Test case chuẩn? Trên thực tế bạn vẫn có thể làm được điều này, tuy nhiên với những người ít kinh nghiệm, việc lack Test case là rất phổ biến

Khi phân tích yêu cầu, hiểu rõ được yêu cầu sẽ giúp QA:

• Biết được phạm vi của phần mềm/tính năng

• Mức độ ảnh hưởng

• Rủi ro có thể xảy ra

• Estimate chuẩn hơn khi chia nhỏ các yêu cầu

Việc phân tích yêu cầu sẽ giúp QA định hình được sản phẩm mà mình đang làm, xét ở nhiều khía cạnh khác nhau, từ đó đưa ra được bộ Test case, Check list ...Điều đó cũng có nghĩa là nếu như có khả năng phân tích yêu cầu tốt => QA sẽ đưa ra được bộ Test case, check list cover được phạm vi rộng của hệ thống phần mềm.

Spec không phải luôn đúng và đủ, việc phân tích yêu cầu cũng giúp QA đưa ra được các quan điểm của mình trước khi bắt đầu phát triển từ đó có thể hạn chế trước được một số trường hợp có thể xảy ra gây ảnh hưởng đến dự án hay thậm trí có thể tiết kiệm được chi phí phát triển, nguồn lực. QA nên giữ tâm thế mình hoàn toàn có thể thay đổi được spec hiệu quả và tối ưu hơn

Việc đặt câu hỏi Q&A khi phân tích spec cũng giúp cho các bên khác nhau cùng làm rõ được vấn đề, đồng nhất cách hiểu và tránh được việc không match ý nhau trong khi làm. Đây là vẫn đề thường gặp và có thể gây ra tổn thất rất lớn cho dự án nếu như các bên phát triển không hiểu cùng một ý

Ví dụ điển hình cho việc đội ngũ phát triển không có cách hiểu chung về yêu cầu phát triển

3 - Phân tích yêu cầu sử dụng Mindmup

A, Overview về Mindmup tool

Mindmup là công cụ tư duy logic cực kỳ hiệu quả được tích hợp ngay trên Google driver và hoàn toàn miễn phí

Ưu điểm: Dễ sử dụng, giao diện đơn giản nhưng không nhàm chán, có thể sharing như một file trên Driver hoặc export ra nhiều định dạng khác nhau như hình dưới đây:

Ngoài ra, có thể export sang link web và truy cập online ngay trên trình duyệt Sử dụng mindmup hoàn toàn có thể thu gọn, expand tùy ý giúp người dùng nhìn vừa nhìn tổng quan và chi tiết một cách nhanh chóng và tiện lợi

Và tất nhiên nó free

Nhược điểm: mindmup sẽ phù hợp hơn với các bài toán khó, nhiều luồng, nhiều đối tượng khác nhau. Với các yêu cầu đơn giản thì việc sử dụng mindmup là không cần thiết

B, Áp dụng mindmup vào phân tích 1 bài toán cụ thể như thế nào

Ví dụ: spec đưa ra một tính năng: cho phép login bằng Google và Facebook ngoài tài khoản đăng ký thường (tk thường gồm email và số điện thoại)

Tính năng này cực kỳ phổ biến và quen thuộc, có nhiều QA khá chủ quan vì đã sử dụng nhiều

Với bài toán này, tôi sẽ đi qua các bước như sau:

B1: Overview, xác định các đối tượng chính, dễ nhìn thấy nhất, tôi sẽ có data như sau:

Bài toán này nhìn vào là thấy ngay 3 đối tượng. Nếu bạn có thắc mắc vì sao lại đặt tài khoản thường ở đây thì câu trả lời vì tài khoản thường sẽ có liên quan, ràng buộc đến 2 acc Social

=> Vậy có thể kết luận trong bước đầu tiên này, chúng ta cần overview về tính năng, dễ dàng xác định hết tất cả các đối tượng chính trong bài toán và đối tượng có thể ảnh hưởng đến các đối tượng này

B2: Đi phân tích theo từng nhánh, ở bước này sẽ đi xác định các thuộc tính của từng loại tài khoản, những thuộc tính mà có thể có liên quan tới thuộc tính của đối tượng khác, tôi sẽ có như sau:

Lúc này, chúng ta đã có thể bắt đầu định hình ra được đối tượng của bài toán và hiểu nó là gì, ở từng bước bạn phải chắc chắn rằng đã liệt kê đầy đủ hết, việc đi từng nhánh sẽ giúp bạn xác định được chi tiết và cẩn thận hơn

B3: từ các nhánh nhỏ này, bạn lại đi tiếp từng nhánh con, bạn sẽ thấy:

Tài khoản thường: email và sđt ko thể chia nhỏ được nữa, vì nó là 2 đối tượng validate, là data được lưu lại trên hệ thống và ko chứa đối tượng nào bên trong

Facebook: email cũng ko thể chia nhỏ được nữa, nhưng SĐT thì trên thực tế sẽ tồn tại những facebook ko có SĐT mà chỉ có email => trường hợp này bạn cần chia nhỏ tiếp ra là Fb có sđt và ko có sđt. Ở bước này bạn cũng có thể cần phải confirm lại với BA và Dev xem mình có lấy thông tin SĐT của facebook lưu về hệ thống hay ko, nếu ko thì bỏ qua nhánh SĐT.

Bạn có thể thấy khi phân tích sẽ phát sinh ra những câu hỏi như thế này mà spec thường bỏ qua, trong TH này tôi ví dụ hệ thống sẽ lấy được SĐT của fb về hệ thống

Google account: cũng tương tự, bạn cần confirm có lấy được SĐT của email để lưu về hệ thống hay ko, giả sử trường hợp này hệ thống sẽ không lấy SĐT của google acc. Sau bước 3 tôi có như sau:

Vậy đến đây bạn nghĩ sẽ làm gì tiếp theo?

Lúc này các thuộc tính đã liệt kê ra hết thì chúng ta sẽ đi móc nối các mối quan hệ giữa 3 đối tượng tài khoản trên

B4: Xác định ràng buộc tôi sẽ có tiếp các nhánh con sau:

Tài khoản thường là tính năng đã hoàn thiện, tôi sẽ để lại làm cơ sở để xét ràng buộc cho 2 đối tượng còn lại là Facebook và Google Account

Nhìn vào đây, các bạn bắt đầu thấy sơ đồ bị phình to, khó nhìn, TH này hãy click vào Collapese Subtree trên menu bar để thu gọn lại, chỉ mở nhánh nào mà bạn cần phân tích tiếp

B5: Lúc này khi đã xác định được các ràng buộc có thể xảy ra => Bạn bắt đầu đi đến chi tiết, câu hỏi Q&A sẽ phát sinh khá nhiều ở bước này. Tôi sẽ đi phân tích cụ thể 1 nhánh Login với acc facebook mà có Email của facebook trùng với 1 email của tài khoản thường

Trường hợp này, khi phân tích ra sẽ có các câu hỏi.

2 đối tượng Acc thường và Acc Facebook đều có email và SĐT, nếu email trùng rồi nhưng SĐT có thể trùng hoặc ko trùng thì xử lý như thế nào?

=> bạn tiếp tục chia ra các nhánh để phân tích tiếp, cứ chia ra tất cả các trường hợp có thể xảy ra trước, phải liệt kê được hết, như TH này thì chỉ có thể là trùng hoặc k trùng, không có TH nào khác nữa thì bạn bắt đầu đặt ra câu hỏi

Nếu cả email trùng và SĐT trùng với tài khoản thường rồi có map luôn vào acc thường và lấy luôn data của acc thường?

Trong trường hợp này bạn cần xét tiếp đặc điểm của hệ thống là gì?

Có nên lấy data của acc đã tồn tại hay tách ra thành 1 acc hoàn toàn mới?

Nếu tách ra acc mới mà hệ thống lại k cho phép 2 tk trùng email và sđt thì có hợp lệ ko? Nếu map vào tài khoản thường thì ví dụ cả tk thường mà cả tk thường và acc Fb đều có ảnh đại diện, full name thì lấy ảnh của cái nào? ....vv

=> đây chính là tập câu hỏi Q&A mà bạn cần gửi sau khi đã tiến hành phân tích, bài toán này tôi ví dụ sẽ map vào tk thường và lấy toàn bộ data của tk thường

Sau bước này, bạn đã có thể nhìn thấy mình có các TC nào và kết quả mong muốn là gì, bạn sẽ tiếp tục cho đến khi các nhánh này không thể chia nhỏ được hơn nữa, ví dụ: nếu sau khi map vào tk thường rồi mà tôi lên facebook update email hoặc số điện thoại thì sẽ xử lý tiếp như thế nào? ....càng đi phân tích sâu sẽ có càng nhiều câu hỏi được đặt ra để đảm bảo rằng mình đã len lỏi được các ngõ ngách, trường hợp có thể xảy ra

=> Lúc này bạn có thể khá chắc chắn rằng mình đã hiểu spec được khá sâu và rộng

Tương tự với các nhánh khác bạn cũng phân tích đi từng bước như vậy, và tiêu chí quyết định ở đây là bạn cần phải xác định được hết tất cả các đối tượng ở bước trước rồi mới đi phân tích tiếp

Như ví dụ trên, nếu bạn liệt kê thiếu thuộc tính Email của facebook => bạn sẽ miss toàn bộ các trường hợp và cả cụm thông tin phía sau

Thực tế bài toán này yêu cầu rất ngắn gọn nhưng khi phân tích ra sẽ là một sơ đồ khổng lồ rất nhiều case và trường hợp có thể xảy ra, dựa vào các bước và lối đi như tôi đã phân tích ví dụ ở trên bạn có thể thực hành và thấy rõ hơn. tùy thuộc vào yêu cầu mà khách hàng đưa ra cho team của bạn

Có thể bài viết này chưa đủ để khiến bạn thay đổi mindset về việc phân tích, nhưng nếu áp dụng nó cho nhiều bài toán tư duy của bạn sẽ nhạy bén hơn rất nhiều Hy vọng nó hữu ích với bạn.