“Java is Dead”, “Java is Dying”, “Java is Obsolete” and other variations on the meme of Java mortality appear frequently on line in the IT “press”. These are click-bait, intended to draw your attention to a headline, or get some cheap SEO. For the more complex and nuanced truth about trends in Java usage – look beyond opinions for evidence.
About two years ago, I was working on a project written in the Go language. Go was originally developed by Google in 2007 for internal use, but was later released (open source) for general use. The project I was on was a large enterprise-wide service that collected large amounts of data (and did it well). This article introduces some of the interesting aspects of the language that might entice you to consider it for your own use, while pointing out a few things of which to be aware if you do.
Microsoft’s WPF bindings are a fine piece of technology. They are flexible and powerful, allowing changes to your objects’ properties to ripple through the rest of your application with a minimal amount of coding effort.
by Larry Van Sickle, Senior Software Engineer
AngularJS is a versatile toolset for building browser-based applications.
How can a developer make the elements of a chart clickable using NVD3 in an Angular application?
by Rema Sreedharakurup, Senior Quality Assurance Engineer
It seems today that no discussion about software development is done until someone brings up ‘Agile.’ And for good reason, as Agile is all about agility – an Incremental and iterative delivery model which focuses on business value, encourages flexibility and rapid adoption to change. It’s based on collaborative efforts to achieve common goals.
The agile principles & values are very short and sweet, but in the real world, Agile is not that simple. Remember, it’s a collaborative effort that requires people – Developers, Testers, all the folks involved in the product development who are trying to perform their best in this transforming phase and get things DONE… all the while trying to get accustomed to new processes that get introduced to improve delivery, and where output is expected quickly. Though, as Albert Einstein once said, “in middle of difficulty lies opportunity.” Hence for me as a Test Engineer, this transition to Agile opened up a wide array of opportunity where I could wear many hats – as a developer, as a tester, a customer advocate, a constant learner, and much more.
Here’s how I see each of these hats fitting my head, and perhaps yours, too. Continue reading
by Troy Rudolph, Senior Software Engineer
The market certainly offers many test automation tools for testing in a variety of environments, but there is a relatively new one I particularly like for automated testing in web applications. While Codeception is intended primarily for testing PHP applications, the UI testing tools may also be used to easily create automated tests for web applications, as well.
In Codeception, these tests are referred to as acceptance tests. These tests are based on the notion of Behavior Driven Development (BDD). Essentially, BDD states that tests should be specified in terms of desired behavior. In the case of BDD, the behavior described is that of a user (or tester). To learn more about BDD, I would encourage reading the inventor’s article at http://dannorth.net/introducing-bdd.
A simple test might look like… Continue reading
By John Cavazos, Senior Performance Test Engineer
At one time, it was very common for companies to use a homegrown solution to performance test their software. This was mainly due to two factors:
- the lack of available, cost-effective commercial testing tools
- the complexity of their software
The situation is different today as it is common to find excellent, free, open-source tools online. These high-quality, stable, easy-to-use tools don’t have the inherent maintenance costs associated with using homegrown solutions.
There are now several industry standard tools available that can be used to performance test most, if not all of the features a company might need. What isn’t readily available can typically be added to these tools with minimal effort due to their open-source nature. Here are a few I have used: Continue reading
by Chris Durand, CTO
Let’s be honest, Quality Assurance is a necessary evil. Many of you have probably wondered why developers can’t just get it right the first time. Why do we pay developers to write bugs, and then pay testers to go and find them?
The answer simply stated is — writing software is hard. Software developers need to be extremely detail oriented, yet also keep the big picture in mind. They must balance short-term tradeoffs with long-term considerations. They often have to learn new tools and technologies with each project while balancing the demands of outside influencers. Oh, you needed that feature or bug fix done yesterday? And you want that application to work on all browsers released in the last 3 years (that’s 24 versions of Google Chrome alone since March 2011), plus mobile? It’s no wonder developers struggle to write perfect code every time.
While it can produce quality results, the old model of throwing code over the wall from the development team to the QA team is inefficient. We that build software have to do more for less, faster, and in a more complex environment than ever before. The rise of automated unit testing and Test- or Behavior-Driven Development (TDD and BDD) is an attempt to realize improvements. By testing at the core (that is, with the developer), we find bugs as early as possible (which yields tremendous savings as discussed in the post https://bridge360blog.com/2013/12/04/5-ways-qa-supports-development/). Automated unit testing also makes it easier to update the application going forward by identifying unexpected broken dependencies in the code before they get in front of a customer. Continue reading
By Paul Bostrom, Senior Software Engineer
Do your software testing teams ever discover bugs that seemingly should have been found by the developers’ unit tests? Quite often, the developer actually did unit test the software, but perhaps simply failed to think of scenarios using the problematic inputs. What if we could tell the computer to “think” of all the values used in our unit tests? This is the approach of property-based testing.
Instead of specifying a limited number of inputs and outputs for testing a unit of software, property-based testing specifies properties that a unit of software must hold, and then relies on the computer to generate the test values.
The authoritative library for property-based testing is called QuickCheck (http://en.wikipedia.org/wiki/QuickCheck), created for the Haskell programming language, but implementations of the library exist for many other popular programming languages. To illustrate the differences in these two testing approaches, we will use a simple example — testing a square root function. Continue reading