Ever since the first software was conceived, there was an immediate need for certain methodologies to follow to create further software. Calling the process of creating and maintaining software “Software Development” was not enough, as there were a lot to process and familiarize with. Software Development includes all the different processes that are involved from conception of the desired software to the final product. The main processes are: thought process, research, design, programming, documenting, testing and bug fixing. Some of these processes may be repeated to maintain the software.

Over the years, there have been an abundance of approaches to software development known as “software life cycle models”, “methodologies”, “processes” or “models”. The methodologies that have been used throughout time are:

• Waterfall Model
• V model
• Spiral
• Prototyping
• Incremental
• Clean room
• Agile

Waterfall Model

Waterfall Model, also considered to be the “traditional development” model follows a top-down approach to carrying out different processes. It’s basically a relatively linear sequential design approach. The original phases this methodology has are system and software requirements, analysis, design, coding, testing, operations and maintenance.

The current phases are also further developed into: conception, initiation, analysis, design, construction, testing, deployment and maintenance. The Waterfall Model is such a linear methodology that it can be observed as an assembly line in a factory. Except of course when the product is ready but not tested in an assembly line. One can argue that since every phase follows another, it’s not too complex, therefore should be implemented to make the job easier. But that’s without considering the other properties this methodology has. This model is less iterative, less flexible and the progress can only flow in one direction. This means that without a phase is completed, the next phase can not take place, if there is a delay in a phase, the whole process gets delayed.

V Model

In V Model, the process is divided into two roads that are eventually connected at the Implementation phase. The development itself and the testing procedures are done parallelly, which takes less time than the Waterfall Model. V Model is basically the half-way bent version of the waterfall model. While it is still a sequential process, it provides more flexibility in the development phase when the product is realised to require another property, and it saves more time. The letter V in the V Model also comes from “Verification” and “Validation”.

Spiral Mode (a.k.a. Risk-Based)

This model is a mix of both Waterfall model and Prototyping. The approach in this model is more risk-based, hence the second name “Risk-Based Model”. The project starts from the center, and each loop (or each trip around the spiral) resembles an iteration. Every iteration is made up of planning, risk analysis, engineering, and evaluation. At the end of iterations, there will be a prototype to evaluate the current iteration. And according to the risks at each prototype, the decision to move to the next iteration or to the previous iteration is made.

Prototyping

Prototyping is not exactly a methodology like the other ones, but it does follow a process. It allows the client to see a sample of the project at hand to make further decisions. This enables the developers to have a reduced project risk since it breaks the project into smaller parts. You could say that it is more focused towards feedback.

Incremental

As the name itself suggests, this methodology provides an incremental building stages, and at each stage there are three main parts; design, implementation, testing. These stages involve both development and maintenance. The product is not ready or finished until all requirements are met. Although this is much more iterative and more flexible, the processes at each stage is still sequential and there may be need for a better methodology.

Clean Room

This model adopts the clean rooms used in the electronics industry to prevent the defects during the fabrication of semiconductors. This method is focused mostly on prevention of the defects rather than catching the defects after an implementation.

Agile

After all these different methodologies took place in the software development industry, there was still room for improvement. Which is why Agile Software Development was created. Seeing all the different disadvantages in the other methodologies, this method had to get rid of most if not all of them. Agile was developed to overcome the latency issues brought about with the Waterfall Model. Iterativity and flexibility was also considered as much needed properties in this methodology. Agile methodology was brought to be a better approach to software development. It is described as the method that enables requirements and solutions to be evolved during the development and maintenance processes with the collaborative effort of the teams who are able to self-organize. Teams do not always have to be comprised of people all of whom have practice in the same field. They can also be cross-functional.

Development and maintenance processes are done in short runs called “sprints.” Some chosen work is to be done and tested to comply with the current requirements. At the end of each sprint, the team must present a successful working version of the product; although that is not supposed to be the end product, it is most likely to be the currently released product. In each sprint, there must be constant meetings set up to keep direct communication and constant feedback alive. That gives the flexibility to the methodology, it can keep track of the changing market and the dynamic customer needs.

Agile Methodology

With the creation and the adoption of the Agile Methodology, software development became more iterative, flexible and took less time, as intended. The traditional model was left behind, and the lesser adopted models were mostly replaced by Agile. Agile enabled the software developers to supply quick releases to meet the needs and interests of customers. It had less number of errors than would be encountered with other models, and it also gave way to quick intervention of those errors without affecting the live release.

Each task has an allocated time period which makes it less stressful to focus on, otherwise, the developer gets lost in different tasks and cannot deliver on time. Catching these defects is a difficult job and requires intensive and thorough testing. In a completely agile system, there will only need to test for the new parts of the product; but to become completely agile, testing of the whole system must be done at each sprint to make sure the new parts of the product does not break the older parts, no such block of code clashes with another block of code and crashes the whole system. This type of testing is called Regression Testing.

Types of Regression Testing

There are a lot of types of tests in Regression Testing, and these tests are widely considered parts of a Testing Triangle. Huge number of Unit Tests which are written in the same language as the software itself are run in each sprint to make sure separate parts return the correct response. After the Integration, Integration Tests are run to check for the logic of the system, the databases, servers and the API. These are less in number, and then there’s System Tests which are even less in numbers. System tests make sure the system checks out by simulating a customer. These tests act like a customer and demand stuff from the software, and check if the software is functioning properly without any issues.

Achieving agility while keeping a continuous integration to the system and continuous delivery of releases is difficult. In order to carry out such tasks, the setup of the project needs to be able to support it. The teams and their cooperation, individual self-discipline, ability to supply quick releases, and proper testing is key for the success of this model. Teams should be open to learning from mistakes, so that agility is one step closer. It should also be noted that the tests need to be good, not just to be written.

Continuous Testing

In applying agile to your system, there will be need for continuous testing to keep track of the system to get defect feedback. All those tests are incredibly time-consuming to do by hand, and there is always room for improvement to carry out those tests automatically. Make sure you have a look at our product Testinium to run your tests automatically to leap towards agility.