CHAPTER 1: Fundamentals of Testing ( Part 2)

January 3, 2020 - admin

No Comments

1.4 Fundamental test process – Quy trình và giai đoạn kiểm thử phần mềm

quy trình test kiểm thử phần mềm

1.4.1 Test Planning and Control (K1)

  1. Test planning

Definition:

Test planning is the activity of defining the objectives of testing and the specification of test activities in order to meet the objectives and mission.

Lập kế hoạch test là hoạt động xác định mục tiêu của việc test và chỉ rõ các hoạt động test để đạt được mục tiêu và trọng tâm

Major task:

  • Determine the scope and risks and identify the objectives of testing – Xác định phạm vi, rủi ro và mục tiêu của testing
  • Determine the test approach ( techniques, test items, coverage, identifying and interfacing with the teams involve in testing) – Xác định phương pháp tiếp cận test ( kỹ thuật, các mục test, tỷ lệ bao phủ, xác định và giao tiếp giữa các đội tham gia vào test)
  • Implement test policy and/or test strategy – Triển khai chính sách và/ hoặc chiến lược test
  • Determine the required test resources ( people, environment, PCs, tool…)- Xác định các nguồn lực cần thiết ( con người, môi trường, PC, công cụ)
  • Schedule test analysis and design tasks, test implementation, execution and evaluation- Lập lịch trình cho các giai đoạn sau
  • Determine the exist criteria- Xác định các tiêu chí kết thúc

Terms:

  • Test policy: A high level document describing the principle, approach and major objectives of organization regarding testing- Chính sách test là 1 tài liệu mức cao thường mô tả nguyên tắc, hướng tiếp cận, mục tiêu chính của testing trong 1 tổ chức
  • Test strategy: A high level description of the test types to performed – Chiến lược test là mô tả mức cao của các loại test được triển khai một cách thông minh để đạt được mục tiêu
  • Test ware: includes test cases, test plan, test data, etc – Tài sản test bao gồm test case, KH test, dữ liệu,..
  • Test approach: The implementation of the test strategy for a specific project – Phương pháp test là triển khai cụ thể của chiến lược test cho 1 dự án
  1. Test control

Definition

  • Test control is the ongoing activity of comparing actual progress against the plan, and reporting the status, including deviations from the plan.

Kiểm soát test là hoạt động diễn ra liên tục để so sánh giữa tiến độ thực tế và kế hoạch, báo cáo trạng thái ( gồm cả những cái lệch so với KH).

  • It involves taking actions necessary to meet the mission and objectives of the project.

Kiểm soát test phải đưa ra được các hành động cần thiết để đạt được mục tiêu của dự án.

  • In order to control testing, the testing activities should be monitored throughout the project.

Các hoạt động kiểm soát test được thực hiện và kiểm tra suốt cả dự án

  • Test planning takes into account the feedback from monitoring and control activities. – KH test phải được cập nhật phù hợp với những hoạt động điều hành và kiểm soát

Major tasks:

  • Measure and analysis the results of reviews and testing – Đo đạc và phân tích kết quả của hoạt động review và test
  • Monitor and document progress, test coverage and exit criteria – Theo dõi và ghi chép tiến độ, độ bao phủ test, tiêu chí kết thúc
  • Provide information of testing to make evaluation – Cung cấp thông tin của test cho việc lựa chọn, đánh giá
  • Initiation corrective actions – Đưa ra các hành động khắc phục, sửa chữa
  • Make decisions- Ra quết định

 1.4.2 Test Analysis and Design (K1)

Definition:

Test analysis and design is the activity during which general testing objectives are transformed into tangible test conditions and test cases.

Phân tích và thiết kế test dựa vào các mục tiêu test để chuyển đổi thành các điều kiện test và test case

