Good day, my dear reader! As I continue my education in Software Quality Assurance, I continue to read blogs and keep finding myself reading a blog about how to do one particular topic, or how to test in one specific method. Now those reads were all good and useful but one particular article caught my attention, “5 Reasons you are wasting your testing time“. Now I will admit, I did succumb to the very obviously clickbait title but, this was one title I am glad that I followed. In class, there is a lot to learn but some things are best learned on the job or get glanced over or forgotten in the classroom. This particular blog was about 5 ways to review your testing time and see where you are wasting yours.

The first way is not setting a clear goal. Establish a goal for the testing session and ensure that by the end of your testing session, the goal has been met. The second way is that you might not understand the value of the tested feature to the end user. This is saying that, while we are tasked to test a feature we should keep in mind if this feature actually is useful or helpful to the end user. The third way is that one doesn’t keep track of what was tested and your finding. This boils down to that you need to be able to adapt your tests as you are testing. Fourth is not consulting existing information to get testing insights. The last reason is refusing to do post-test reviews or feedback sessions.

The first thing that popped out to me is the consideration for the end user. This is definitely something that is not talked about in class. It’s something I keep running across and I hope I can keep it in mind as I head out into the job market. The end goal is to create a usable, program that an end user will actually use or purchase. The next thing that jumped out at me is that some testers, “…who say they consciously prefer not to see the previous test-runs or the bugs found in an area of the system in order to avoid any bias towards those areas during their current testing session.” I found this kind of silly that some people see testing a program like a clinical double-blind study. When I hear testing, I think of video game testers effectively ramming their heads against a particular part of a game until it breaks or they do. While I doubt I will ever have this mindset, it’s always good to know what to avoid. The last thing that caught me was that testing, “While at the same time it is an art, as you need to (almost instinctively) know how to adapt and change your testing based on actual stuff you find along the way.” This caught me off guard admittedly. Testing does seem dynamic to me but not in that sense of having to change the nature of a test mid-session. This is something that I will have to remember and try to put into practice out in the field.

Thus ends another blog and another week of discovery and learning. I can only wonder what I will learn next week and I am definitely excited to find out. Until then, have a good night folks!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Source: https://blog.lelonek.me/how-should-we-do-code-reviews-ced54cede375

This week’s reading is a blog about conducting code reviews properly by Kamil Lelonek. It gives a general overview of code review as a process of giving feedback about another person’s code. By utilizing this process of rejecting and approving certain changes to the codebase, it will generate improvements as a whole. However, it goes much further beyond code review as it is not as simple as it seems. Even though benefits such as catching bugs early and ensuring that the code is legible and maintainable moving forward. The post makes it important to realize that developers are very protective about the code that they write and will attempt to defend against criticism. So, it provides different approaches to mitigating problems that could rise while undergoing code review. The benefits of these approaches should be able to correctly reach out without appearing as a threat. Some of these techniques would be to distinguish opinions from facts, avoiding sarcasm, and being honest with yourself. Also, by understanding the ten tips provided, it should make code reviews more effective for everyone involved.

What I found interesting about the article is how straight forward it is towards addressing one’s ego. They are right when they say that developers would like to say that they have wrote good code but sometimes they need to leave the ego behind them. By not opening themselves to criticism and addressing it as threats is detrimental to the team as a whole. Also, when actively code reviewing, I can see that providing evidence for nitpicking at certain lines of code should make it easier for the reviewee to understand what you are addressing specifically. However, I believe that avoiding jokes and sarcasm should be remembered as top priority. Especially when you are reviewing code for a friend. Recalling from personal experience, I do believe I did not help my peer to the best of my abilities by using sarcasm during code review. This also applies to distinguishing opinions from facts where sometimes through practice, you are led to believe that one technique is better than another. In conclusion, these tips are great for improving code review sessions.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the term “simplicity” when we refer it to a software product. There have been an old ‘80/20’ rule meaning that 80% of the people use 20% of the features. So, you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In a period in the past, dozens of companies tried to release ‘lite’ word processors that only implement 20% of the features. Most of the time, they gave their program to a journalist to review, and the journalist reviewed it by writing their review using the new word processor, and then the journalist tried to find the ‘word count’ feature which they needed because most journalists have precise word count requirements, and it was not there, because nobody in the target 80% would use this feature. The journalist ended up writing a story that attempted to claim simultaneously that lite programs were good, bloat was bad, and he could not use this program because it would not count his words.

