Appreciating The Role Of QA On Valentine’s Day

It is Valentine’s Day this week. It is that time when we reflect, appreciate, and celebrate the one we love. While Valentine’s Day is often associated with relationships that are romantic in nature, the holiday incorporates other relationships nonplatonic in nature as well. Children give valentines to their teachers and classmates. Many people send gifts and cards of appreciation and love for parents or grandparents. There is even a growing trend for ladies to celebrate “Galentines” Day in which ladies celebrate their friendships with their nearest and dearest gals.

At Xcelacore, we love business-driven technologies, especially software development, DevOps, and quality assurance testing. Our infatuation with these got us thinking about how these technologies depend on the associated relationships with one another. Although these components certainly don’t experience romantic or even platonic love, they do depend on one another. So, we wanted to take a look at the close relationship between DEV, QA, and DevOps in honor of Valentine’s Day.

 

QA Helps Complete Dev and DevOps

In the iconic movie from the 1990s, Jerry Maguire cites the infamous line to Dorothy, “I love you. You complete me.” We all want to feel complete, and software is no different. Without QA, a software application may never come to its completed fruition thanks to bugs. QA completes the development process by eliminating mistakes and bugs, thus improving the quality of the code.

 

QA makes Dev and DevOps better

It is a beautiful thing to fall in love with someone who makes you a better person. QA makes your code better. Better code brings higher value for the business that uses it. That value then touches the lives of multiple stakeholders, improving their lives in little ways along the way.

 

QA and Dev work towards long term goals

Couples are always making dreams together; the dream vacation one day, the house they plan to build, the children they plan to raise. Companies and developers have long term goals, as well. They dream of creating software that will solve problems, generate greater efficiencies, and create recognized value. QA walks side by side with the developer, working towards the goal of seeing their software creation released to the world.

 

QA and DevOps share incremental victories

While successful marriages share common long term goals, it is the shared intricacies of daily life that bring them closer together. They work together to get the kids through school, make date nights, and help one another through sickness and worry. QA plays an integral role in the culture of DevOps. Whether it is creating code for a new application feature or merely modifying a navigation button, QA and DevOps work hand in hand to ensure that every incremental release is the best that it can be.

 

QA helps challenge development

Many people, both women, and men want a partner who will challenge them, for it is when you are challenged, that you grow. You may have the most exceptional team of developers on the planet, but they aren’t perfect. QA serves as that second set of discerning eyes to examine all of their written code for bugs and inefficiencies. This will make your developers better, which leads to better code and better results.

 

The sum is more significant than its parts

A great couple is defined by two people who work cohesively as a team. They both have a role in the relationship, yet they accomplish more united together. QA is the ideal teammate for development and DevOps. They both have a different purpose, yet those two roles merge seamlessly together. In fact, the boundaries of QA and developer can become blurred in a DevOps environment. All parties on the team are dedicated to making the highest quality code possible in the quickest amount of time. In that way, the end product is better because of the collective effort of both parties.

 

The pairing of strengths and weaknesses

A healthy marriage is one in which each partner’s shortcomings are canceled out by the other’s strengths. There are not many programmers out there who enjoy testing code consistently, and that is ok. Your developers don’t have to when they are paired with a QA partner. All QA does is test code, and it is very good at it. This removes the burden of testing off the shoulders of your developers, allowing them to focus on what they do best- create great code.

 

Xcelacore plays Matchmaker

There are many ways to meet your soulmate. Some prefer online dating sites, while others prefer the traditional organic way of finding someone. This Valentine’s Day, think of Xcelacore as a matchmaker. In fact, think of us as Cupid. If your developing efforts require the introduction of that perfect partner, then we have the match. Our automated QA solutions are the ideal fit for your current development team. Xcelacore automated QA solutions can bring increased efficiency, improved accuracy and reliability, faster validation, and greater consistency to your coding projects. Quality assurance may not be the first thing you think of on Valentine’s Day, but providing QA solutions to our clients is something we think about every day of the year.

Happy Valentine’s Day!

 

 

Appreciating QA

It’s not exactly Shakespeare, but it is a question many companies are asking today.  It’s a question that is particularly relevant to organizations that are currently mapping out their digital transformation as they attempt to both maximize their existing technology frameworks and monetize their technology investments.  The question applies especially to Enterprise Resource Planning (ERP).  ERP is the lifeline for many businesses today.  As such, it is the collective depository of shared databases that support multiple functions that are used by business units across the organization.  It provides the backend magic that powers so many business processes such as orders processing, pricing, billing, inventory and reporting. 

