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.

This post is about a new development in software testing, a possible evolution that makes so much sense logically to me I can’t believe I didn’t draw the conclusion earlier in my posts about Test Ops.

Google has recently (ok, more like earlier in the year) renamed their Testing Automation Conference into the Engineering Productivity conference. They also did the same with their team.

And this instantly went back to all the Test Ops posts I’ve been reading.

All of them showed the natural progression of simple testing into something wholly devoted to increasing productivity itself of an engineering project. Continuous Improvement, Testing and Development. Testing not only if a product works but if it is working effectively or not. Testing and Quality Assurance are simply the beginning of using software to ensure increased productivity of software engineering projects.

The essence of it is to let the developers themselves handle the tasks of making sure the code works and is of good quality. This means that they will be making tests for their own code. Obviously, just doing this would not be very effective, as developers might not be great at testing. This is why a new task for the Engineering Productivity team is provide guidance and tools to developers to help them more effectively produce effective tests with good code coverage and that will make sure the performance is reasonable. By doing this, the responsibilities of the team are lowered and they can take on more responsibilities in terms of aiding with Continuous Development, and using big data techniques to test the how effective features are at keeping users (for projects where this is applicable) so developers know where to steer productivity.

Of course, there needs to be flexibility. Focusing on testing in the beginning seems to be very effective, leading to there being much less issues down the road. So the team focuses their time on things like pending time on IDE plugins, code coverage, and effective code review. After release, the team can shift over to Testing in Production tasks, especially when features or updates start development. A responsibility the team always has is making sure there are no testing bottlenecks. If a test takes too long, people will stop running them altogether at some point.

This is really a formalization of all the other topics I’ve posted on. Seeing the evolution of a dedicated testing team, the blending between developer and tester, and finally leading to the testing team becoming a team focused not only on testing but increasing production in general is quite fascinating. In a way, the testing team was always about increasing productivity, and formalizing it has made that apparent.

Original Post: http://www.awesome-testing.com/2017/07/testops-5-engineering-productivity.html#more

From the blog CS@Worcester – Fu&#039;s Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Another programming term I learned about this week is “Bloaters” which are code, methods, and classes that have increased to such big proportions that they are difficult to work with. This is part of a section of code that “smells”, which doesn’t literally smell, but it means that this type of code stinks. When it comes to bloaters, these “smells” do not come up right away, but they accumulate over time as the program evolves.

https://sourcemaking.com/refactoring/smells/bloaters

The blog “Source Making” goes in-depth with Bloaters and I like this blog because it breaks down the types of Bloaters and explains what they are, what causes them, and how to fix them in a way that’s easy to understand. The blog lists a few types of Bloaters.

• Long Method
• Large Class
• Primitive Obsession
• Long Parameter List
• Data Clumps

Long Methods are methods with too many lines of code. The rule of thumb given by this blog is that if a method has more than ten lines of code, it should be reconsidered. A solution given by the blog is that if you feel the need to comment on something inside a method, you should take the code out and put it into a new method instead.

Large Class is a class that contains too many fields/methods/lines of code. Classes usually start small but get bloated as the program grows. If a class is wearing too many “hats”, then you should think about splitting them up.

Primitive Obsession is the use of primitives instead of small objects for simple tasks, the use of constants for coding information, and the use of string constants as field names for use in data arrays. Like many other smells, primitive obsessions are born in moments of weakness but become a problem later on. The blog suggests that if you have a large variety of primitive fields, it could be possible to logically group some of them into their own class, or move the behavior associated with the data into the class too.

Long Parameter Lists are more than three or four parameters for a method. To fix this, check what values are passed to parameters, if some of the arguments are just results of method calls of another object, you should replace the parameters with a method call.

Data Clumps are different parts of the code that contain identical groups of variables and should be turned into their own classes. This can be caused by copying and pasting a lot of code, and if you see repeating data, the blog suggests using the Extract Class to move data fields to their own class.

This blog gave me a great understanding of types of code smells, like the Bloater, with multiple examples of bloaters that many of us may encounter or even create while coding. This is a good way to see if you’re practicing bad coding habits and how to fix them to make your code more concise and to make your programs run better.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.