For this post I chose the article “What is Non Functional Testing?” on Software Testing Help’s website. I chose this article because I like the content on this site that I have read previously and I often forget the difference between functional and non-functional testing. I’m hoping by covering it in a blog it will help commit it to memory and also give me my own quick reference if I need it in the future.

To start it’s important to remember the two broadest types of testing are functional and non-functional. Non-functional testing in a general sense addresses things like application performance under normal circumstances, the security of an application, disaster recovery of an application, and a lot more. These types of testing are just as important as meeting requirement of any application. They are what contribute to the quality of an application.

To follow are the most popular non-functional techniques as a quick reference and a quick explanation:

1. Performance Testing: Overall performance of a system. (meets expected response time)
2. Load Testing: System performance under normal and expected conditions. (test concurrent users)
3. Stress testing: System performance when it’s low on resources. (low memory or disk space, max out)
4. Volume Testing: Behavior with large amounts of data. (Max database out and query, check limit of data failure)
5. Usability Testing: Evaluate system for human use. (ease of use, correct/expected outputs)
6. User Interface Testing: Evaluate GUI. (Consistent for its look, easy to use, page traversals)
7. Compatibility Testing: Checks if application can be used with other configurations. (different browsers)
8. Recovery Testing: Evaluates for proper termination and data recovery after failure. (loss of power, invalid pointer)
9. Instability Testing: Evaluates install/uninstall success. (correct system components, updating existing installation)
10. Documentation Testing: Evaluates docs and user manuals. (document availability, accuracy)

In conclusion this covers a good portion of the main types of non-functional testing. This will really just serve as a quick reference or lookup to remind me of the different types of testing that categorize as non-functional. This isn’t changing the way I code but it has reminded me the importance of non-functional testing. Just meeting the requirements during the development of an application does not ensure you will output something with high quality. I would argue that non-functional testing responsibility falls more on the developers to know what to do more than the client. A client requesting requirements for an application likely will not even think of a lot of the testing types mentioned above. I think it’s important for the developers to openly communicate with clients about non-functional testing so that they can come up with the best testing plan together.

Overall this was another good article on Software Testing Help. It was exactly the details I needed and nothing more. Looking ahead I might as well do a similar blog on functional testing to complete my own testing type’s reference.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

For this post I chose the article “Singleton Design Pattern” written by the team at Source Making. I chose this article for two reasons: 1) Source Making is a good resource that covers topics such as design patterns, antipatterns, UML, and refactoring. 2) While we covered the Singleton design pattern in class, I felt like I needed to take a look at it again from another source.

To start, the article touches on what the intent of the Singleton pattern is. First, it ensures that there is only once instance of a class with a global point of access. Second, it uses encapsulation in the sense of initializing on first use.

To use the Singleton pattern you need to make the single instance objects class be able to create, initialize, and enforce. The instance itself must be a private and static type. Next you need a function that encapsulates the initialization and provides access to the instance. This function also needs to be declared public static. When a user needs to reference the single instance they will call the accessor function (getter).

Additionally there are three criteria which must be met:

1. Ownership of the single instance can’t be reasonably assigned.
2. Lazy initialization is desirable. (delayed creation)
3. Global access is not otherwise provided for.

The author makes some additional remarks about the Singleton pattern. He mentions that this pattern is one of the most widely misused patterns among developers. One of the most common mistakes is attempting to replace global variables with Singletons. One advantage he mentions is that you can be absolutely sure that you have only one instance however he also points out that most of the time it is unnecessary. He also advises to always find the right balance of exposure and protection for an object to allow for flexibility. Using a Singleton however can lead to not thinking carefully about an objects visibility.

After reading the article I definitely have a better understanding of how the Singleton pattern works and why I would use it. After reviewing the Duck Simulator slides from class and seeing some additional information in this article, I have a good grasp on the concept now. I think the most interesting concept of the Singleton pattern is the concept of lazy initialization. I like the idea of no instance being created until it is actually needed. After reading this article I would give it a “C” for content. Had I not been exposed to the Singleton pattern in class, this article would not have been much use to me. But because I already had a basic idea of the pattern, the article just helped reinforce the concepts and provide some more examples.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Since for the second part of our “Software Quality Assur & Test” class, we are now beginning to test object-oriented software, I thought it would be useful for me to expand my knowledge of horizon on Junit. The article I read this week is about unit testing with JUnit 4 and JUnit5. It explains the creation of JUnit tests. It also covers the usage of the Eclipse IDE for developing software tests. In this blog I will be centered around JUnit 4 and the JUnit topics that I found useful for both my current software testing course and my professional career as well.

Define a test: To define that a certain method is a test method, annotate it with the @Test annotation. This method executes the code under test. Use an assert method, provided by JUnit to check an expected result versus the actual result.

Naming conventions: As a general rule, a test name should explain what the test does. If that is done correctly, reading the actual implementation can be avoided.

I will be naming my test methods as logically as I can, so that not only I know what exactly the test does, but also be easier for my team member to not to dig into the actual code, thereby saving the time, while working on group. Moreover, I will also avoid using testcase naming convention which uses class names and method names for testcases name.

Test execution order: JUnit assumes that all test methods can be executed in an arbitrary order. Well-written test code should not assume any order, i.e., tests should not depend on other tests.

Most of the times while writing my test cases, I used to think about the bigger picture. I used to scan through the entire project’s code, making sure that I know the relations and dependencies among the classes. This way, often, I ended up writing test cases that must be executed in a particular order. But now I will remember that tests should be independent, and test only one code unit at a time. I will try to make each test independent to all the others.

