Blog Detail

Automation in Software Development

Posted by Payal Patel On 09 Mar 2017

Automation in Software Development

Automating Software development process

Vision to Software development process which is beyond any particular software technology or computer language called as automating the process. It is the strategy to win over continuously changing technology. Article is about

What is automation in development?

Industry people usually define it as  "anything that can speed up the development process and allow the company to bypass most, if not all, of the software development process, jumping from a simple business-level wish list to a ready-for-the-market product (writing as little code as possible and hiring as little programmers as possible)".

In other terms: "any technology/methodology that can reduce software development to the most complicated thing the average business guy can understand.

Automating monotonous/repetitive procedures can provide actual value to software development projects. Article is all about to explore the significance and barriers to automation and provide some guidance for automating aspects of the development process.

To utilize the precious qualities of developer Or Tester to put in actual value in the project, rather than repeating the same tasks again and again, it will be consider advocating the concept of automation to the development process and team. The management who is committed to maximizing the talents and saving time of the members of your technical team, as well as minimizing the risk of your project failing to deliver on time and on quality, you will want to encourage your team to invest the necessary time and effort required to automate the types of tasks that will be identified in this article.

Why should Automate?

Standardize Structure: Leave behind the micro screening of the developer code for the technical standards. It is managed through the automation. Improvements in the technical standards can be a next versioning for the automation. Moreover, in anyway uniformly generated scripts will be easy to understand.

Repeatability:  Scripts can be repeated, and, unless your computer is having a particularly bad day, you can be reasonably certain that the same instructions will be executed in the same order each time the same script is run.

Reliability: lessen chances for human error.

Efficiency:  Automated tasks will often be faster than the same task performed manually. (Some people might question whether gains in efficiency are typical, noting that they have worked on projects where, in their view, trying to automate tasks actually cost the project more time than it saved. Depending on the situation, this may be a real concern. In addition, automation might have been implemented poorly or carried too far on some projects—but keep reading for more on what to automate, and when.)

Testing:  Designed / Scripted procedures undertake the testing throughout the development cycle, in the similar way the system code does. This significantly increases probability of successful process execution and outcome represents the mature and proven set of reoccurring process.

Versioning:  Scripts are artifacts that can be placed under version control. With manual processes, the only artifacts that can be versioned and tracked are procedure documents. Versioning of human beings—the other factor in the manual process equation—is unfortunately not supported by your typical source control system.

Leverage:  Another big benefit to automating is that developers and testers can focus on the areas where they add real value to a project—developing and testing new code and features—instead of worrying about the underlying development infrastructure issues.

For example, instead of requiring everyone to become very well familiar with all the little nuances of the build procedure, you can have one person focus on automating the build and have that person provide the team with a greatly simplified method of building, hopefully as simple as running a command or two. Less time spent on builds leaves more time for the tasks that add the most value to the project.

Some of the typical targets for automation are:

  • Build and deployment of the system under design.
  • Unit test execution and report generation.
  • Code coverage report generation.
  • Functional test execution and report generation.
  • Load test execution and report generation.
  • Code quality metrics report generation.
  • Coding conventions report generation.


The above list is obviously not thorough, and every project has its own unique characteristics. However, procedure should be automated or not that depend on its regular repetition during system’s life cycle. The more often it repeated the higher the value of automating it.

Once a process has been identified, spend a little time investigating how you might be able to automate the process, including researching tools that could assist with automation, and estimating the level of effort required to implement the automation versus the total cost and risk of requiring team members to manually perform the procedures.

As with any other business decision, it really should come down to a cost versus benefit analysis.

When should apply?

  • Improvements and modification are better than re-writing the things. So, attempt to automate before understood the process is dangerous.
  • A team whose aim to deliver the working software is in no position to develop enterprise wise strategies and tools.

A well planned developed strategies can be apply for future project which are less costly and eventually undertaken automation also be less costly. If it has been govern by separate teams under required infrastructure.

Obstacle points

  • Stakeholder pressure/ Developer back lock: Demand to produce rapid development and as soon as progress, teams often fail to notice or forget to Practices that do not appear as automation contributed to working code.
  • Focus on core requirements: The team has an overwhelming desire to begin producing working code and tests as soon as possible. Writing code that can be demonstrated is much more satisfying to developers than writing automation scripts.
  • Sales Department pressure
  • Lack of follow through. Even with the best of intentions, teams can quickly lose their commitment to plans for implementing automated processes.



BLOG:  S.O.L.I.D  Principles

S.O.L.I.D:  The First 5 Principles of Object Oriented Design