Making simple with 20% feature products is an excellent bootstrapping strategy because you can create them with limited resources and build an audience. So, you sell “simple” as a wonderful thing and coincidentally, it’s the only thing you have the resources to produce. Bootstrapping strategy has advantages in certain situations, however, it would not be good for long term strategy because there’s very few obstacles to prevent the next two-person startup from cloning your simple app, and because eventually you can’t fight human nature of wanting the features.

Success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control. All of these features share a common character of having benefits that customers like and pay for, but none of them can really be described as “simplicity.” With many years of experience running his own software company, Joe Spolsky saw that nothing he have ever done at Fog Creek has increased the revenue more than releasing a new version with more features. When a new version came out with new features, there was a sudden, undeniable, substantial, and permanent increase in revenue.

It is fine to use the term “simplicity” to refer to a product as meaning that the user model corresponds closely to the program model, so the product is easy to use. More, it is fine to use the term “simplicity” to refer to a product with a spare, clean visual appearance. However, if you think simplicity means “not very many features” or “does one thing and does it well,” you can’t go far with a product that deliberately leaves features out.

Article: https://www.joelonsoftware.com/2006/12/09/simplicity/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

We learned few techniques of testing in class such as Boundary Value Testing, Decision Table-Based Testing, Path Testing … however there are other techniques. In this article,  “Test Design Techniques overview” there are other techniques like Classification Tree Method, State Transition Testing, Cause-Effect Graphing, Scenario Testing. Different techniques are useful in different scenario.

Classification Tree Method. When to use it: we are testing hierarchically structured data or data in a form of a hierarchical tree. Identification of test relevant aspects and their corresponding values, then combination of different classes into test cases. Draw hierarchical classes as graph as shown below, then make projections of tests on a horizontal line using one of the combination of strategies.

           State Transition Testing. When to use it: a tester is testing the application for a finite set of input values, also test sequence of events that occur in the application under test. This will allow the tester to test the application behavior for a sequence of input values.

            Cause-Effect Graphing. When to use it: To Identify the possible root causes, the reasons for a specific effect, problem, or outcome. To set up, identify conditions and effects, draw the graph with all logical dependencies and constraints. Convert the graph into the decision table, tracing each combination of causes that lead to an effect from the effect. This technique helps us to determine the root causes of a problem or quality using a structured approach.

           Scenario Testing. When to use it: to help understand a complex system to test better where in the scenarios are to be credible which are easy to evaluate. Tester put yourself in the end user’s shoes and figure out the real-world scenarios and use cases. Before using scenarios for creating test cases, they are layout described using a template. Then create specific test cases using equivalence partitioning and boundary values techniques.

I like this article because the simple structure, and information with example. In the “Specification-Based Testing Techniques” section, different techniques divide into different group, and which scenario fit better to techniques. I think it’s would be better if there are example with the source code. We can look that the Test Techniques with real life scenarios, to have better understanding.

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

