Làm thế nào để thực hiện kiểm thử nếu không có tài liệu đặc tả?

Requirement là 1 phần không thể thiếu hụt của dự án, không chỉ có giúp nhóm kỹ thuật cải cách và phát triển các tính năng, hình ảnh một phương pháp đúng hướng; mà còn giúp tester/ QA thực hiện công đoạn test một giải pháp trơn tru, chuyển giao được thành phầm đúng yêu thương cầu. Vậy những vấn đề thường gặp mặt với requirement là gì với tester/ QA cần xử lý thế nào với những trường hợp đó? thuộc bboomersbar.com Asia “giải mã” nhé!

I. Giới thiệu

*

Requirement được biết lý tưởng khi nó:

Đầy đủRõ ràngChính xácNhất quán

→ Requirement “lý tưởng” như trên để giúp đỡ cho công việc trở nên tiện lợi và tác dụng hơn cực kỳ nhiều! Đặc biệt, đối với các bạn QA, việc giành được requirement “lý tưởng” giống như một “bữa nạp năng lượng thịnh soạn” vậy, nó hỗ trợ cho họ thuận lợi hơn trong việc phân tích requirement, gửi ra quan điểm test, chế tạo ra tài liệu kiến thiết test case, thử nghiệm một cách chuẩn xác nhất,… mà không hẳn phân vân điều gì. Sản phẩm được chế tạo ra đảm bảo an toàn được hóa học lượng, phù hợp yêu cầu, mong muốn đợi của khách hàng. Mặc dù nhiên, chỉ tất cả số ít dự án đạt được đk requirement lý tưởng trên. Thông thường các bạn sẽ gặp rất nhiều trường vừa lòng sau:

Không bao gồm requirementRequirement mơ hồRequirement không thống nhấtRequirement bị biến hóa liên tụcRequirement đã cũ

→ Vậy các bạn sẽ giải quyết những sự việc đó như thế nào? họ cùng nhau đi tìm kiếm câu trả lời cho từng vấn đề nhé!!!

II. Giải quyết và xử lý vấn đề 1. Không có requirement

*

Ví dụ: người tiêu dùng đã có sẵn một áp dụng trên smartphone (SP) và hy vọng muốn trở nên tân tiến thành khối hệ thống trên trang web để fan dùng hoàn toàn có thể dễ dàng truy vấn và áp dụng nó.

Bạn đang xem: Làm thế nào để thực hiện kiểm thử nếu không có tài liệu đặc tả?

Khách mặt hàng giao task: Hãy thêm chức năng làm chủ lịch thao tác làm việc của nhân viên bên trên website y như bản SP.

→ ý kiến để thực hiện dự án này cần:

Đảm bảo được toàn cục logic từ vận dụng SP thanh lịch website.Phân tích vấn đề cần điều chỉnh một số trong những quan điểm (Ví dụ:GUI, chức năng…) để phù hợp với hệ thống website.

→ Đây là một trường hợp khó khăn, người sử dụng không đưa bất kể tài liệu tương quan nào, khiến cho QA chạm mặt rất những rắc rối, khó khăn và tốn những thời gian công sức để search hiểu, điều tra, gửi ra cách nhìn test, xây đắp test case,…Do đó ẩn chứa nhiều rủi ro khủng hoảng cao vào dự án, dẫn tới sự việc phát sinh những bug từ khách hàng,…

Giải pháp:

Hãy hỏi khách hàng về phần nhiều tài liệu tương quan đến nghiệp vụ, tài liệu kiến tạo có sẵn (SRS, UI/UX,…), kiểm tra case cũ,… Nếu không có bất kì tài liệu gì thì so với dự án như vậy này thì hệ thống/ áp dụng cũ đó là requirement.Hãy sử dụng tay nghề của chính mình, coi mình là một end user, khảo sát hệ thống để hiểu về logic, luồng hoạt động để đưa ra những luồng hoạt động và kết quả mong chờ đúng theo logic của khối hệ thống cũ, từ kia đặt câu hỏi cho khách hàng hàng cũng tương tự đưa ra những đề xuất, phương án buổi tối ưu cho khách hàng.Để bảo đảm an toàn các chuyển động logic của hệ thống cũ được đưa ra đầy đủ và chính xác nhất, yêu cầu phải thao tác nhiều với khối hệ thống và áp dụng nhiều loại data, nghĩ về ra nhiều trường hợp theo nhiệm vụ của hệ thống. Tại sao là, ngoài những gì được thấy dễ dãi trên khối hệ thống thì bao hàm trường hợp, cần cóđiều khiếu nại data rất tinh vi thì bắt đầu tái hiện nay được.Có thể phụ thuộc tài liệu mock, basic design nhưng dev tạo ra để tham khảo, từ bỏ đó hoàn toàn có thể đưa ra các quan điểm test, xây dựng test case,… mặc dù chỉ phải xem những tài liệu đó như thể tài liệu tham khảo, vì nó đang chưa chắc đúng trả toàn, vẫn có thể chứa bug. Trong quá trình tìm hiểu, nếu như phát hiện điểm bất hợp lý thì đề xuất confirm ngay chớp nhoáng với những thành viên vào team và với khách hàng.Đặc biệt, nếu QA có thể đọc phát âm được source code của hệ thống/ áp dụng có sẵn thì hoàn toàn có thể lấy được tương đối đầy đủ logic cách xử trí của khối hệ thống cũ. Trường đoản cú đó rất có thể tạo nên ý kiến test cho hệ thống/ vận dụng hiện tại, đưa ra được những trường hòa hợp test có thể xảy ra, hạn chế khủng hoảng nhất gồm thể. Kế bên ra, do ứng dụng vận động trên những môi trường không giống nhau nên đang dựa theo môi trường vận hành của khối hệ thống mới phối hợp kỹ năng test để mang ra thêm các quan điểm test, các test case phù hợp. Ví dụ về giao diện, những case theo những thuộc tính của item, môi trường thiên nhiên test, trang bị test…Có thể tiến hành test thăm dò, chạy thử ở số đông điểm hay hay tất cả lỗi xảy ra.Tổ chức những buổi meeting để cùng nhau thảo luận, confirm mức độ phát âm với toàn bộ thành viên vào team dự án, chia sẻ kiến thức về dự án,…

