devopsy.kinsta.cloud

Tag: Quality Assurance

Reasons Why Developers Should Test More

When I got started as a professional software developer, I thought awesomeness in development was measured by the lines of code (LOC) per day and how quickly code got to QA for testing. Coding a few thousand lines overnight gave one instant bragging rights, regardless of how well the code worked (or didn’t) in the morning. The more senior guys always acted like they knew better, suggesting that it’s not about the quantity but the quality. But I was too young and arrogant to listen. And, of course, I had to learn it the hard way. My seemingly amazing overnight code would show cracks once under the microscope of the QA team.

True today as it was then, most mistakes are tiny and easy to fix, but even small problems require a tedious set of steps from when a QA engineer finds the mistakes to when the developer fixes them and sends them back to QA for verification. Some bugs are the size of the Mariana trench and require weeks of work and thousands of additional LOC. And, even new code, once resubjected to QA, can generate bugs, therefore repeating the cycle without an end in sight. Of course, by this time projects are late and developers are tired, frustrated and burnt out.

After this happened to me too many times, I realized that maybe I was wrong. Maybe the experienced guys were on to something with this quality thing. They never seemed too tired, and their projects were in much better shape. I decided that for my next feature, delivering quality instead of LOC would be my priority.

I’m sure you think you know what’s coming next. I’m going tell you that I tested my stuff from that day on and it worked perfectly—no more boring bug-fixing. You think I’m going to tell you, you should do it too, right? Well, no. I actually spent a lot of time in my second attempt instrumenting my code better so that I could debug it faster as the need arose. I also spent a lot of time writing my own test tools because I didn’t have one. But I kept moving forward and learned the hard way. Here is what I took away from those moments:

Develop More, Bug-Fix Less

There are two common reasons for developers’ involvement in a project. Developing a new feature or enhancement is about creativity, as it gives one the opportunity to design and implement new things. And then there’s the challenge of bug-fixing, which is all about maintaining existing functionality within older, already-made things. As a developer needs to do both, often at the same time, minimizing bug-fixing time is important to have more time in which to actually be creative and develop new functionality. And the best way to minimize bug-fixing is to test code more, as it’s developed, to avoid the death spiral I describe above. Good initial quality will mean QA will find fewer bugs and it is very likely that the criticality of the bugs found will be greatly reduced. As such, fixes no longer would be a struggle on short notice; shortcuts that generate more bugs don’t have to be used; and developers can focus on new features as opposed to fixing bugs. In all, the reasons are to develop more, and bug-fix less to be more productive.

Be More Reliable

Bugs also are nasty in that they tend to appear really, really late in the game. The Murphy’s Law on bugs should be something like, “The hardest bug is found one hour before the release is pushed to production.” This typically happens because everyone is busy peeling the onion, finding and fixing bug after bug until they get the “system” stable enough for QA to crush it with those large-scale system test cases that expose that one nasty bug. It is an artifact of waterfall development but also happens in agile development, as no agile team can afford running long duration tests in a sprint. So what happens then? Who ends up in crunch mode? The developer. To avoid this, developers need to find and fix the easier bugs sooner, as they write the code. That way, the onion is half peeled once it reaches the QA team. The nasty bug will be found much sooner—if the developer did not find it and fix it already. In short, developers can be more reliable by avoiding last minute bug-fixing. And we all know, reliability in execution is fundamental for fostering trust with management. A trusted developer is the one that gets to work on important, meaningful projects.

Be More Flexible

While in an ideal world the design of a feature is not changed frequently, in real life the exact opposite is true. At some point, even regularly, developers will have to modify the code as the scope of the features keeps changing. Massive code changes such as refactoring, if not done right, can send developers right back to a long, teeth-grinding, bug-fixing period. Avoiding it by testing early, as they change the code, offers a significant advantage—flexibility. Developers would be able to accommodate required changes more quickly.

Agile Development is Critical

Let’s do a quick recap: By simply testing code as it is written, developers can spend less time fixing bugs and more time developing new features, to become more productive, more reliable and trustworthy and even more flexible in implementing changes. This takes us to our final reason for early testing: Agile development is no longer nice to have, but business-critical. All of the attributes described above are quintessential for succeeding in an agile team. Developers are expected to be flexible, reliable and build a lot in short time periods. The days of trial and error, of learning the hard way, are gone. Today, we need to go from design to development to testing to going live in days, not months. Quality is what differentiates products. Developers need to do all of this to be successful.