Major tasks

  • Reviewing the test basis (such as requirements, software integrity level1 (risk level), risk analysis reports, architecture, design, interface specifications) – Xem xét các cơ sở cho test ( yêu cầu, các rủi ro, báo cáo phân tích rủi ro, kiến trúc, thiết kế, đặc tả giao diện)
  • Evaluating testability of the test basis and test objects – Đánh giá khả năng test của test basic và các đối tượng test
  • Identifying and prioritizing test conditions based on analysis of test items, the specification, behavior and structure of the software – Xác định và sắp xếp thứ tự ưu tiên của các điều kiện test dựa vào phân tích các test items, đặc tả, hiệu ứng và cấu trúc của PM.
  • Designing and prioritizing high level test cases – Thiết kế và sắp xếp thứ tự ưu tiên của Test case
  • Identifying necessary test data to support the test conditions and test cases – Xác định các dữ liệu test để phục vụ cho test conditions and test cases
  • Designing the test environment setup and identifying any required infrastructure and tools – Xác định môi trường test cần thiết lập và các yêu cầu về hạ tầng, công cụ
  • Creating bi-directional traceability between test basis and test cases- Tạo ma trận theo dõi 2 chiều giữa test basic và test cacses.

1.4.3 Test Implementation and Execution (K1)

Definition

Test implementation and execution is the activity where test procedures or scripts are specified by combining the test cases in a particular order and including any other information needed for test execution, the environment is set up and the tests are run. Thực hiện test và chạy test là hoạt động  xây dựng các thủ tục test được chỉ rõ bằng việc kết hợp giữa các test case và các thông tin cần thiết khác cho việc thực hiện test, thiết lập môi trường test và chạy test

Major tasks:

  • Finalizing, implementing and prioritizing test cases (including the identification of test data) – Chuẩn hoá, xây dựng và sắp xếp ưu tiên test case ( bao gồm cả xác định test data)
  • Developing and prioritizing test procedures, creating test data and, optionally, preparing test harnesses and writing automated test scripts – Xây dựng và ưu tiên các thủ tục test, tạo test data, chuẩn bị thủ tục và viết test scripts tự động test
  • Creating test suites from the test procedures for efficient test execution – Tạo bộ test suites từ thủ tục test cho việc chạy test hiệu quả
  • Verifying that the test environment has been set up correctly – Kiểm tra các môi trường được thiết lập đúng chưa
  • Verifying and updating bi-directional traceability between the test basis and test cases – Kiểm tra và cập nhật ma trận theo dõi test basic và test cases
  • Executing test procedures either manually or by using test execution tools, according to the planned sequence – Chạy các thủ tục test bằng tay hoặc tự động bằng tool
  • Logging the outcome of test execution and recording the identities and versions of the software under test, test tools and testware – Ghi nhận kết quả chạy test và các vấn đề phát hiện được, phiên bản được test, công cụ test và tài sản test
  • Comparing actual results with expected results – So sánh kết quả thực tế và kết quả mong đợi
  • Reporting discrepancies as incidents and analyzing them in order to establish their cause (e.g., a defect in the code, in specified test data, in the test document, or a mistake in the way the test was executed) – Báo cáo lỗi và phân tích chúng để tìm ra nguyên nhân( lỗi trong code, trong test data, trong tài liệu test hoặc sai ở cách thực hiện test)
  • Repeating test activities in order to confirm a fix (confirmation testing), execution of a corrected test and/or execution of tests in order to ensure that defects have not been introduced in unchanged areas of the software or that defect fixing did not uncover other defects (regression testing) – Lặp lại các hoạt động test để xác nhận các sửa lỗi là phù hợp ( re-test), kiểm tra những phần xung quanh không xảy ra lỗi nữa ( regression test)

1.4.4 Evaluating Exit Criteria and Reporting (K1)

Definition

Evaluating exit criteria is the activity where test execution is assessed against the defined objectives. This should be done for each test level

Đánh giá tiêu chí kết thúc được thực hiện khi việc chạy test đã đạt được đến mục tiêu trong kế hoạch, nó nên được làm ở mỗi level của test

Major tasks

  • Checking test logs against the exit criteria specified in test planning – Kiểm tra các kết quả test với các tiêu chí kết thúc trong KH
  • Assessing if more tests are needed or if the exit criteria specified should be changed- Đánh giá xem có cần phải test them nữa ko hoặc phải sửa exit criteria ko
  • Writing a test summary report for stakeholders – Viết báo cáo test gửi nhà đầu tư

1.4.5 Test Closure Activities (K1)

Definition

  • Test closure activities collect data from completed test activities to consolidate experience, testware, facts and numbers.

Là hoạt động thu thập dữ liệu từ các hoạt động test đã hoàn thành để tập trung lại các kinh nghiệm, tài sản test.

  • Test closure activities occur at project milestones such as when a software system is released, a test project is completed (or cancelled), a milestone has been achieved, or a maintenance release has been completed.

