If only it were that easy.
Writing code isn’t like writing a book. You don’t just create a story outline and start writing from start to finish. The lifecycle of custom software development is a complex process that is broken down into multiple palatable stages. It also requires a great amount of teamwork, collaboration and management. There are also a multitude of determinants that govern the process such as user requirements, involved platforms and target dates. Despite the involved complexity, it is essential to get the process right. The premature release of a “buggy” application can result in lasting consequences down the road. For one, it’s always more expensive and time consuming to fix it the second time. In addition, the image of both the development team and the company behind the release can be greatly tarnished. Hence the phrase, you only have one shot to make a first impression.
This is why it is important to have a methodology that defines how the project will be implemented. organizes the workflow of the project. There are two basic methodologies utilized today.
A good analogy that demonstrates the distinctions between these two can be observed in the way in which Microsoft releases its operating systems today. It used to be that Microsoft released its operating systems with defined life cycles of three to six years. Although Microsoft would release a service pack at some point during the product lifecycle to fix bugs and add a feature or two, very little changed until the next OS release. Compare this to the Windows-as-a-Service approach of Windows 10. The latest OS is constantly evolving on a continuum basis, introducing new features every few months, rather than years. This allows for a more up-to-date operating system that users can easily adjust to as changes are incremental and not huge leaps.
There is no denying that Waterfall is an awkward name, but a good analogy might be that like a waterfall, water can’t go back up after it flows downward. Such is the nature of this traditional methodology. Using this traditional approach, the development project is separated into distinct stages. Each one must be completed and signed off on before the work is passed on to the subsequent stage. These stages are usually comprised of something like the following:
Each successive stage has its own personnel team and relies on information that was forwarded from the previous stage. Think of how a car is manufactured on an assembly line. Each component is added on in a highly distinct order that does not change.
There is no doubt that waterfall is not as popular as it once was, but that doesn’t mean it is dead. In fact, there are a number of circumstances in which the waterfall approach still makes a lot of sense.
The very word, agile denotes agility and flexibility, which is what this approach is all about. Agile has been widely embraced due to the elastic nature of software today and is the dominant approach used by development teams. Unlike waterfall, there is no defined vision or stages. Instead, the project is broken up into a series of sprints that encompass a short period of time (3 weeks for instance) in which new product features are planned, developed, reviewed and released. Agile isn’t about a single release, but perpetual releases that are constantly introducing innovative features that enhance the product. The primary aim is to get something of value in the hands of the customer as soon as possible.
For instance, the sprint at hand may be to create a button that the stakeholders of the application have decided is now needed. Once completed, the team takes on the next facet to be released. Although the agile approach may sound chaotic, it is actually a very orderly process that allows for constant customization and refinement. Each day begins with a daily standup, a fifteen-minute meeting in which contributors and managers discuss what was completed the previous day and agree on what needs to be done on that day. While the end product may be far different than its vision, the customer and other stakeholders are continuously involved throughout the agile process.
No matter which methodology you utilize, one thing is common to each. You must ensure you have quality code before it goes into production. For waterfall, this means testing everything near the completion point of the project. In the case of Agile, testing is a continuous process, often commencing in parallel with code development.
At OnPath Testing, our automation engineers are adept at creating the best testing solution for your application needs to ensure that your application is stable and predictable, regardless of platform. We can also go beyond the role of automated QA and dive down into the functionality of your code to ensure it does what it was intended to do. In the end, it doesn’t matter to us which development methodology you use to guide your project. What matters to us is that we inject the value of assurance into your development through our testing expertise and efforts.