For this week’s blog post I will be looking at another design pattern, this time called Façade. This time once again from the handy site of SourceMaking.com. The overall intent of the design pattern is to provide a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, wrapping a complicated subsystem with a simpler interface. The problem that faces it is a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. Essentially façade discusses encapsulating a complex subsystem within a single interface object, thus reducing the learning curve necessary to successfully leverage the subsystem. The only access point for the subsystem will limit the features and flexibility that power users may need. The façade object should be a fairly simple facilitator. “Façade takes a “riddle wrapped in an enigma shrouded in mystery” and injects a wrapper that tames the amorphous and inscrutable mass of software.” With the quote from the site above the name really comes into play here. A good example of this would be something like that of a catalog. Where the consumer calls one number from the catalog and speaks with costumer service. The customer service representative acts as a façade, providing an interface to the order fulfillment department, the billing department and then the shipping department. Façade defines a new interface where in the Adapter design pattern it uses an old interface. The site/article then goes on to explain some general rules of thumb that can prove useful to those wanting to learn more or follow the design pattern even more. All and all the site is an excellent resource for anyone looking to learn more about design patterns and more with this article proving that with valuable information on a new design pattern I have not seen or used before.

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

Acceptance Testing

For this week’s blog post I will be discussing another form of testing called Acceptance testing. Acceptance testing is a form of testing where a system is tested for overall acceptability. The reason for this is to see if the systems compliance with certain business requirements and assess whether it is acceptable for delivery. The site shows a helpful diagram illustrating when you uses this testing, with Unit Testing on the bottom, Followed by Integration testing above that, System testing above that and with Acceptance on that the top of that one. The site also gives a good analogy of what it is exactly happening with the illustration. During the process of a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are all produced separately, and unit tested separately. After this they are assembled and begin integration testing, with System testing following this. With of course Acceptance testing last to confirm once more that the pen is ready to function properly. Black Box Testing is the most common method used in performing Acceptance Testing. The testing does not follow any strict procedure and is not scripted but is rather ad-hoc testing. Ad-hoc testing is random testing or Monkey testing, essentially throwing stuff at a wall trying to see what sticks and what does not. You perform this testing after system testing like mentioned above in order for the system to be made available for actual use. Internal Acceptance Testing is performed by members of the organization that developed the software but who are no directly involved in the project, usually this is members of the Product Management, Sales or Customer Support. The opposite end of this is known as External Acceptance Testing where it is performed by those who are not employees of the organization that developed the said software. This is then broken up into two different fields, Customer Acceptance Testing and User Acceptance Testing. Customer Acceptance Testing is a pretty self-explanatory name where it is performed by those who purchased the software or are customers of the company that developed it. User Acceptance Testing is performed by the end users of the software, customers’

Customers essentially.

All and all this website was pretty well organized and explained everything very clearly and so forth in a manner where it made extremely simple to read and understand.

http://softwaretestingfundamentals.com/acceptance-testing/

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

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Hello reader!

Today’s blog,  will discuss the differences between Unit, Intergration, and System testing. I will briefly explain the benefits for each test, as well as pointing out their distinct features. I will also be sharing my analysis of Software Testing Fundamental’s-“Software Testing Levels” article from which I read. Let’s begin!

Software testing levels are various phases of the development sequence in which the testing is conducted. The main goal of system testing is to assess the system’s agreement with the specified needs. There are different testing levels that help check behavior and performance. These testing levels are designed to see missing areas and accordance between the development lifecycle states. There are three levels of software testing that I am going to talk about: Unit, Integration, System, and Sytem Testing.

Unit testing is a level of the testing process that tests individual units of a software. The goal is to show that each unit of the software works as designed. Intergration testing is a testing process that combines and tests individual units as a group. The goal of this level is to show faults in the interaction with integrated units. System testing is a testing process in which a program is tested for acceptability. The goal is to evaluate the program’s agreement with the business requirements and to see whether it is acceptable for delivery.

These three testing types cannot just be applied randomly during the forming process. There is a sequence that should be considered to in order to lessen the risk of failures. By increasingly testing the more simple things in the system and moving on to the more complex things, the testers should know that they are carefully examining the software in the most efficient ways possible.

Testing early and often is definitely worth the effort. Having a efficient approach to testing allows the tester to find any faults in the system sooner, which leads to less time and less money wasted later on.

Software Testing Fundamental’s-“Software Testing Levels” was written very well and it was very easy to understand. It taught me a great amount of these three types of testing. I hope I was able to extend what I learned in a informative way.

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