Agile Software Design and Development :

Design is an important part of any software project. Yet agile teams often struggle with "what to do
about design?" because of these four factors:

● Many teams focus on high-fidelity designs during the planning process, which forces a
waterfall culture throughout implementation.
● Designers are often shared across teams and have limited time to spend with any given
team.
● Designers don't always have an easy way to report feedback to the engineering team.
● The logic and presentation layers aren't always clearly separated in the code base, making
style changes difficult.

What is Code Refactoring?

In software development, a lot of developers do not fix the things in an application unless it’s not
broken. After all, it just spending some extra hours on something which has no problem yet.

But do we need to wait for the problem to arise in the development process…?
Can’t we just update or improve the software before it’s old or create any problem in the future…?

Code refactoring is all about it.

We update or improve the internal structure of the code before it becomes messy and create any
problem in the future. We restructure the code without changing the external behaviour or
functionality of the application. You make tiny changes in the source code but you keep in mind
that the functionality remains the same.

Don’t consider code refactoring as rewriting the code. Rewriting the code changes the behaviour of
the code but refactoring doesn’t.

For customers, code refactoring doesn’t matter at all. They do not bother about it because it’s not
going to benefit them in the short term. For customers, the application remains the same as it was
made earlier. They don’t find any changes in the application so they also don’t bother about paying
money for this process.

The main idea behind code refactoring is making the inefficient and over-complicated code to more
efficient, simpler, cleaner, and easier to understand. Code refactoring makes the entire application
more efficient, secure, fast, maintainable, and scalable. It also helps developers to find the hidden
bugs and vulnerabilities in the system.

In the code refactoring process, you eliminate all the code smell problems. It involves removing the
duplicate code, large classes, and long methods. You follow some best practices that include
rename method, encapsulated field, extracts class, introduces assertion, pushdown methods, etc.
You make code reusable and you remove all the unnecessary declared variables and unnecessary
code from the application.

All the above best practices make your code cleaner and later it becomes easier for anyone to
upgrade, implement, or change some functionality in the system.
Refactoring:

It is the practice of continuously improving the design of existing code, without changing the
fundamental behavior. In Agile, teams maintain and enhance their code on an incremental basis
from Sprint to Sprint. If code is not refactored in an Agile project, it will result in poor code quality,
such as unhealthy dependencies between classes or packages, improper class responsibility
allocation, too many responsibilities per method or class, duplicate code, and a variety of other
types of confusion and clutter.

Refactoring helps to remove this chaos and simplifies the unclear and complex code.

Following are the definitions quoted by various experts in Agile on Refactoring concepts:

A refactoring is a “behavior-preserving transformation” – Joshua Kerievsky

Refactoring is “a change made to the internal structure of software to make it easier to

understand and cheaper to modify without changing its observable behavior” – Martin
Fowler

It is best to refactor continuously, rather than in phases. Refactoring continuously prevents

the code from getting complicated and helps to keep the code clean and easy to maintain.

In Agile development, there can be short and separate sprints to accommodate refactoring.
This module provides an overview of the technical/engineering practice of Refactoring
which would be implemented in Agile projects.

Challenges:
Though refactoring brings a lot of benefits to the code quality of the software, there are multiple
challenges that dissuade developers in Agile projects from continuously refactoring the code.

Following are a few challenges that are mostly seen in Agile projects:

Time Constraint: Time is the biggest challenge for doing refactoring in Agile projects as the
Sprints are time-boxed with a defined set of deliverables.
Reluctance: If the code is working fine without any refactoring done, there will be an inclination
towards not revisiting the code. This is primarily because of the mindset that there is no error and
hence no need to do additional activities i.e. refactoring.
Integration with branches: To integrate the code across different branches post refactoring is
considered a challenge
Fear factor: Developer often fears that refactoring will introduce bugs and break the existing
functionality which is working fine
Re-Testing: In case automated test suites are not available, the developer is discouraged to do
refactoring with the additional effort of manual testing to check the functionality Backward
Compatibility: Backward compatibility often prevents developers from starting refactoring efforts.

Motivation For Refactoring:

The following points for motivation are more common among the developers while they do
refactoring

1. It becomes easier to add new code

2. The existing code’s design is improved.
3. Helps to gain a better understanding of code
4. Makes coding less annoying

Advantages of Refactoring:
Refactoring in small steps helps to prevent defects from being introduced. The following
points can be further perceived from the benefits of implementing Refactoring.

1. Improves software extendibility