About the Author/Gabriel Chiriacescu

Gabriel Chiriacescu is the director of Software Development at Ixia, with more than 13 years of experience in embedded software development. He is currently leading the product management effort for the new Ixia Developer solution, an agile test tool designed specifically for developers.

At Ixia, Gabriel has led multiple engineering teams responsible for developing market-leading test solutions in a variety of technological areas, including wireless, broadband access, data center, triple play, authentication and security.

A native of Bucharest, Romania, Gabriel holds a BS in computer science from the Polytechnic University of Bucharest. After living several years in Los Angeles, Gabriel is now based in North Carolina and enjoys discussing CICD, SOA design patterns and the evolution of software development.

April 27, 2016
How Mobile Testing Converts to Greater Earnings

From a business’ sales strategy to the type of coffee it decides to stock in the company lounge, every decision boils down to this: How will it impact this year’s earnings? That’s what makes testing critical for any business with a mobile app: Having a poor-performing app is just like throwing money away.

There are three primary ways mobile testing translates into more cash for the company: corporate image, performance and speed to market. Read on for the details.

Testing and Corporate Image

Treat your mobile application like the face of your brand.

The majority of time people spend on anything digital is over a mobile application. Users spend more time on their smartphones than they do on their desktop and even television. From a business perspective that means any customer, both real and potential, will experience your brand over a mobile app more than on your TV commercials, physical billboards and even website.

They will see you over their phone more than in your store.

Mobile testing makes sure that the lights are on in your business, and that the air conditioner is working. We take for granted that when we enter a place of business everything is working properly. If something is off, we immediately recognize it. The same holds for a mobile application. If a function is not working right or is performing slowly, it will impact the user’s decision whether or not to become a customer.

If it is working perfectly, the larger audience that mobility commands will generate a larger customer interest in your brand.

Testing and Application Performance

The faster the app, the happier the customers.

The instinct for testing applications is to make sure the code itself is working. This is the basis of functional testing. In the age of desktop apps that work directly over the computer’s operating system, or even web apps that work over a local connection, the speed at which your application moved was usually assured.

Mobility has changed the rules. A mobile app working on a portable device can operate over any of the 400 mobile networks worldwide. It can have to brave poor network conditions, being confined to an elevator, or even riding through a tunnel. All of these different environments affect the speed at which your functions execute, which is no longer static.

If a function moves to slowly, the app will be considered broken. In fact, 90 percent of the mobile applications on a phone right now won’t be there in a year’s time. This is the need for performance, namely network virtualization testing: It makes sure your application provides potential customers with a smooth experience.

A smooth experience is the best way to guarantee return business, and retaining a customer is 5 times more cost-effective than acquiring a new one.

Testing and Speed to Market

Time is more important than money—with the right tools.

There are 20,000 mobile devices out there, running on four different type of mobile operating systems, all with their own set of versions both new and old. Every day there are devices and operating systems enhancing their capabilities with expanded capacity and new features. This demands that your mobile application adapt by including new features and capacities that capitalize on what the platforms are now offering.

The key to DevOps is to develop, test, and release the most cutting-edge version of your mobile application as quickly as possible without sacrificing quality in speed or execution.

Even if it is for only a short time, offering features your competitors are not ready to release is like having monopoly on a part of your market: You stand alone. Those customers looking for the best app will have only you to go to.

Mobile testing is the most arduous step in the DevOps process. A quality test automation tool that includes both performance and functional testing, connecting to a mobile lab enabled by a mobile cloud-testing tool, will accelerate your mobile testing while shortening the release time for your latest app incarnation.

Conclusion

In the age of mobile, everything that impacts your mobile application impacts your bottom line. Mobile testing reduces expenses, retains customers and enables your development team to design and release an application that can add solid growth to your company’s coffers.

April 25, 2016
An Engineering Think Tank to Change the World

In his famous book “Mythical Man Month,” Fred Brooks says, “Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.”

While being very fond of engineering on the big scale, such as building millions of high-end and yet individually configured cars or double-deck aircraft or space ships, for example, I have always asked myself, why the most promising industry—software engineering—is so often not capable of doing engineering on that scale, too? Or, why are so many big enterprise IT projects painful in so many ways?

With these questions that nobody seemed to be really interested in on my mind, one day I met some higher corporate management, who wondered why the IT department would be so reluctant to follow their lean transformation advice and instead talked about some agile and continuous integration thingy.