S.O.L.I.D is kind of short form for the first five object-oriented design (OOD) principles produced by Robert C. Martin, popularly known as Uncle Bob.

Robert Cecil Martin is an American software engineer and author. He is a co-author of the Agile Manifesto. He now runs a consulting firm called Uncle Bob Consulting LLC and Clean Coders which hosts videos based on his experiences and books.

These principles, when combined together, make it easy for a programmer to develop software that is easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or the adaptive software development.
Article simply sheds on light on what is solid.

S.O.L.I.D stands for

  • S– Single-responsibility principle
  • O– Open-closed principle
  • L– Liskov substitution principle
  • I– Interface segregation principle
  • D– Dependency Inversion Principle



Single – responsibility Principle

The class should have only one reason to change its functionality in another way class should have only one job/ Single job to do.

SRP is the simplest of the above mentioned principles. However, it can be said that one of the most difficult to practice too. Developing class with more than one responsibility is easy while finding and separating those each responsibilities is all about SRP to design.


We have some shapes and need to calculate area. Shape classes are as defined below required calculation properties has been set in the constructor.

Area calculator class as shown below which covers required logic to calculate areas.

As  shown we can initialize our class and get the output.

Now, what if we need output in the different form or multiple form like json, HTML etc.  All that really does not concern with the AreaCalculator class as per SRP concept. This class should only do the single responsibility of calculating the area without considering user’s requirement for output.  To solve the issue you can create another class as SumcalculatorOutputter which will handle the area display types.

   Practice SRP Benefits:

  • Responsibility separation reduce the side effects of modification
  • Code complexity is reduced by being more explicit and straightforward
  • Readability is greatly improved,
  • Coupling is generally reduced,
  • Your code has a better chance of cleanly developing
  • In anyway Small classes are easy to manage.

      Practice SRP Disadvantages:

  • Overly Scattered code
  • Number of classes will increase



It’s quite logical if class is restricted to one specific responsibility; it’s bound to be cleaner and more respective to the changes.



Open-Close Principle

Objects or entities should be open for extension, but closed for modification. Entities can be considering Classes, modules, functions etc.

This means the written code does not required to change every time when the requirement get changes.  Hear change mean the cascaded changes which we usually required to do while having something changed in OOP code flow.  This principle tells that you can change internal operation either can do extension of the existing code. However, do not code which needs cascaded changes; means changing one requirement leads to the change in all classes involved in the flow.


There is class Rectangle and need to calculate its area.

The area class implementation is as shown below.

Now, as per above code if Area Calculator class is limited to the calculating the area of Rectangle class. And if user need the same class not only to calculate area of only rectangle but also area of circle. That will make the Area method to change.

However, if the Area method accepting the argument of the collection of shapes and then as per the shape type area will be calculated it will be less complex and in a way open for extension rather modification.

Here, we can add shapes as many we want logically we are not modifying the code but we add/change code in order to extend it.  We are not doing flow modification.

In a real world scenario where the code base, a hundred or a thousand times larger and modifying the class means redeploying its assembly/package to five different servers that can be a pretty big problem. 

By the end of this section 2 more shapes can be easily added as per constant requirement changing in software development.

Above is yet not concrete way but we can develop base class for shapes as shown in below example.





  • Loose coupling
  • Improved readability
  • Reduced the risk of breaking existing functionality be adding/inheriting new classes. Saves regression testing time of existing code base.


  • Change may required at many places depending on situation


Liskov Substitution Principle

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

All this is stating is that every subclass/derived class should be substitutable for their base/parent class.

Object of a derived class should be able to replace an object of the base class without bringing any errors in the system or modifying the behavior of the base class.

All the time we design a program module and we create some class hierarchies. Then we extend some classes creating some derived classes.

We must make sure that the new derived classes just extend without replacing the functionality of old classes. Otherwise the new classes can produce undesired effects when they are used in existing program modules.

Likov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.


Derived types must be completely substitutable for their base types.

This principle is just an extension of the Open Close Principle and it means that we must make sure that new derived lasses are extending the base classes without changing their behavior.

Bad Example

Good Example


Interface Segregation Principle

Name itself defines Segregation / separation in interface while developing. A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use. Hear client refers to the classes which will implement the interface.


Bad example:

Good Example:


Dependency Inversion Principle

Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

Bad example:

Good Example


Dependency inversion can be more easily done by unity framework, where coupling between class and interface will be registered by type of naming convention

S.O.L.I.D might seem to be a handful at first, but with continuous usage and adherence to its guidelines, it becomes a part of you and your code which can easily be extended, modified, tested, and refactored without any problems.