2. Reduce the expense of code maintenance.
3. Provides standardized code
4. Architecture improvement without impacting software behavior
5. Provides more readable and modular code
6. Modular component refactored to maximize possible reusability

Design Guidelines for Agile Projects:

In a traditional software development project, requirements and plans are set before development
begins, which enables the team to know the road ahead with reasonable confidence that
requirements or design will not change drastically in the middle whereas the Agile method is to
enable and embrace change. On an Agile project, requirements can change at any point in the
project cycle. Therefore, it is imperative for Agile teams to have a code in a position where they can
conveniently accept a new requirement or change.

Good design is an important principle of Agile manifesto projects: “Continuous attention to

technical excellence and good design enhances agility”.

Precautions for Refactoring:

Too much pattern focus takes away the focus from writing small, simple, and understandable
code. Look at patterns from a refactoring perspective and not just as reusable elements.

Why Code Refactoring is Important in Software Development?

Take the example of your kitchen in your house. What will happen if you do not clean the dishes
today and leave it for tomorrow? Maybe it’s not a problem for you from morning to evening but the
next day your kitchen will be a real mess and you may become frustrated in cleaning up the entire
mess. A similar thing happens in software development when you do not pay attention to cleaning
up the mess in your code while building the functionality one by one in your entire application.

In the Agile software development approach when teams are involved in developing some
application the code is managed by many programmers. To implement some new features or to
extend the functionality of the code every member needs to understand the code and this is
possible if the code is clean, simple, and easy to understand. Nobody loves to work on some
messy code that is not continuously updated or improved as the feature grows in the system.

Refactoring the code becomes mandatory for the sake of other members of the team. A refactored
code eliminates all the code smell problem and the code becomes much more clean and easy to
understand. Debugging becomes easier because of small functions and proper placement.

Let’s discuss some of the major importance or benefits of code refactoring in software
development…

1. To Keep Your Code Clean

Code refactoring removes all the notion of code smell and makes your code cleaner and easier to
understand. You remove redundant code, unnecessary variables, too many parameters, longer
methods, longer classes, too many conditions or unnecessary loops, etc. You clean up all the mess
from your code and you eliminate all the defects before it makes real damage.

When your code is simpler, cleaner, and easier to understand, it becomes easier to work with. Also,
it becomes easier to extend some features or debug the code. Code refactoring also helps in
understanding some unfamiliar software. By refactoring the code you can test your application and
understand what each part of the program does and how the entire application is built. This helps
in understanding the project in a better way.

2. To Improve The Performance of The Application

An application that doesn’t have unnecessary classes, functions, variables, methods, or any other
mess, runs faster and smoother. Performance of an application increases if the code is recently
refreshed or updated. Your application generates quick responses and users no longer complain
about the slower performance. This leads to a better customer experience.

3. You Save Time and Money in The Future

A clean and clear code takes less time to understand and implement the new features. None of the
developers loves to work or waste their time understanding some messy code. An application that
is not refactored takes more time to extend or upgrade. Also, if the application is damaged due to
some issues, the organization needs to spend the money on fixing the issues and the budget gets
increases.

4. To Reduce the Technical Debt

The cost of any software is not finalized when you launch the first version of it. Your software may
stop responding after a couple of months if you don’t make regular updates in it. You may end up
with the technical debt and to reduce this debt you need to refactor the code all the time.

5. Your Code is Outdated

Often in development, we use some libraries or the framework that needs to be updated with time.
When a newer version of these libraries or frameworks appears the program written in the older
version may not work or it may work with some errors. If your application uses some libraries that
are no longer maintained or even exist then it can create a lot of problems in the application. Your
application may stop responding or you may find a lot of bugs. You need to keep your code up to
date to prevent this issue.

6. Makes Bugs Easier to Be Found

It’s easy to find the bugs in an application when you understand the code and entire structure of
your application. You can test the application and find the bug if you understand how things are
connected and working in an application.

7. Improves the System Design

You learn new things over time when you improve the code and understand your project in a better
way. You implement some feature and after a couple of months if you just pay attention to your
code you will find that it can be written more simply and easily. The solution you implemented
months ago can not be good today. The overall design of your application can be improved by
following some best practices and refactoring your code.