2. Requirement mơ hồ

*

Ví dụ: quý khách hàng đưa ra requirement như sau: Thêm tính năng upload image vào màn hình hiển thị thêm bắt đầu thông báo.

→ Một yêu cầu không rõ ràng, với không ít vấn đề được để ra, ví dụ như như: không biết image có định dạng như vậy nào, dung tích tối nhiều là bao nhiêu, trường hợp xẩy ra lỗi thì xử lý như vậy nào, hiển thị message gì,…

→ Khi người sử dụng đưa ra yêu ước mơ hồ, không rõ ràng, thiếu thông tin như vậy dẫn đến sự việc gây rất nhiều khó khăn trong bài toán xác nhận chính xác yêu cầu, muốn đợi từ bỏ phía khách hàng hàng. Giả dụ ngay từ trên đầu hiểu không đúng yêu cầu của bạn hoặc confirm không rõ ràng với khách hàng thì sẽ khá nguy hiểm, dẫn mang lại hiểu không đúng toàn bộ tính năng trong yêu thương cầu cũng như logic hoạt động, luồng cách xử lý của hệ thống/ứng dụng…Do đó tạo ra nhiều rủi ro khủng hoảng cao vào dự án.

Giải pháp:

Hãy thử tìm kiếm hiểu, xem thêm từ các hệ thống/ ứng dụng khác tương tự để hiểu được ngắn gọn xúc tích hoạt động, phương pháp xử lý khi thao tác làm việc với hệ thống/ ứng dụng đó hoặc có thể sử dụng gớm nghiệm, sự từng trải trong những dự án tự đó hỗ trợ cho các bạn có thể xác định logic, luồng làm cho việc, phân biệt những điểm hiện nay đang bị thiếu sót. Cần làm rõ, tự đó đặt ra tất cả câu hỏi, sự việc liên quan cũng như đưa ra đề xuất tương ứng mang đến khách hàng để làm rõ cùng hiểu đúng chuẩn nhất về yêu ước mà người tiêu dùng mong muốn.Tổ chức các cuộc họp cùng với những thành viên vào team để cùng nhau xem xét vấn đề gặp mặt phải cùng tìm hướng giải quyết. Trong buổi họp đó, mọi người dân có thể chia sẻ thông tin cơ mà mình đã mày mò được, từ bỏ đó cùng nhau thảo luận cũng như xác nhận mức độ phát âm của toàn bộ thành viên, tiếp nối cùng nhau coi xét list Q&A trước đưa sang phía khách hàng để gia công rõ hơn yêu cầu.

3. Requirement ko thống nhất

*

Ví dụ: khách hàng đưa ra yêu cầu sau: – Yêu mong 1: User là Admin, Editor của tổ chức triển khai thì tất cả quyền truy vấn đến màn hình quản lý tổ chức. Đối cùng với User là Viewer, Guest khi truy cập thì đưa đến màn hình lỗi 403. – Yêu cầu 2: Trường đúng theo user là Admin, Editor khi truy cập vào màn hình quản lý tổ chức thì hiển thị button Thêm new tổ chức. Trường thích hợp user là Viewer, Guest khi truy cập vào màn hình làm chủ tổ chức thì button Thêm mới tổ chức có khả năng sẽ bị ẩn đi.

Xem thêm: Bộ Đề Thi Văn Học Kỳ 1 Lớp 2 Năm 2021, Bộ Đề Thi Học Kì 1 Môn Tiếng Việt Lớp 2 Năm 2021