Defining test methods: JUnit uses annotations to mark methods as test methods and to configure them such as:

@Test, @Before, @After, @BeforeClass, @AfterClass, @Ignore , @Test (expected = Exception.class), @Test(timeout=100).

Assert statements: JUnit provides static methods to test for certain conditions via the Assertclass. These assert statements typically start with assert. They allow us to specify the error message, the expected and the actual result. An assertion method compares the actual value returned by a test to the expected value. It throws an AssertionException if the comparison fails. Most common methods include:

fail([message]), assertTrue([message,] boolean condition), assertFalse([message,] boolean condition), assertEquals([message,] expected, actual), assertNotEquals([message], expected, actual), assertNull([message], object-reference).

Form now onwards, while writing my asserts I will provide meaningful message in assert statements that will makes it easier later on to identify what exactly happened and fix the problem, if any error occurred.

For my next week I am looking forward in learning more about testing for exceptions and the use of assertThat statement.

Source: (http://www.vogella.com/tutorials/JUnit/article.html)

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

http://reqtest.com/testing-blog/white-box-testing-example/
This week we generalize to whitebox testing. Whitebox testing or code based testing as the name implies works at the code based level. This technique does not rely on the specifications but instead provides the programmer with the actual code. Armed with such technical details, programmers can create test cases to test for the success of the system. The key principles to successful testing are the following:

Statement coverage – the simplest type of coverage ensures that every statement is executed.
Branch coverage which ensures that every branch is covered.
Finally, path coverage which ensures that all paths are tested.

Statement and branch coverage does not guarantee full edge coverage. So, above all path coverage is favoured for its comprehensiveness.
For code testing, I have always asked if white-box testing is enough to create a successful, working product when the tester already has the code. What are the advantages of black box testing when whitebox testing should be sufficient?
This article is all about whitebox testing. It poses the question of which is better white box or black box testing, but does to formulate any favoritism for either. Both has advantages/disadvantages depending on the scenario, so neither can be ruled out over the other. As stated in the article, black box testing allows the system to be tested from a user’s point of view. White box testing on the other hand allows the system to be tested from a developer’s point of view.
Black box testing allows the tester to have more perspective on the intended customer/users and tests for the expected results. For new insights, the author seems to favor it during the early stages of product development and the first few sprints in the release. It allows for further progress and development after eliminating “show stopper” bugs. However, from what I have seen black box testing is redundant and consumes too much time. One disadvantage is that test cases are extremely difficult to design when the specifications are unclear and not concise. One advantage is that it can test for boundary conditions.
White Box testing on the other hand, allows the tester to see the code. Therefore, it helps to bring out bugs that would otherwise be missed with black box testing. White box testing as stated helps to fix journeys and scenarios that would have otherwise been considered as exceptions, but that can be damaging in real life in terms of reputational, regulatory, and monetary damages. It allows for code optimizations by revealing hidden bugs. The emphasis on it is that it allows engineering teams to conduct thorough testing of the application by allowing for all possible paths to be covered. So, in my opinion whitebox testing should be given higher weights

I chose this article for generalization and out of interest to learn more about whitebox testing. Although the article does not show favoritism, I am in favor of most of the techniques over black box testing.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

Encapsulation

        I chose a podcast this week to try and broaden my learning experience using different resources. This podcast talked about object oriented programming dealing specifically with the idea of encapsulation. It went through the basics of what encapsulation is and how classes, methods, and variables all connect with each other to hide data. The people on the podcast explained the differences that encapsulation can have between different languages but the basic idea is essentially the same. The overall syntax may change slightly but the idea of data and code being hidden from the user is still there. They then explain how the idea of a roadmap works well with this idea and how helpful it could be if other programmers are looking at the code. It allows programmers to understand what they can and should use in your code. They go over access modifies such as public, private, and protected where they explain that giving the user all the code can be harmful as that allows the user to change values that could end up breaking the program. They also use global variables to help show this point by saying they are not reusable and make it more difficult to track down errors.

         I chose this podcast because encapsulation is an essential part of coding in an object-oriented language like java. It allows the programmer to hide code that doesn’t need to be seen by the user to make sure that they can’t alter anything they shouldn’t. I have to admit that out of all the complicated podcasts I searched through, this one especially made it easy to understand java concepts. Coding blocks has a solid source of information and does a great job explaining how everything works using their own definitions for the somewhat confusing vocabulary. Although I already knew most of this information, it was a great idea to refresh on it because I had forgot all the vocab such as mutators and accessor methods which I just called getters and setters. Overall the content was very easy to understand due to the helpful explanations given by the people in the podcast. It affected and helped me by allowing me to refresh on encapsulation and encouraged me to go look at inheritance along with polymorphism again. This obviously will tie back to our class since we’re going to be using a lot of object oriented programming in java and using encapsulation to work on our projects. Encapsulation will have a big impact on my practice of code as it will help shape my design for how the code will look and what the user will have access to if I want them to only have limited control over the program.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

https://blog.joegreen.pl/lesser-known-java-syntaxes.html

Today I stumbled across an interesting little blog post on lesser-known Java syntax. The author gives examples of code that doesn’t look like it would compile, but is surprisingly still legal syntax. For example, a two-dimensional array is usually declared like this:

class MyClass {
    public void method(MyClass this, int argument) {
    }
}

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.