A poorly designed software may be good in the short term but in the long term, it can create so
many issues. To avoid the issues in the future it’s good to spend some time in code refactoring and
follow the best practices instead of taking the shortcut and making some quick and cheap choices.
Conclusion
Code refactoring is not just about improving the code. It’s a healthy habit for any company which
should be followed to avoid any major issues or bugs in the application. A project lives longer for
years if it’s regularly updated or refactored. Your application runs faster and it gives a better
customer experience which is important to run any kind of business. Instead of creating a big
problem for yourself in the future, it’s good to invest time in the code refactoring process while
building an application.
Implementation of Refactoring Techniques:
There are multiple refactoring techniques available that will make the existing code better in terms
of performance and maintainability. The basic purpose of refactoring in Agile or any other
methodology is “Leave a module in a better state than you found it”

The Refactoring techniques are categorized by Martin Fowler as follows:

1. Composing methods
2. Moving features within Objects
3. Organizing data
4. Simplifying Conditional Expression
5. Making method calls simpler

Every category has certain refactoring techniques.

Few techniques are explained below.

Composing Methods: It deals with the proper packaging of method or function code. Large
methods/functions having very long complex logic implementation can reduce the maintainability
and readability of the code. Applying refactoring techniques like extract methods will help make the
code more maintainable and readable.

A few of the refactoring techniques in composing method/function are detailed below:

1. Extract Method
2. Inline Method
3. Replace method with method object

Extract Method: This is one of the popularly used Refactoring techniques. The implementation
behind this technique is very simple. It consists of breaking up long methods by shifting complex
chunks of code into new methods which have very descriptive identifiers. This method is used
when:

The code consists of long methods covering multiple logical flows that can be broken up into
smaller methods
If the same code is duplicated in more than one flow, move this to a single method and call from all
other flows.

Inline method: In contrast to the Extract Method technique of refactoring, Inline method
techniques suggests replacing a method/function call with the body of the method/function. It is
suggested when the source code of the method/function is very small. This method is used when:

When a function call causes a performance bottleneck

When inline code increases the readability of the code since the body of the function is the same
as the function name
When there are too many delegations in the code.

The advantages of this method are:

Unnecessary complexity reduced, reduction in method calling overhead

Increases the readability of the code

Replace method with method object: The Thumb rule of good code is that, it should be readable
and easily manageable. At times we might come across a very long method having complicated
logic implementation done inside it with many local variables. Such a method cannot be simplified
by applying the extract method technique because of the usage of too many local variables,
because passing around that many variables would be just as messy as the long method itself. In
such cases, a class can be created for such a method. This class will have all local variables of
that long method as its data members. One of the methods will be the long method. The
complicated logic of this method can easily be simplified by applying the extract methods
technique.

Continuous integration: is an agile and DevOps best practice of routinely integrating code
changes into the main branch of a repository, and testing the changes, as early and often as
possible. Ideally, developers will integrate their code daily, if not multiple times a day.

Benefits of continuous integration

Investing in CI results in fast feedback on code changes. Fast as in "within minutes" fast. A team
that relies primarily on manual testing may get feedback in a couple hours, but in reality,
comprehensive test feedback comes a day–or several days–after the code gets changed. And by
that time more changes have occurred, making bug-fixing an archeological expedition with
developers digging through several layers of code to get at the root of the problem.

Protect quality with continuous builds and test automation

Two practices keep us out of that situation:

Continuous builds: Building the project as soon as a change is made. Ideally, the delta
between each build is a single change-set.

Test automation: Programatic validation of the software to ensure quality. Tests can initiate
actions in the software from the UI (more on that in a moment), or from within the backend
services layer.

Continuous integration pairs continuous builds with test automation to ensure that each
build also assesses the quality of the code base.

To fully realize the benefits, a team must also have the discipline to pause development and
address breakages right away.