→ Requirement của người sử dụng đang bị xung hốt nhiên với nhau. Ở yêu mong 1 thì user là Viewer, Guest thì không được phép truy vấn đến màn hình quản lý tổ chức. Mặc dù nhiên, sinh sống yêu cầu 2 thì lại đang mô tả được cho phép user là Viewer, Guest truy vấn vào screen đó.

Giải pháp:

Hãy xem xét, phân tích, tấn công giá, chuyển ra ý kiến về từng yêu cầu đó, đặt mình ở chỗ là end-user để đưa ra ngắn gọn xúc tích xử lý, luồng vận động hợp lý, từ kia chỉ ra phần lớn điểm bất đúng theo lý, xích míc hoặc chưa tương xứng trong những yêu cầu đó, từ bỏ đó chuyển ra phương án tối ưu, liền kề với thực tế và phù hợp nhất với ao ước đợi của người dùng.Chỉ rõ sự xung đột nhiên này với khách hàng bằng cách phân tích rõ từng yêu cầu, chỉ ra phần đa điểm bất phù hợp lý, mâu thuẫn hoặc chưa phù hợp, từ bỏ đó gửi ra khuyến nghị với người sử dụng theo hướng cơ mà mình ý định làm.

4. Requirement bị thay đổi liên tục

*

Trong mỗi dự án, việc khách hàng biến đổi yêu cầu liên tục là điều cực nhọc tránh khỏi, là chuyện “cơm bữa” của cả team dự án. Riêng so với chị em QA thì sẽ là cả một quá trình, nhiều lúc khách sản phẩm chỉ update lại một địa điểm nhỏ, đôi khi chúng ta dev chỉ thêm/sửa/xóa một chiếc code nhưng mẹ QA nên sửa lại toàn thể test case, demo lại tổng thể chức năng, screen đã test hoàn thành trước đó.

Giải pháp:

Trong quy trình tiến độ phân tích yêu thương cầu, khi phát hiện thấy những điểm bất thường, chưa hợp lý… thì nên confirm với người sử dụng ngay lập tức, nếu có thể hãy đưa ra các lời khuyên về hướng xử lý cho khách hàng hàng, nhằm mục đích giảm thiểu không nên sót ngay lập tức từ quy trình đầu và né tránh dẫn mang lại nhiều biến đổi sau này.Khi có bất kì một sự đổi khác nào từ phía quý khách hàng thì hãy tổ chức triển khai các cuộc họp để các thành viên vào team cùng cầm được vấn đề, cùng mọi người trong nhà đánh giá, so sánh về yêu thương cầu đổi khác để xem nó có đúng chuẩn và phải chăng hay không, điều tra, phân tích về nấc độ hình ảnh hưởng.Update tài liệu thử nghiệm ngay sau khoản thời gian yêu cầu biến hóa đã được xác thực để bảo đảm an toàn test case đúng với yêu cầu tiên tiến nhất của khách hàng.

5. Requirement vẫn cũ

*

Giải pháp:

Hãy kiểm tra toàn bộ tài liệu tương quan được sản xuất vào thời hạn nào, hãy confirm với quý khách hàng xem đó liệu có phải là phiên phiên bản mới tuyệt nhất hay chưa. Ví như đã tất cả sẵn hệ thống/ứng dụng thì hãy đối chiếu với những thông tin gồm trong tài liệu, từ kia xem xét thông tin nào có thể sử dụng.Confirm với người tiêu dùng để họ rất có thể cung cấp tài liệu, thông tin tiên tiến nhất hoặc hoàn toàn có thể update lại tài liệu cho mình hay không.

III. Kết luận

Những chiến thuật cho từng trường phù hợp trên là kinh nghiệm tay nghề của bạn dạng thân mình đã có được trong quy trình làm dự án, cũng giống như học hỏi từ kinh nghiệm thao tác làm việc của các anh chị đi trước. Nó góp phần hạn chế được những rủi ro, gần như lỗi không muốn trong dự án, góp cho dự án công trình đạt rất chất lượng nhất, thỏa mãn nhu cầu được yêu cầu, sự chấp nhận của khách hàng.

Trong quá trình thao tác với dự án, bạn sẽ phải chạm chán nhiều trường hợp, tình huống khó khăn, éo le và bắt buộc chúng ta phải kiếm tìm hướng xử lý và ham mê nghi cùng với nó. Mặc dù trong ngôi trường hợp ra sao đi chăng nữa, các bạn cũng cần bình tĩnh coi xét, so sánh kĩ vấn đề, đưa ra hướng giải quyết và xử lý hợp lý để đã đạt được mục tiêu sau cuối là phát triển dự án và bảo đảm được chất lượng tốt nhất cho sản phẩm.

 Trần Tươi – bboomersbar.com ASIA