From that moment, I understood that everything necessary to radically upgrade software engineering was already there! The biggest problem was that we do not communicate enough—and furthermore, there is no holistic view on the complete IT value chain.

By that I mean we need to create awareness for the value chain, starting with digitized formal models of business processes and written business requirements.

That was how the following chart came to existence, and I still love it. Apparently, most awesome things happen on the borders of separated knowledge domains; you need just to talk to colleagues from departments you’d never talk to! What if we would mix knowledge from big industry, best available process improvement and quality assurance methodology, and apply all this to how we design, build and deliver software?

At first I thought I had found a new perspective on DevOps, but now I believe there could be more to it. Well, now the door to the radical innovation is open! Just imagine: What if we would apply the Internet of Things approach to our industry? Maybe we could close the loop of process improvement in software development and test, moving it to real time and running optimization not by ambiguous frameworks but by hard facts coming from virtual sensors, with unprecedented levels of transparency?

This was how a couple of friends and I came to the idea of our foundation we call SIGSPL (Special Interest Group for Software Production Lines). This public organization is a non-profit think tank, built around three generic domains—Labor Automation, Analysis and Advanced Visualization—which we consider to be the three pillars of the upcoming convergent software engineering in the post DevOps era.

We are sure this sort of thing inevitably will happen, but our mission is to catalyze these processes to make radical innovation happen intentionally and faster, so we all can build information technology that rocks!

We are a small team of six with some infrastructure, publications at our blog and a well-established yet growing knowledge base. We would like to reach out to more like-minded people to let this idea grow and change the world. Our plan is to foster further exchange and discussions between DevOps experts and other specialists “unexpected” in this context, such as production lines and supply chain management experts, Six Sigma Black Belts, 3D artists, hackers, venture capitalists and many, many others.

Our proof that we are not ponding to nowhere is our magic triangle diagram, showing some well-known tools we map to the three generic domains, which are also of high interest for venture capital. Our question to the world is, What would appear in the middle of this triangle in, say, five years?

About the Author/Peter Muryshkin

Peter studied M.Sc. in Applied Computer Science and works in management consulting roles focusing on complex analysis and customer satisfaction, including IT Business Analyst and Change Manager. His current scientific research focus is digital transformation applied to the field of software engineering in large distributed organizations.

LinkedIn: https://de.linkedin.com/in/muryshkin
Team blog: http://sigspl.org/blog/

February 25, 2016
QA in the DevOps Era

In software approaches that produce monolithic applications, it is not uncommon to find siloed teams, with development, testing and operations each an island unto themselves. The responsibilities of test and development are distinct from each other and are not meshed into a hybrid team as you might see in advanced DevOps shops.

“QA (quality assurance) always comes late in the game to verify or test the software developed by the development team against the predefined specifications know as software requirements,” says Venkata Vinay Pandella, team lead at Nisum Technologies Inc.

That’s the view inside and among these teams in which legacy development approaches still flourish. The rest of the enterprise sees these teams altogether differently from how they see themselves. “Even in a traditional software engineering organization, folks outside the engineering team generally consider Development, QA and Operations teams as a single group with a single responsibility to deliver a quality software product,” says Pandella.

Even when Dev and Ops do embrace each other, the rest of the enterprise often maintains the same POV it had when Dev, Ops and QA were three entities and not one. How do DevOps and QA see QA after the shift?

DevOps as a Foundation for the New QA

Enterprises, the business units, Dev and Ops all expect DevOps to propel software using continuous integration (CI), continuous delivery (CD) and ultimately continuous deployment techniques that are fueled by and gain traction using automation. The more processes that Dev and Ops teams are able to automate, the more that DevOps accelerates the process of software delivery and deployment to the delight of software consumers and the business.

DevOps enables teams to push software out weekly, daily and hourly through continuous software improvement. This negates the many obvious downsides of applying the traditional software development approach, which requires excessive planning, cross-team coordination, staging, testing and releases of monolithic blobs of software all at once. “Given that companies organically adopt DevOps together with agile software development practices, business managers are able to fulfill the objective to get high-quality software out to market faster,” says Pandella.

To meet the goals of DevOps, QA must feed into the automated development process and help teams to achieve increasing software quality and faster time to market.

QA: The Quality Icing on the DevOps Cake

According to Pandella, QA specialists and teams have a number of roles and responsibilities in DevOps:

• QA should prevent software defects at the earliest point during the software development process rather than find and report on software bugs after DevOps has produced the software. This will help to ensure that customers experience as few defects as possible.