The Pros and Cons for Coupling the Two

The Advantages of Joining ERP & Web Platforms

The primary advantage of coupling your ERP and web platforms together is the apparent simplicity of consolidating them into one package.  That means one purchase decision, one implementation and one vendor to support it all.  Sounds nice, right? This approach has been popular since the early years of IT as IT centers focus on building large monolithic systems.  In fact, the practice of consolidating different component types is in vogue today as large networks are reducing their datacenter footprint and turning to hyper-converged infrastructure solutions.  HCI (Human Computer Interaction) consolidates the compute, storage and networking components of the datacenter into a single box, allowing admins to manage all components through a single pane of glass.  This manner of coupling different technologies is highly popular today as companies strive to simplify their network architectures. But coupling ERP and web platforms isn’t all rainbows and roses.

The Disadvantages of Joining ERP & Web Platforms

Consolidation has definite disadvantages. If you are old enough to remember the single-console entertainment systems of the early 90’s (the ones which combined TV, DVD and VCR) or the all-in-one boom boxes – it is easy to see the primary shortcoming of consolidation. No individual component can be upgraded without purchasing an entirely new console.  While coupling platforms through HCI has great benefits, it’s able to do so by commoditizing the technology of each component. 

ERP, however, is not commoditized.  It is a highly complex business process management system with proprietary elements and intricate dependencies.  Coupling it with a web platform simply adds to this complexity, greatly restricting the ability to scale out.  Changing web technologies and upgrading the ERP platform can also pose issues that negatively impact web and mobile applications.  Because of this, new release frequencies are reduced which in turn limits new functionality innovation.  This doesn’t bode well at a time when agility and nimbleness create huge competitive advantages.

The Pros and Cons for Decoupling the Two

The Advantages of Decoupling ERP & Web Platforms

The speed of innovation today far outpaces the upgrade processes and traditional software development practices of yesterday.  That is why so many organizations use the new approach of DevOps in order to increase an organization’s ability to deliver applications and services. Under DevOps, developers can work in unison to create and upgrade separate features which speed the velocity of development and deployment.  By decoupling your ERP and web platforms, developers can work independently and in parallel.  This modular approach allows for subtle differences to be made without worrying about dependencies or corresponding changes to the other end.  This can greatly increase a company’s operational efficiency and agility, giving it the ability to respond to changing needs in quick fashion.  Decoupling also increases resiliency as down time on one platform does not affect the other. 

The Disadvantages of Decoupling ERP & Web Platforms

Decoupling does introduce some drawbacks, however.  When you decouple your web platform, it often means that more vendors are involved, increasing the complexity of communication and responsibility.  Also, implementation and initial costs can be higher as more players are involved.  Higher costs are seen on the front end and are offset by a lower cost of ownership because of the increase in flexibility and increase in the rate of innovation.  Organizations that choose to decouple should also plan on an influx of personnel with the web development skills required to build and maintain the platform. 

Sorting Through Your Organization’s Individual ERP Situation

The truth is that there is no right or wrong answer to the question at hand; only an answer that is best for your particular situation.  It depends on what your business’s processes and goals are, and how each path lines up with your organization’s particular requirements. 

Have questions? Please feel free to reach out to us. We stand ready to listen to your business and technology challenges and help you find the right solution for your business.


Ready to Talk? Contact Us.

You need a software application that does (blank), you meet with the developers, and a few months later you have your new software. Easy, right?  If only it were that simple.

Most people agree, creating customized software is generally a complex process. It requires a great deal of planning, collaboration, teamwork and management. And the stakes are high. A poorly implemented software release paints a negative image of the development team as well as the organization that hired them.  That’s why the software development lifecycle requires some type of methodology to oversee the development operation.

There are two primary methodologies you should be aware of – Waterfall and Agile.  A quick web search will garner numerous links in which these two approaches duke it out as to which one is better.  However, to say one is better than the other is like saying that owning a truck is better than owning a compact car. If you need to haul a lot of stuff, a truck is better.  If you live in a very dense, urban area where parking is at a minimum, a compact car is better. The approach you choose depends on the situation at hand. Not sure which approach is best for your project? Read through the descriptions of each below to understand each one. Still have questions – feel free to reach out to us and we’ll help you decide.

Waterfall

