Editing Software testing (section)

=== Processes ===

Organizations that develop software, perform testing differently, but there are common patterns.<ref name="pan" />

==== Waterfall development ====

{{further|Capability Maturity Model Integration|Waterfall model}}

In [[waterfall model|waterfall development]], testing is generally performed after the code is completed, but before the product is shipped to the customer.<ref>{{Cite web |title=Software Testing Lifecycle |url=http://www.etestinghub.com/testing_lifecycles.php#2 |access-date=January 13, 2012 |website=etestinghub |at=Testing Phase in Software Testing}}</ref> This practice often results in the testing phase being used as a [[project management|project]] buffer to compensate for project delays, thereby compromising the time devoted to testing.<ref name="Myers 1979" />{{rp|145–146}}

Some contend that the waterfall process allows for testing to start when the development project starts and to be a continuous process until the project finishes.<ref>{{Cite book |last=Dustin |first=Elfriede |url=https://books.google.com/books?id=K0qWBUOAf6IC&pg=PA3 |title=Effective Software Testing |publisher=Addison-Wesley Professional |year=2002 |isbn=978-0-201-79429-8 |page=3}}</ref>

==== Agile development ====

[[Agile software development]] commonly involves testing while the code is being written and organizing teams with both programmers and testers and with team members performing both programming and testing.

One agile practice, [[Test-driven development|test-driven software development]] (TDD), is a way of [[unit testing]] such that unit-level testing is performed while writing the product code.<ref name="AgileAllianceTDD">{{Cite web |date=December 5, 2015 |title=What is Test Driven Development (TDD)? |url=https://www.agilealliance.org/glossary/tdd/ |access-date=March 17, 2018 |website=Agile Alliance}}</ref> Test code is updated as new features are added and failure conditions are discovered (bugs fixed). Commonly, the unit test code is maintained with the project code, integrated in the build process, and run on each build and as part of regression testing. Goals of this [[continuous integration]] is to support development and reduce defects.<ref>{{Cite web |title=Test-Driven Development and Continuous Integration for Mobile Applications |url=https://msdn.microsoft.com/en-us/library/bb985498.aspx#_Continuous_Integration |access-date=March 17, 2018 |website=Microsoft Developer Network|date=January 14, 2009 }}</ref><ref name="AgileAllianceTDD" />

Even in organizations that separate teams by programming and testing functions, many often have the programmers perform [[unit testing]].<ref>{{Cite book |last1=Brown |first1=Chris |url=http://www.informit.com/articles/article.aspx?p=26320&seqNum=6 |title=Introduction to Rapid Software Testing |last2=Cobb |first2=Gary |last3=Culbertson |first3=Robert |date=April 12, 2002}}</ref>

==== Sample process ====

The sample below is common for waterfall development. The same activities are commonly found in other development models, but might be described differently.

* [[Requirements analysis]]: testing should begin in the requirements phase of the [[software development life cycle]]. During the design phase, testers work to determine what aspects of a design are testable and with what parameters those tests work.
* Test planning: [[test strategy]], [[test plan]], [[testbed]] creation. Since many activities will be carried out during testing, a plan is needed.
* Test development: test procedures, [[Scenario test|test scenarios]], [[test case]]s, test datasets, test scripts to use in testing software.
* Test execution: testers execute the software based on the plans and test documents then report any errors found to the development team. This part could be complex when running tests with a lack of programming knowledge.
* Test reporting: once testing is completed, testers generate metrics and make final reports on their [[test effort]] and whether or not the software tested is ready for release.
* Test result analysis: or ''defect analysis'', is done by the development team usually along with the client, in order to decide what defects should be assigned, fixed, rejected (i.e. found software working properly) or deferred to be dealt with later.
* Defect retesting: once a defect has been dealt with by the development team, it is retested by the testing team.
* [[Regression testing]]: it is common to have a small test program built of a subset of tests, for each integration of new, modified, or fixed software, in order to ensure that the latest delivery has not ruined anything and that the software product as a whole is still working correctly.
* Test closure: once the test meets the exit criteria, the activities such as capturing the key outputs, lessons learned, results, logs, documents related to the project are archived and used as a reference for future projects.