In software engineering, the software development process (also known as the software development life cycle) is the name given to the workflow for the activities, actions, and tasks required to create software systems. As introduced in Chapter 6, From Requirements to Test Cases, the usual phases in any software development process are:

• Definition of what: Requirements elicitation, analysis and use case modeling.
• Definition of how: The system architecture and modeling of structural and behavioral diagrams.
• The actual software development (coding).
• The set of activities that makes the software available for use (release, installation, activation, and so on).

The timing in which tests are designed and implemented in the overall software development process results in different test methodologies, namely (see diagram after the list):

• Behavior-Driven Development (BDD): At the beginning of the analysis phase, conversations between the software consumer (final user or costumer) and some of the development team (typically, project leader, manager, or analysts) took place. These conversations are used to concretize scenarios (that is, concrete examples to build up a common understanding of the system features). These examples form the basis to develop acceptance tests using tools such as Cucumber (for more details about it, take a look to Chapter 5, Integration of JUnit 5 with external frameworks.) The description of acceptance tests in BDD (for example, using Gherkin in Cucumber) produces both automated tests and documentation that accurately describe the application features. The BDD approach is naturally aligned with iterative or Agile methodologies, since it is very difficult to define requirements upfront, and these evolve as the team learns more about the project.

• Test-Driven Development (TDD): TDD is a methodology in which tests are designed and implemented before the actual software design. The idea is to convert the requirements obtained in the analysis stage to specific test cases. Then, the software is designed and implemented to pass these tests. TDD is part of the XP methodology.
• Test-First Development (TFD): In this methodology, tests are implemented after the design stage, but before the actual implementation of the SUT. This allows to assure that the software units have been understood correctly before its actual implementation. This methodology is followed in the Unified Process, which is a popular iterative and incremental software development process. The Rational Unified Process (RUP) is a well-known framework implementation of the Unified Process. In addition to TFD, RUP also supports other methodologies such as TDD and TLD.

• Test-Last Development (TLD): In this methodology, the implementation of the test is carried out after the implementation of the actual software (SUT). This test methodology is followed by classic software development processes, such as waterfall (sequential), incremental (multi-waterfall) or spiral (risk-oriented multi-waterfall).

Regarding who is responsible for coding the tests, there is a universally accepted consensus. It is broadly recommended that unit tests should be written by SUT developers. In some cases, especially in small teams, these developers are also responsible for other kinds of tests.

In addition, the role of an independent test group (often called testers or a QA team) is also a common practice, especially in large teams. One of the objective of this role separation is to remove the conflict of interests that may be present otherwise. We cannot forget that testing is understood as a destructive activity from a physiological point of view (the objective is finding defects). This independent test group is usually in charge on the integration, system, and non-functional tests. In this case, both groups of engineers should work closely; while tests are conducted, developers should be available to correct faults and minimize future errors.

Finally, high-level acceptance tests are usually conducted in heterogeneous groups involving non-programmers (customers, business analysis, managers, and so on) together with software engineers or testers (for example, for implement the step definition in Cucumber).