First off, waterfall may seem like a strange name for a project management process – but it’s a common term in IT;  and many refer to it as “traditional.”  One possible way to explain the name is that just like a waterfall, water can’t go back up after it cascades downward. A waterfall project is comprised of various stages and each one must be completed and signed off on before being passed on to the subsequent stage.  Each successive stage has its own personnel team and relies on information forwarded from the previous stage. Waterfall is ideally suited for instances in which there is a defined vision by the customer of what they want. To use an antiquated example, think of Henry Ford and the Model T.  The car moves along the assembly line as teams of employees complete their assigned tasks. What starts out as a simple frame in the beginning, drives out of the factory a completed car, ready to hand off to the dealer. Using a waterfall approach, the car moves along from start to finish in order.

In terms of a software development project, the successive phases are usually broken down into these basic stages:

Research – Analysis – Design – Construction – Testing – Implementation

A waterfall-oriented development team usually consists of four roles that include a project manager, business analyst, developer and tester.  Compared to agile, waterfall puts more emphasis on planning on the front-end. Progress is easy to measure and end results are more predictable thanks to detailed planning and design in the early stages.  You could say that waterfall sticks to the script as the plan is conceived at the beginning and everyone follows the plan in proper order.

Agile

As its name implies, this methodology is about agility and flexibility.  It’s highly suited for software development due to software’s elastic nature. Unlike, waterfall, there is a more loosely defined vision that guides the process. There are no defined stages.  Agile is a continuous deployment practice made up of “sprints.” A sprint is a short span (2-3 weeks per sprint is very standard) in which products are planned, developed, reviewed and released.  But the definition of “product” can vary from project to project. Agile isn’t designed around a single release, but multiple releases, that may in fact induce further releases.

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, this sprint may then be followed by another sprint that centers around the release of a new application feature. This perpetual cycle can go on for years as the software evolves.  Each sprint is loosely defined by a storyteller who creates a story of what the product at hand should accomplish based upon the input of the stakeholders. Because there is no highly defined plan at the beginning, 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.

Although the agile approach may sound chaotic, it is actually a very orderly process that allows for constant customization and refinement.  While the end product may be far different than its vision, the customer and other stakeholders are continuously involved throughout the agile process.  One of the goals of Agile is to get something of value in the hands of the customer as soon as possible. In the case of a new application, the aim of the agile team is to get a basic working application delivered as soon as possible.  Continuous sprints then take place to add new features, many of which may have never been conceived at the outset. Unlike waterfall where testing is done at the finale, testing is continuous, sometimes operating in parallel to the code development.

Summary

As you can see, each approach is very different.  While Agile is definitely the newer methodology of the two, it is readily gaining acceptance in the software community.  Both approaches have their advantages and disadvantages. As stated, there is no overall better way, only a way that is better suited to the needs of your project and organization.  Before you begin a project, be sure to find out which approach your development team utilizes.

As technology and business leaders, many of us have been part of a decision around building new technology solutions to create new services or products. In this mobile-first era, one of the first questions you are challenged with is – do we need an App for that? Or can this service or product can utilize just the mobile web version?

We all wish this was an easy yes or no answer. But the answer may be much simpler than you think. There are 3 main criteria you need to consider that will help you make the decision.

#1 – Application feature set

If your product needs built-in phone features like GPS, Accelerometer, Contacts, Push Notification, etc., then you will need to build an app. From the technological advancement with HTML5, some of the phone features can be accessed so you may be able to get away with only a mobile web version. You will need to research the specific feature set requirements with what is possible to do within HTML5.

If the answer is – yes, I have to use phone features that are not available through HTML5, then your decision is made, no need to read further!

#2 – Audience

Just because a customer downloaded your app does not mean that they will be using the app for life, or even at all. The data shows that people actively use only 5-7 apps in a given month. Unless there is a compelling need for the users to download the app, they will not.

Again, your answer here will determine what direction you take.

#3 – Resources

Since you have read it this far, the assumption is that the decision is still pending. Developing a mobile app is a skillset that not all developers hold. You should carefully evaluate the resources at your disposal in making the decision. Not only do you have to build an app (possibly on multiple platforms – iOS, Android, Windows), but you also must manage and maintain it. You should consider the total cost of ownership as you make this decision.

In conclusion, whether you build an app or not, you will need to develop a solution that is mobile responsive at the least.

Sincerely, The Xcelacore Team


Ready to Talk? Contact Us.