Steps for Software Testing Process

Step 1: Asses Development Plan and Status

This first step is a prerequisite to building the VV&T Plan used to evaluate the implemented software solution. During this step, testers challenge the completeness and correctness of the development plan. Based on the extensiveness and completeness of the Project Plan the testers can estimate the amount of resources they will need to test the implemented software solution.

Step 2: Develop the Test Plan

Forming the plan for testing will follow the same pattern as any software planning process. The structure of all plans should be the same, but the content will vary based on the degree of risk the testers perceive as associated with the software being developed.

Step 3: Test Software Requirements
Incomplete, inaccurate, or inconsistent requirements lead to most software failures. The inability to get requirement right during the requirements gathering phase can also increase the cost of implementation significantly. Testers, through verification, must determine that the requirements are accurate, complete, and they do not conflict with another.

Step 4: Test Software Design
This step tests both external and internal design primarily through verification techniques. The testers are concerned that the design will achieve the objectives of the requirements, as well as the design being effective and efficient on the designated hardware.

Step 5: Program (Build) Phase Testing
The method chosen to build the software from the internal design document will determine the type and extensiveness of the testers needed. As the construction becomes more automated, less testing will be required during this phase. However, if software is constructed using the waterfall process, it is subject to error and should be verified. Experience has shown that it is significantly cheaper to identify defects during the construction phase, than through dynamic testing during the test execution step.

Step 6: Execute and Record Result
This involves the testing of code in a dynamic state. The approach, methods, and tools specified in the test plan will be used to validate that the executable code in fact meets the stated software requirements, and the structural specifications of the design.

Step 7: Acceptance Test
Acceptance testing enables users to evaluate the applicability and usability of the software in performing their day-to-day job functions. This tests what the user believes the software should perform, as opposed to what the documented requirements state the software should perform.

Step 8: Report Test Results
Test reporting is a continuous process. It may be both oral and written. It is important that defects and concerns be reported to the appropriate parties as early as possible, so that corrections can be made at the lowest possible cost.

Step 9: The Software Installation
Once the test team has confirmed that the software is ready for production use, the ability to execute that software in a production environment should be tested. This tests the interface to operating software, related software, and operating procedures.

Step 10: Test Software Changes
While this is shown as Step 10, in the context of performing maintenance after the software is implemented, the concept is also applicable to changes throughout the implementation process. Whenever requirements changes, the test plan must change, and the impact of that change on software systems must be tested and evaluate.

Step 11: Evaluate Test Effectiveness
Testing improvement can best be achieved by evaluating the effectiveness of testing at the end of each software test assignment. While this assessment is primarily performed by the testers, it should involve the developers, users of the software, and quality assurance professionals if the function exists in the IT organization.

翻譯：

軟件測(cè)試的11個(gè)步驟

第一步：評(píng)定開(kāi)發(fā)方案和狀態(tài)

這第一步是創(chuàng)建W＆T計(jì)劃的先決條件，W＆T計(jì)劃用于評(píng)估執(zhí)行的軟件解決方案。在這一步，測(cè)試員可質(zhì)疑開(kāi)發(fā)方案的完整性和正確性。并且基于項(xiàng)目計(jì)劃的完整和延伸定義，測(cè)試員要估計(jì)出測(cè)試這個(gè)執(zhí)行的軟件解決方案所需要的資源數(shù)量。

第二步：形成測(cè)試計(jì)劃

形成測(cè)試計(jì)劃應(yīng)該要符合軟件開(kāi)發(fā)過(guò)程的模式，所有計(jì)劃的結(jié)構(gòu)應(yīng)該是一樣的，內(nèi)容則要基于測(cè)試員對(duì)開(kāi)發(fā)中的項(xiàng)目的感知程度。

第三步：測(cè)試軟件的需求說(shuō)明

不完整的，不正確的，或不一致的要求都會(huì)導(dǎo)致軟件開(kāi)發(fā)失敗。 在需求收集階段，不正確說(shuō)明軟件需求，會(huì)明顯的增加開(kāi)發(fā)費(fèi)用。 測(cè)試員通過(guò)查證，一定要保證需求說(shuō)明的是正確的，完整的，并且不會(huì)有沖突。

第四步：測(cè)試軟件的設(shè)計(jì)

這一步測(cè)試員首先要能過(guò)查證技術(shù)測(cè)試軟件的外部和內(nèi)部設(shè)計(jì)，測(cè)試設(shè)計(jì)是否能完成需求說(shuō)明的目標(biāo)和這些設(shè)計(jì)能否在指定的硬件上起作用。

第五步：軟件開(kāi)發(fā)過(guò)程中的測(cè)試

根據(jù)內(nèi)部設(shè)計(jì)文檔選擇的軟件開(kāi)發(fā)方法將會(huì)決定測(cè)試員測(cè)試需要的類型和范圍。因?yàn)檐浖?gòu)建變得更加自動(dòng)化，所以這一階段要求相對(duì)少的測(cè)試，不過(guò)，如果軟件采用瀑布型的開(kāi)發(fā)模式，容易產(chǎn)生錯(cuò)誤，這些錯(cuò)誤應(yīng)該被發(fā)現(xiàn)。經(jīng)驗(yàn)表明，在構(gòu)建階段發(fā)現(xiàn)問(wèn)題會(huì)比在動(dòng)態(tài)測(cè)試過(guò)程發(fā)現(xiàn)問(wèn)題節(jié)省很多成本

第六步：執(zhí)行和記錄錯(cuò)誤

這個(gè)階段包括在動(dòng)態(tài)狀態(tài)測(cè)試代碼，在測(cè)試計(jì)劃中指定的步驟，方法，工具會(huì)被用于驗(yàn)證可執(zhí)行代碼是否符合規(guī)定的軟件需求和設(shè)計(jì)的結(jié)構(gòu)化規(guī)范

第七步：可接受性測(cè)試

可接受性測(cè)試能讓使用者在操作他們的日常工作所需功能時(shí)評(píng)估軟件的適用性和可用性。這樣能測(cè)試出使用者認(rèn)為軟件應(yīng)該實(shí)現(xiàn)什么功能，與需求文檔的中說(shuō)明的軟件應(yīng)該實(shí)現(xiàn)什么功能形成對(duì)照

第八步：報(bào)告測(cè)試結(jié)果

測(cè)試報(bào)告是一個(gè)持續(xù)的過(guò)程，可口頭表達(dá)也可記錄下來(lái)。 缺陷和涉及的問(wèn)題要向相應(yīng)的小組報(bào)告，并且報(bào)告要易于理解，這一點(diǎn)很重要。這樣就能以最低的可能成本修正問(wèn)題

第十步：測(cè)試軟件變化

當(dāng)進(jìn)行到第十步，是軟件被安裝使用后的維護(hù)過(guò)程。相關(guān)概念隨著整個(gè)執(zhí)行過(guò)程而改變，任何時(shí)候需求改變了，測(cè)試計(jì)劃也要相應(yīng)改變，并且這些改變對(duì)于整個(gè)軟件的影響也要測(cè)試和評(píng)估。

第十一步：評(píng)估測(cè)試效率