The article this blog post is written about can be found here.

I chose this article for this week because I was curious about integration testing, as most of what we’ve done up until now has been unit testing.

Integration testing, broadly speaking, is defined as testing used to determine if the connection between two systems work. Systems can be a lot of different things – different parts of the code in one software product, multiple software products working together, your code and a database, a database and the internet, etc. Sometimes individual pieces can work fine on their own, and yet the whole breaks down once they are combined.

The article offers a scenario where someone takes a picture, uploads it to twitter with a caption, and sends the link to a friend as an example of where faults discovered by integration testing might be found. If one of those steps fails and the tweet never shows up in TweetDeck, testing would have to be done to determine where in the chain of connections the fault lies, and then what specifically went wrong within that connection. The article suggests starting this process by reviewing the log files, which should offer an indication of how far the tweet managed to get.

The article gives electronic health record systems as another example of complex systems where integration testing is needed. There are about 20 different popular EHR systems in use, as well as ones created by healthcare companies, which all store data in one way and send it out in a different way. Records go out to insurance companies that want to receive them in different formats. There isn’t one record to represent all the medical information about one person, but scattered records containing different information based on what each party needs. This situation demands thorough integration testing of the connections between the EHR systems, billing companies, and insurance companies. With so much that varies, there’s a lot of opportunity for failure.

Reading this article helped me understand the different scales on which integration testing operates, and that I can’t think of a piece of software as existing by itself – it’s going to interact with others’ code and with elements in the outside world. It’s necessary to consider not just the software itself but the bigger picture. With this in mind, I will think about the ways in which my code interacts with other components and have an idea of where to start testing those interactions.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