Hoạt động này diễn ra ở mỗi giai đoạn của dự án, khi HT được phát hành hoặc khi dự án test hoàn thành, giai đoạn kết thúc, phát hành sản phẩm

Major tasks:

  • Checking which planned deliverables have been delivered – Kiểm tra các SP được lên KH phát hành đã phát hành chưa
  • Closing incident reports or raising change records for any that remain open – Đóng các báo cáo lỗi hoặc nâng cao các ghi chú thay đổi cho phần còn xót lại
  • Documenting the acceptance of the system – Tài liệu hoá chấp nhận HT của KH
  • Finalizing and archiving testware, the test environment and the test infrastructure for later reuse – Hoàn thiện và thu hồi tài sản test, môi trường và hạ tầng việc tái sử dụng
  • Handing over the testware to the maintenance organization – Bàn giao tài sản test cho tổ chức
  • Analyzing lessons learned to determine changes needed for future releases and projects – Phân tích các bài học kinh nghiệm để xác định các thay đổi cần thiết cho các ban hành trong tương lai hoặc dự án khác
  • Using the information gathered to improve test maturity – Sử dụng các thông tin thu thập để cải tiến hoạt động test

1.5 Psychology of testing -Khía cạnh khác của kiểm thử phần mềm

1.5.1 Level of independence – Các mức độ độc lập trong kiểm thử

A certain degree of independence often makes the tester more effective at finding defects and failures- Mức độ độc lập của test giúp tăng hiệu quả của việc tìm lỗi và failures

  • None: tests designed by the person who wrote the software – Các TH Test không được xây dựng bởi người viết ra phần mềm
  • Tests designed by a different person – Test phải đc xây dựng bởi người khác
  • Tests designed by someone from a different department or team ( e.g test team) – Test cần được xây dựng bởi người từ những phòng ban khác ( đội tester)
  • Tests designed by someone from a different organisation ( e.g agency) – Test cần được xây dựng bởi người từ những tổ chức khác ( đại lý)

1.5.2 Why do we sometimes not get on with the rest of the team?- Giao tiếp với phần còn lại của dự án

  • Identifying failures during testing may be perceived as criticism against the product and against the author. As a result, testing is often seen as a destructive activity, even though it is very constructive in the management of product risks.

Việc chỉ ra lỗi được nhiều đối tượng coi như là 1 hành động chỉ trích đến sản phẩm và tác giả. Vì thế mà test thường bị coi là hoạt động phá hoại, ngay cả khi đó là 1 hoạt động mang tính xây dựng trong quản lý rủi ro,

 

  • Looking for failures in a system requires curiosity, professional pessimism, a critical eye, attention to detail, good communication with development peers, and experience on which to base error guessing.

Để tìm ra lỗi trong phần mềm yêu cầu cần phải có sự tò mò, bi quan, con mắt nghiêm trọng, tập trung vào chi tiết, giao tiếp tốt với các nhóm phát triển và có kinh nghiệm để dự đoán được lỗi

  • The tester and test leader need good interpersonal skills to communicate factual information about defects, progress and risks in a constructive way.

Tester và test leader cần có kỹ năng giao tiếp tốt  để trao đổi về các thông tin thực tế của lỗi, tiến độ, rủi ro trên tinh thần xây dựng

  • Communicate findings on the product in a neutral (fashion neutral, objectively), fact-focused way without criticizing the person who created it.

Giao tiếp những điểm tìm được về sản phẩm 1 cách khách quan, tập trung vào thực tế mà ko có sự thù ghét cá nhân.

  • Explain that by knowing about this now we can work round it or fix it so the delivered system is better for the customer.

Giải thích bằng các hiểu biết về những gì chúng ta phải làm gì với nó hoặc sửa nó cho bản gửi KH tốt hơn.

  • Start with collaboration rather than battles. Remind everyone of the common goal of better quality systems.

Khởi đầu bằng sự hợp tác ko phải là trận chiến. Luôn nhắc mọi người về mục tiêu chung là giúp hệ thống đạt chất lượng tốt hơn

 

 

 

admin

Leave a comment

Your email address will not be published. Required fields are marked *