The energy a team invests (and make no mistake: it's an investment) in writing tests and
configuring the automation is all for naught

if builds are allowed to languish in a broken state. Protecting the investment in CI and protecting
the quality of the code base are one and the same thing.
Testing in CI:

Unit, API, and functional tests

CI runs have two major phases.

Step one makes sure the code compiles. (Or, in the case of interpreted languages, simply pulls all
the pieces together.)

Step two ensures the code works as designed. The surest way to do this is with a series of
automated tests that validate all levels of the product.

Unit Tests

Unit tests run very close to core components in the code. They are the first line of defense in
ensuring quality.

Benefits: Easy to write, run fast, closely model the architecture of the code base.

Drawbacks: Unit tests only validate core components of software; they don't reflect user
workflows which often involve several components working together.

Since a unit test explains how the code should work, developers can review unit tests to get
current on that area of the code.

API tests

Good software is modular, which allows for clearer separation of work across several
applications. APIs are the end points where different modules communicate with one
another, and API tests validate them by making calls from one module to another.

Benefits: Generally easy to write, run fast, and can easily model how applications will
interact with one another.

Drawbacks: In simple areas of the code, API tests can mimic some unit tests.

Since APIs are the interfaces between parts of the application, they are especially useful when
preparing for a release. Once a release candidate build passes all it's API tests, the team can
be much more confident shipping it to customers.

Functional tests

Functional tests work over larger areas of the code base and model user workflows. In web
applications, for example, HTTPUnit and Selenium directly interact with the user interface to test
the product.

Benefits: More likely to find bugs because they mimic user actions and test the
interoperability of multiple components.
Refactoring in Test Driven Development:

Test-Driven Development (TDD) is a software engineering approach that consists of writing failing
test case(s) first covering functionality. And then implementing the necessary code to pass the
tests and finally refactor the code without changing external behavior.

TDD deals with 2 types of tests i.e.

Unit tests: used to verify the functionality of a single class that is separated from its
environment. Acceptance tests: used to check a single functionality

On similar lines, Refactoring can also be categorized into different types.

Refactoring at local class level:

The unit tests for this class are unchanged and the tests are still green. If the Unit tests are
designed to check complete scenarios instead of single-member calls, the refactoring falls into this
category.

Refactoring impacting multiple classes:

In this case, Acceptance tests are the only way to check complete functionality after
refactoring. This is useful if a new way of functionality is provided, and implemented by
changing class after class and associated unit tests.

An important aspect to remember for refactoring in TDD is when code is refactored impacting
interface/API, all the callers of this interface/API along with Tests written for the interface/API need
to be changed as part of refactoring. In congruence with the definition, refactoring is a “behavior
preserving” change.

Agile Scale

In an Agile methodology, there are two popular frameworks- scrum and kanban. A team level uses
scrum and kanban as a framework. As their popularity increases, the industries start to scale agile
to suit larger organizations. There are two popular methods emerge to facilitate, these are a scrum
of scrums, and the Scaled Agile Framework (SAFe). The scrum and kanban are high starting
points for scaling agile within an organization.
Scrum of Scrums

It is the most attractive, agile framework for individual teams. When several scrum team works
together on a big project, the scrum of scrums is the next step for scaling agile. The most crucial
component of the scrum of scrums is a multi-team stand-up. It is a small meeting for scrum
masters to talk about the agile process.

Select a member from each team to get a start, and each team represents them at the scrum of
scrums, admirably someone in a technical role. It is a domestic meeting where the scrum master
helps to facilitate the stand-up, but it is run just like any other team stand-up. Scaled Agile
Framework (SAFe)

Scaled Agile Framework (SAFe) is another way to scale agile in large organizations. According to
the Pioneered by Dean Leffingwell, it takes the most structured approach to scale agile than scrum
of scrums. It describes three levels in the organization: portfolio, program, and team. Such
structure typically appeals to larger organizations, because Scaled Agile Framework (SAFe)
employs a tiered approach for the delivery of work.

Version Control:

All version control systems allow you to keep track of the changes made to source files. One
advantage of this is that you can see how the software has evolved over time. This can provide a
deeper understanding of code than can be obtained by just looking at the current state. Being able
to compare source files from different times is invaluable when investigating why a change was
made, how bugs were introduced, etc.

Version control, also known as source control, is the practice of tracking and managing changes to
software code. Version control systems are software tools that help software teams manage
changes to source code over time. As development environments have accelerated, version
control systems help software teams work faster and smarter. They are especially useful for
DevOps teams since they help them to reduce development time and increase successful
deployments.

Version control software keeps track of every modification to the code in a special kind of
database. If a mistake is made, developers can turn back the clock and compare earlier versions of
the code to help fix the mistake while minimizing disruption to all team members.

Moreover, you can get a snapshot from any point in time. For example, in the diagram below you
could use the version control system to "checkout" the source as it was at the time of Release 1.0.
You can then build that specific version if you need to investigate its behavior.

Another essential facility of a version control system is branching. This allows variations to be
developed from a common base version. Traditionally, branching has two uses:

release branching - a branch is created when a new version is released

feature branching - a branch for an experimental or long-term development

Agile approach to Quality Assurance,:

In software development, Quality Assurance (QA) guarantees the quality of a software product, as
per the standards set by an organization, its industry, or the International Organization for
Standardization (ISO). QA ensures that all software development methods, activities, and
procedures are monitored and comply with quality standards.

Agile is an umbrella term that describes a set of frameworks and practices that reflect the values of
the Manifesto for Agile Software Development.
Agile solutions are bound by four guiding values. Prioritize people over tools and processes;
frequently deliver working software, not fuss over technical documentation; involve customers in
the process, not just negotiate the requirements; and be open to unforeseen changes. Agile
solutions also topple down silos that keep development and test teams apart, ensuring they are
all on the same page, working towards the same goals.
QA ensures that all software development methods, activities, and procedures are monitored and
comply with quality standards.

● Agile is an umbrella term that describes a set of frameworks and practices that reflect the
values of the Manifesto for Agile Software Development.
● Agile solutions are bound by four guiding values.
● Prioritize people over tools and processes; frequently deliver working software, not fuss
over technical documentation; involve customers in the process, not just negotiate the
requirements; and be open to unforeseen changes.
● Agile solutions also topple down silos that keep development and test teams apart,
ensuring they are all on the same page, working towards the same goals.

Why Merge Agile With QA?

Agile QA incorporates testing into the Software Development Life Cycle (SDLC) early and often.
This helps teams catch and fix bugs faster, reduce technical debt, and uncover any unforeseen
requirements.
Furthermore, Agile QA makes quality a shared responsibility. This means testability is a priority
for every role, from designers to product owners and coders to testers, and is present in each
step of the SDLC, instead of being shoehorned in at the last minute.

According to the 15th State of Agile Report, the two most urgent reasons for adopting Agile were
to: enhance the ability to manage changing priorities, and accelerate software delivery. Other listed
reasons include enhancing software quality, reducing project risk, and increasing software
maintainability. Research also shows that engineers spend, on average, 1 day per week managing
technical debt, thereby impacting team morale, and slowing development. Establishing effective
Agile QA processes early may help improve software testing outcomes.

Breaking Down the Agile QA Process

The Agile QA process begins at the start of the SDLC. The Quality Assurance team, in close
collaboration with the developers, performs testing in several sprint iterations. Each sprint lasts
about 2 weeks or longer depending on the project requirements.

During each sprint, the team performs the following steps to ensure the intended milestones are
reached:

1. Risk Analysis and Impact Assessment

The QA team gathers input from internal and external stakeholders as well as target end users.
They identify the potential risks and issues, and categorize them based on their anticipated effects.
The analysis may not catch everything, but it will leave room to deal with unforeseen issues if they
occur.

2. Create Test Plan

QA and stakeholders create a test plan. The plan covers every facet of the testing strategy, such
as the objectives, timeline, order of deliverables, and estimated budget as well as resources for
manual and automated testing. The plan also clearly outlines the objectives for each testing
method (i.e. Unit, Acceptance, Integration, and Smoke tests). This way, each test is performed at
the right time, in the right testing environment, and captures actionable insights that help improve
software quality.

Unlike a Waterfall test plan, an Agile plan is more flexible and incorporates continuous feedback
into each stage of development. This helps the team identify and resolve bugs earlier and faster.
As a result, bugs are less likely to be ingrained into the final product.

3. Predict Release Date

Every time a new feature or function is implemented into the build, it is tested. The feature or
function is uploaded to the source-code repository and thoroughly tested. If it is release-ready, it
passes. If not, the test results are recorded and sent to the development team. The devs will then
revise the feature or function and resubmit for review.

With each successful Agile sprint, the team will have a better idea as to what the most realistic
release date might be. They can then share this information with the customer. Most customers will
appreciate this level of honesty, and feel relieved knowing that their project is being well-managed.

4. Daily Scrums
During a sprint, all stakeholders will meet each morning to share information and progress
updates. They may also set goals for that particular day, and prioritize any unmet goals from the
previous day.
Daily Agile scrums are a great way to motivate the team, resolve unforeseen issues, and reflect on
progress so far. They also help break down silos between departments, by filling in knowledge and
information gaps, as well as establishing shared accountability to keep everyone focused and on
the same page.

5. Sprint Review Meeting

At the end of a sprint, an informal meeting is held. Here, the team demonstrates the product in
progress and determines what is finished and what needs more work. The usability of the product
is assessed in stages, throughout the course of development, in collaboration with all stakeholders
at once.

This is more beneficial than the traditional Waterfall approach. In Waterfall, the usability of a
software product is assessed near the end, after all of the coding and design decisions have been
made. By incorporating continuous feedback into each stage of development, Agile makes it easier
to identify what works and improve upon what does not work.

Embracing Agile QA in Software Development

QA in Agile software development encourages testing early and often. This requires collaboration
between all development team members, including internal and external stakeholders plus target
end users. For this reason, hiring a software development company, one that effectively
incorporates QA into the Agile process, is a worthy investment as it can help streamline
development and reduce time to market.
QA in Agile :

It’s a well-known fact for professionals that they must achieve the satisfaction of their clients
through early and continuous delivery of their valuable product, say their software. So,
professionals must sail on the boat by balancing early feedback and continuous delivery, which
should happen constantly.

Some customers don’t mind your valuable efforts if they are invested in the work, which will better
impact their requirements. For example, consider that you made some enhancements and made
the application UI look even better.

The reason is that they might be expecting just the functionality to work correctly now, and UI
enhancements might not be their priority. And even after professionals had invested their client
money and time in doing this, it failed. This could be because of the lack of continuous feedback
from the client.

We have another example that says if a team had done the estimation of the software delivery
wrong. And if they thought they could deliver the product early and committed the same to the
client. Later, they analyzed that they couldn’t do it as they might have underestimated the process,
which might also lead to failure due to continuous delivery.

In today’s world, the need for software is fundamental. Right from the start of the day, we will come
across and interact with various types of applications like one for grocery ordering, commuting
applications, and much more. People are using software for all kinds of needs. And the point to be
noted is they are used to frequent updates of the software they are using. The reasons might be
many as there is too much competition between software providers to grab clients and then
continuously provide their best service to clients. There are chances to lose their clients at any
point of time if any one of the two early feedback or continuous delivery fails.

The main change to be noted here is an increase in test automation scope, which will
continue along with the need for continuous automation.

So here there are two points.

One is that more features and functionalities need to be automated. Automation needs to happen
in hand with delivery, say a feature is delivered, and a plan to automate it should be in place. The
other one is we should have room to accommodate changes to address enhancements and
changes in the corresponding feature even after the test automation.

There is an agile principle that says Business and Developers together, which means the technical
team and a business team should work hand in hand, which will remove the barriers among them
and help achieve a better product and promote transparent and healthy communication. Some
customers don’t mind your valuable efforts if they are invested in the work, which will better impact
their requirements. For example, consider that you made some enhancements and made the
application UI look even better. The reason is that they might be expecting just the functionality to
work correctly now, and UI enhancements might not be their priority. And even after professionals
had invested their client money and time in doing this, it failed. This could be because of the lack
of continuous feedback from the client.
So basically, what agile methodologies say about managing a project by splitting it up into
several phases.

First, it requires continuous collaboration with all people involved in the business and people
involved in making the business process happen, i.e., for communication between stakeholders,
partners in business, and technical people who are the reason for developing and maintaining the
software.
At any point in time, any new requirement needs to be answered with less or no effect on business.
But in fact, it’s not simple as we quoted here. For example, consider a bank needing a customer
login application to enhance their business in attracting customers interested in banking online. So,
the bank’s job and technical people will not end with just developing and handing over the software
to the client.
There should always be a space to accommodate the changes in existing features and address the
customer’s new needs in this competitive world. Of course, professionals will achieve this for sure,
and they can also estimate the circumstances once the new requirements are added. But to
identify how these changes affect the software and have prevention measures to address them in
advance and rectify the future effects, there is a need for quality assurance people right from the
beginning of the project.

Responsibilities of a Quality Assurance Engineer

● The quality assurance team needs to be involved in discussions about the feasibility and the
possibility of implementing the requirements.
● Moreover, testing the requirements individually and in harmony with other integrated
applications, addressing defect retesting once they are fixed and estimating the impact of
the defect fixes, and retesting the features around that defect, are essential.
● The agile methodology encourages continuity in the process as well as business and same
the quality assurance process.
● Repeat the quality assurance process, not just ‘Software Testing’ also supports the
continuity, and this quality assurance process in software development is a key factor. So
when going in-depth into the quality assurance process, a typical QA, i.e., Quality
assurance engineers, have below responsibilities.
Test Driven Development :
It is the process in which test cases are written before the code that validates those cases. It
depends on repetition of a very short development cycle. Test driven Development is a
technique in which automated Unit test are used to drive the design and free decoupling of
dependencies.

The following sequence of steps is generally followed:

1. Add a test – Write a test case that describe the function completely. In order to make the test
cases the developer must understand the features and requirements using user stories and
use cases.
2. Run all the test cases and make sure that the new test case fails.
3. Write the code that passes the test case
4. Run the test cases
5. Refactor code – This is done to remove duplication of code.
6. Repeat the above mentioned steps again and again

Red – Create a test case and make it fail

Green – Make the test case pass by any means.
Refactor – Change the code to remove duplicate/redundancy.

Benefits:

Unit test provides constant feedback about the functions.

Quality of design increases which further helps in proper maintenance.
Test driven development act as a safety net against the bugs.
TDD ensures that your application actually meets requirements defined for
it.
TDD have very short development lifecycle.
Pair Programming

As the name implies, pair programming is where two developers work using only one machine.
Each one has a keyboard and a mouse. One programmer acts as the driver who codes while the
other will serve as the observer who will check the code being written, proofread and spell check it,
while also figuring out where to go next. These roles can be switched at any time: the driver will
then become the observer and vice versa.

It’s also commonly called “pairing,” “programming in pairs,” and “paired programming.”

Working of Pair Programming :

Pair programming requires two developers, one workstation, one keyboard and a mouse. The
pairings can be assigned or self-assigned.

Pair programming uses the four eyes principle, which ensures two sets of eyes review the code that
is being produced, even when there is a division of labor. While the driver writes the code, the
navigator checks the code being written. The driver focuses on the specifics of coding, while the
navigator checks the work, code quality and provides direction.

The process starts with the developers receiving a well-defined task. They agree on one small goal
at a time, such as writing code, testing or just taking notes. Any discussions on direction or
corrections can be made after each goal, as to avoid interrupting the driver's flow. The two
programmers can talk about the various techniques and challenges, with the results usually being
higher quality code than when one person does the same work.

The two developers take turns coding or reviewing and check each other's work as they go.
Rotating roles regularly helps keep both developers alert and engaged. Organizations may also
have the pair rotate roles to work on different tasks. This way, they get experience working on the
different parts of the system being built.

Depending on how the pairs are coordinated, junior and senior developers can work together,
enabling senior developers to share their knowledge and working habits. It also helps new team
members get up to speed on a project.
Pair programming styles and techniques

Pair programming uses three general programming styles:

● the driver/navigator style,
● unstructured style and
● ping-pong style.

Driver/navigator style:

The driver/navigator approach is a popular pair programming style where one programmer handles
the mechanical side like coding, and the other is in control of the strategic or architectural elements
like reviewing code. The driver and navigator switch roles often. This style works well for a novice
paired with an expert programmer. The navigator role can range from a reserved approach to a
tactical hands-on role.

Unstructured style:

Most pair programming relationships fall into the unstructured style, where two programmers work
together in an Ad hoc manner and collaboration is loosely guided. Both programmers should have
matching skill levels. A common variant of this style is the unstructured expert-novice pair, where
an expert programmer and a novice are paired together.
An unstructured approach is difficult to discipline and unlikely to last for longer projects.
Unstructured pair programming is also harder to keep afloat remotely. This approach is considered
if programmers do not know what will work best for a project upfront.

Ping-pong style:

With the ping-pong approach, one developer writes a test and the other developer makes the test
pass. Each person alternates between writing and passing tests. When two developers shift roles
regularly, it is unlikely one programmer will control the workflow. This style of pair programming is
normally performed in conjunction with test-driven development.

Development teams should also choose pair programming styles that align with the skills of the
programmers involved. Potential skill pairs include:
Expert/expert pairs. Two experts can generally work within any pair programming style. Advanced
programmers may prefer the ping-pong style, as it allows them to have even participation.
Novice/novice pairs. Two novices together may have difficulty in the driver/navigator style, because
no one is experienced enough to take charge. In addition, the unstructured approach may be
difficult for beginner programmers.
Expert/novice pairs:

The most common skill combination is an expert programmer working with a less experienced
person. Experts rely on their depth of knowledge to direct the activity, while the novice can learn
more from the expert.

Advantages :
1. Two heads are better than one. If the driver encounters a hitch with the code, there will be two of
them who’ll solve the problem.
2. More efficient. Common thinking is that it slows down the project completion time because you
are effectively putting two programmers to develop a single program, instead of having them work
independently on two different programs. But studies have shown that two programmers working
on the same program are only 15% slower than when these programmers work independently,
rather than the presupposed 50% slow down.
3. Fewer coding mistakes. Because there is another programmer looking over your work, it results
in better code. In fact, an earlier study shows that it results in 15% fewer bugs than code written by
solo programmers. Plus, it allows the driver to remain focus on the code being written while the
other attends to external matters or interruption.
4. An effective way to share knowledge. Code Fellows talks about how it could help programmers
learn from their peers in this blog post. It would allow programmers to get instant face-to-face
instruction, which is much better than online tutorials and faster than looking for resources on the
Internet. Plus, you can learn things better from your partner, especially in areas that may be
unfamiliar to you. Developers can also pick up best practices and better techniques from more
advanced programmers. It can also facilitate mentoring relationships between two
programmers. 5. Develops your staff’s interpersonal skills. Collaborating on a single project
helps your team to appreciate the value of communication and teamwork.

In sum, it helps your programmers learn from each other while coming up with programs and
applications with better code quality and fewer bugs.

Benefits:

● Fewer mistakes are introduced into your code because a lot of errors are caught as
they are being typed. This level of continuous code reviews gives rise to fewer bugs in
your code. You have shorter and tighter code.
● Two people can solve the problems that crop up along the way faster and quicker.
● Your developers learn more about things that are specific to the applications that they are
working on as well as software development in general, best practices, and other areas.
● You have more people who know how the new program works. This means that if one of
the pair leaves the company, it will not kill the project.
● Your team develops better interpersonal and social skills. Team members can
learn to communicate with each other, work together, and share information.
● Your team members are more satisfied.

Best practices for pair programming:

● Some best practices to follow when enacting pair programming include:

● Consistent communication. If there is no communication going on, then the developers
are likely not sharing thought processes.
● Switch roles consistently. This promotes the sharing of more skills between developers
and keeps them engaged.
● Pair up carefully. Ensure the two developers will be able to work together well, without
any hiccups. Otherwise, this will make for a poor work environment.
● Use a familiar development environment. Both developers should be familiar with the
environment they are working in. Otherwise, the balance of pair programming will be
disrupted.
● Submit code frequently. Quick commits to code pair well with switching between the
driver and the navigator.
● Ask for clarification when needed. Particularly when a novice works with an expert, the
novice should take any opportunity to learn.
● Take breaks when needed. Work at a pace that fits both developers.
● Set rules: Even before implementing pair programming, establish the rules and present it to the
 whole team.
● Take it slow: While kickstarting pair programming, we suggest that you not to start with a sea
change in developers’ work. Start with a few a few hours a week to try out the new method, see
if it works for you and scale it up based on results.
● Analyse pair composition: Consider which pair will complement each other, as well as who
can learn the most from whom.
● Change pair compositions: It is seen that when two programmers work together longer than a
few sprints, there decrease in productivity and a risk of conflict. Hence it is suggested to change
the programming pairs regularly.
● Plan pair programming before the sprint starts: The best way to effectively organise pair
programming is to carefully plan both staff compositions and responsibilities when planning a
new sprint. After analysing the status of individual tasks, it is the best time to determine who will
work with whom, what the pairs should do, as well as who will be the driver and who will be the
navigator, and how long will it last.
● Pair programming online for remote working: Gone are the days when Pair programming
involves two developers physically being in front of the same computer. Online pair programming
is gaining traction and though the numbers are yet to emerge, there is an opinion among the
developer community that pair programming online is more productive than in person.
● Gather team feedback regularly: Regularly collect feedback from team members on how they
find working in pairs. Common discussions and conclusions allow you to find the best solutions
tailored to the company’s current needs and employees’ preferences.

List of Pair Programing Tools:

All the pair programing tools that we have listed fall into one of the categories below:

● Collaborative integrated development environment (IDE): This type of tool lets users invite
other developers to collaborate directly in their IDE. Only the IDE is shared in this category.
● Single user sharing, dual user remote control: Tools that allow a single user to share their
screen while the second user can view and control the screen.
● Multi-user sharing, multi-user remote control: Here, multiple users can share their screens
and control apps at the same time. This category offers the most collaboration between the
coders.
Automated Build Tool is a software that compiles the source code to machine code.

Automation tools are used to automate the whole process of software build creation and the other
related processes like packaging binary code and running the automated tests.

These automation tools can be categorized into two types i.e. Build-Automation Utility and Build
Automation servers.

Challenges for Build Automation:

1) Longer builds: Longer builds take more time to run, it will increase the developer’s wait time
and thereby reduces productivity.

2) Large volumes of builds: If a large volume of builds is running, then you will get limited access
to the build servers for that specific period.

3) Complex builds: Complex builds may require extensive manual efforts and may reduce
flexibility.

Benefits of Automation Build Tools:

Using the build automation software has several benefits as mentioned below:

Saving time and money.

Keeping a history of builds and releases. It will help in investigating the
issue. Dependencies on key personnel will be eliminated through these
tools. It will accelerate the process.
It will perform redundant tasks.