A recent blog post from Cigniti discusses the importance that Agile Testing has in enterprises (http://www.cigniti.com/blog/agile-testing-really-helpful-enterprises-stay-innovative-competent/).  The post does not argue whether or not Agile Testing is essential for enterprises, but instead discusses why it is essential for enterprises to employ this method of testing in it’s daily operations.   It is becoming increasingly clear that their are many benefits to incorporating Agile Testing in their enterprise.  Enterprises need to be flexible and able to change in order to stay competitive and try to keep an edge over rivals.  One of the biggest and most obvious advantages of Agile Testing is the flexibility it provides to not only the testing team, but all teams involved.  The short sprints that Agile Testing provides allows companies to adjust their goals quickly and easily if the customer or the development teams changes their desired outcomes.  This is essential to businesses that want to maintain an advantage over other companies and stay attractive to clients.  Agile Testing also helps improve the overall customer experience.  The flexibility and constant ability for change helps a business adjust to a customer’s inevitable desire to change their minds on what they want from their product.  Agile Testing also helps the testing team and development team communicate more and relay information back and forth to work with each other rather than against each other.  While there is always risks in producing a product Agile Testing greatly cuts down on these risks.  Being able to stay in constant conversation and working in sprints it allows teams to catch and resolve issues as they arise.  Companies can then adjust time frames as well as end user products in a timely manner rather than waiting until closer to the release date and having to push the launch back completely or risk losing the contract with the customer.  These all boil down to communication between all teams involved on the project.  Without proper communication Agile Testing falls apart and loses much of its efficiency.  It’s important to realize that the completion of a quality product that satisfies the customer’s needs is more important than the pride of any individual or team involved.  Programmers should be ready and willing to bring up any issues or faults that are found as well as be receptive to any constructive criticism from other team members.  This allows Agile Testing to work effectively and efficiently throughout the entire development process.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

In this blog post, Pratik Kothari talks about software quality and gives us some tips on how to develop quality code. Software quality has been more important recently, as companies slowly learn asking for a realistic time-frame allows bugs and quality assurance issues to be caught early, saving time wasted on debugging later on.

What Does Software Quality Mean?

Organizations have different quality standards, for the author, “software quality means that your code is meeting the bare minimum business expectations and do not have serious usability issues.” He goes on to say that it’s next to impossible to implement software without any defects, and that having defects in the system does not indicate poor quality software.

“If the software is meeting business expectations at the end without compromising the user’s ability to perform their tasks, the quality of the software is acceptable.”

Who Owns Software Quality?

The author says that software quality should always be at the center of the software development process and should be owned by a team, not one person. Testers take the brunt of identifying quality issues but it’s everyone job to ensure your product is clean and free of major bugs.

When to Define a Quality Strategy

The strategy for maintaining quality should be one of the initial steps of a product. Everyone should be on the same page on what quality standards are to be met and what is considered done.

Quality Strategy

Having a quality strategy is key to ensure everyone knows the expectations of quality and done-ness. The quality strategy “should be owned and defined by the Project Manager along with Architects, the Testing Lead, and the key team members. Ideally, it should cover the below quality-related objectives.”

• How to identify personas.
• How to write and store test cases.
• Unit testing plan.
• Regression testing plan.
• Automation plan.
• Performance testing plan.
• Code Quality Review.
• How to measure quality.

Step 1: Communication

Giving team members a clear picture of what is expected, and who is accountable for what. Like giving developers a heads up if they need to add test development to a project, allowing them to give accurate estimates.

Step 2: Training

Ensuring that gaps in skills are filled with time to learn skills or new members who know the skills. It pays to keep team members up to date on the latest skills.

Step 3: Infrastructure

It’s important to “utilize the greatest and latest infrastructures for quality strategy.”

Step 4: Continuous Improvement

The team regularly reviews what is, and what is not, working well.

I chose this blog post because it had good information on ensuring quality standards in code. The content of the article had good tips for ensuring success and communication is possible in a team. I learned the importance of communication, training, good infrastructure, and continuous improvements. I will use this information in the future when working on a team of people, and strive to do my part in creating quality code.

The post Four Practical Steps to Execute a Software Quality Strategy appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

In this blog post, Riaan Nel goes over an example of the Builder Pattern, a creational pattern used to create and configure objects. The following example is from Effective Java by Joshua Bloch.

The Problem

In this example, we are part of a Java team working on software for a bank. We need a way to represent banks accounts.

BankAccount.java

public class BankAccount {
    private long accountNumber;
    private String owner;
    private String branch;
    private double balance;
    private double interestRate;

    public BankAccount(long accountNumber, 
                       String owner,
                       String branch,
                       double balance,
                       double interestRate) 
       {
        this.accountNumber = accountNumber;
        this.owner = owner;
        this.branch = branch;
        this.balance = balance;
        this.interestRate = interestRate;
   }
    //Getters and setters omitted for brevity.
}

We run into two problems in the about code:

• Too many constructor arguments
• Incorrect object state

The Pattern

The builder pattern “allows us to write readable, understandable code to set up complex objects. It is often implemented with a fluent interface, which you may have seen in tools like Apache Camel or Hamcrest.” The builder will

public class BankAccount {
    public static class Builder {
        private long accountNumber; 
        private String owner;
        private String branch;
        private double balance;
        private double interestRate;

        public Builder(long accountNumber) {
            this.accountNumber = accountNumber;
        }

        public Builder withOwner(String owner){
            this.owner = owner;
            return this; 
        }

        public Builder atBranch(String branch){
            this.branch = branch;
            return this;
        }

        public Builder openingBalance(double balance){
            this.balance = balance;
            return this;
        }

        public Builder atRate(double interestRate){
            this.interestRate = interestRate;
            return this;
        }

        public BankAccount build(){
            BankAccount account = new BankAccount(); 
            account.accountNumber = this.accountNumber;
            account.owner = this.owner;
            account.branch = this.branch;
            account.balance = this.balance;
            account.interestRate = this.interestRate;
            return account;
        }
    }
    //Fields omitted for brevity.
    private BankAccount() {
        //Constructor is now private.
    }
    //Getters and setters omitted for brevity.
}

We can create new account with the following code:

BankAccount account = new BankAccount.Builder(1234L)
            .withOwner("Marge")
            .atBranch("Springfield")
            .openingBalance(100)
            .atRate(2.5)
            .build();
BankAccount anotherAccount = new BankAccount.Builder(4567L)
            .withOwner("Homer")
            .atBranch("Springfield")
            .openingBalance(100)
            .atRate(2.5)
            .build();

This makes code clearer and more verbose. Using the Builder pattern is a good solution if you find yourself having to add more and more parameters to the constructor resulting in error-prone and hard to read code. I chose this resource because I wanted to learn more about design patterns, and I did not know much about this pattern. I learned how the Builder pattern can help simplify code that may get too complex and hard to read. The content of the post is good quality and the example used was simple and easy to understand, making learning how the Builder pattern works easier. I plan to use this information when in my professional career whenever the Builder pattern would be the best solution.

The post Design Patterns: The Builder Pattern appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Soft Qual, Assur & Test

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

In the second lesson of Shay Howe’s HTML and CSS tutorial, he begins going in more depth about HTML by showing which HTML elements are best used to display different types of content, how they’re visually displayed on a web page, as well as what different elements mean semantically.

Throughout the tutorial, Howe describes several different HTML elements and explains what their purpose is. He also displays a live demo of his examples which is very useful in understanding exactly what each element looks like visually. The list of elements that he describes and their purposes are as follows:

• <div>: division – a block-level element that is commonly used to identify large groupings of content; helps to build a web page’s layout and design.
• <span> – an inline-level element commonly used to identify smaller groupings of text within a block-level element.
• <h1-h6>: heading – block-level elements with six different levels. These help to quickly break up content and establish hierarchy.
• <p>: paragraph – blocks of text visually separated from adjacent blocks (i.e. vertical blank space, first-line indentation, etc.)
• <b>: bold – stylistically offsets text.
• <strong> – places a strong importance on text by bolding it.
• <i>: italicize – conveys text in an alternative voice or tone by slanting it.
• <em>: emphasis – places a stressed emphasis on text.

HTML5 introduced new structurally based elements in order to give meaning to the organization of our pages and improve structural semantics:

• <header> – used to identify the top of a page, article, section, etc.
• <nav>: navigation – identifies a section of major navigational links on a page.
• <article> – used to identify a section of independent, self-contained content that may be independently distributed or reused.
• <section> – used to identify a thematic grouping of content, usually includes a heading.
• <aside> – holds content that is related to the main content around it, but not central to the flow of it.
• <footer> – identifies the closing or end of a page, article, section, etc.

Howe emphasizes the importance of understanding the semantic difference of elements. For example, even though the elements <strong> and <b> both create the same bold text effect, they’re semantically different. The <strong> element is used to give strong importance to text while the <b> element simply stylistically offsets text.

The reason I’m writing about this topic because it’s very relevant to our final project. Prior to reading this I hadn’t even considered the semantics of elements. Also it’s useful to understand how to use each element. In the future I’ll be able to use what I learned to better organize pages and improve its structural semantics. I’ll also be able to apply this to my final project, so this lesson has been very useful to me.

Source: https://learn.shayhowe.com/html-css/getting-to-know-html/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.