• QA takes ownership of and responsibility for continuous software improvement and software quality tracking throughout the software development life cycle.

• Every QA team member is responsible for identifying problems not just in the product but also in the process, and recommending changes wherever they can to improve the continuous delivery of quality software.

• Tests must be in code, based on the designed release cadence to publish a new release every week, every day or every hour. There is no room for manual testing—QA must develop automation systems through code that can ensure quality standards are maintained.

• Automation rules: QA should automate anything that can be automated.

• QA testers are the quality advocates, influencing both developmental and operational processes. They don’t just find bugs; they look for any opportunity to improve the quality of software through the software development process.

• QA must move beyond functional testing, because even a small, nonfunctional defect introduced into a critical transaction process on an e-commerce website can bring a business to its knees. Many organizations have mature processes for automating functional testing; they are only beginning to apply these practices to other areas of testing such as security and stress testing. In particular, load testing and stress testing are critical disciplines for DevOps organizations that move at high velocity.

February 9, 2016
What it’s Like Working as Quality Assurance in Consultancy Companies

Quality Assurance (QA) engineers working at consultancy companies should embrace trying new technologies and solving problems. This role is best defined by two words: variety and challenges. QA engineers at consultancy companies must pay great attention to detail and check all of their actions meticulously to make sure everything is being done correctly. The position also requires equal focus on the quality of the software application and client expectations, and constant communication between all individuals and teams involved in the process.

Thinking about a job in QA? Here are some more details about this demanding yet rewarding position.

Expectations

Working as a QA engineer in a consultancy company demands very strong communication skills, flexibility and prioritization skills to help deliver a high-quality product in a timely manner. This role requires continuous improvement of both the process and working methods, which are not limited to testing or preventing defects but also consider the application’s lifecycle and ways to improve the product.

Challenges can arise from working with myriad intricate software applications and environments. As the complexity of the software and the multitude of targets that can be addressed increase, so do the technical and communication challenges. A good QA engineer should always plan for this complexity in each project and be prepared to handle these challenges.

Variety

QA challenges and projects become even more complex and varied at consultancy companies. In a consultancy company engineers work with multiple companies from different cultural backgrounds and different levels of technical experience. Sometimes there are significant cultural differences across projects and within a team, which can have a big impact on the overall quality assurance process. To overcome any obstacles, QA engineers must communicate frequently with each company to answer any questions that may occur during the project lifecycle and to keep it on track.

For each project, the QA engineer is expected to contribute to various parts of the process, which can include everything from client and internal team communications to delivering technical requirements. In addition, QA engineers must ensure technical requirements are communicated, tracked, planned, scheduled and executed correctly for each team. This is where attention to detail and prioritization skills are key, in making sure the correct communication is reaching the correct teams so the project runs smoothly and successfully.

In addition to the innate variety that exists within the QA role, there is a fair amount of diversity, with multiple clients of different sizes spread across numerous industries. While some clients write out the project specifications and define clearly the expected outcome of the software application, others don’t, creating another opportunity for a QA engineer to contribute to a new project.

Finally, QA engineers in a consultancy company constantly work with a variety of platforms and applications, from desktop to mobile projects and web-based to server-side. I see this as a positive—it keeps you on your toes and you constantly are gaining additional technical and architectural experience.

As a Quality Assurance consultant, you will be expected to work on a wide variety of technologies and communicate effectively under a variety of circumstances. While the position can be challenging, it’s never boring. And knowing the project is successful because of your work is extremely rewarding.

January 4, 2016
Service Virtualization – Window into “Advanced” DevOps

The new style of IT is pushing DevOps teams to reinvent software building, validation and delivering processes with an aim to shrink development cycle time and reducing defects in production. But in constrained testing environments, DevOps teams face a range of challenges in following the continuous integration and delivery approach for large multi-tier applications. Because release cycles are compressed application testing coverage, and what you test is constrained. And on top of that, consumers demand for an always-on, easily enhanced and mobile experience that comes with cloud-sourced and cloud-delivered composite mobile app offerings.

(more…)

December 10, 2014
You Asked for Quality, You Got Alienated QA

The role of Quality Assurance (QA) is creating a bit of a buzz these days, because even as teams and budgets are shrinking, the demand for better quality is increasing. The chilling repercussions of service disruptions caused by software flaws warrants interest even at the executive level: “Nobody’s madder than me about the fact that the website isn’t working as well as it should,” said President Obama when HealthCare.gov went down last year due to software defects.

(more…)

November 24, 2014