CS 443 has taught me many things: how to test code, the different ways to test code, collaboration among peers, what is possible/not possible in Java, mockito, the list goes on. What it has not taught me is how code is actually tested in the field professionally; what should I expect to do or know if I were to shift towards the QA Engineer path?

‘A Day in the Life of a QA Engineer’ by AJ Larson talks about what he does in a professional setting and I compared it to the daily tasks we performed in class and it seems it is not completely opposite. He starts off by comparing software developers to QA engineers and stating that it is not too different; some companies even combine the two into one where you are a dev and a tester. He talks about how the team communicates; telling each other where they are in the project, what their plan is and if they have been encountering any problems. I guess in a way we have been doing that in class.

Onto the more important part of this blog is where he talks about testing ‘stuff’. He spends his time running manual tests and when he encounters a failed test how he goes about it. I learned that communication is key in both school and professional work environment; pretty much anywhere there is teamwork there must be communication.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Regression Testing

For this week’s blogpost I will be looking at an article from ReQtest that explains what regression testing is and its benefits. Regression testing ensures that previously developed and tested software applications are working the same as they were before recent code changes were done. Tests cases are re-executed to check to see if this occurs. Regression testing is needed when new features are added or when changes in requirements and code are modified per changed requirements. Bug fixing and fixing performance related issues are also instancing of when regression testing is needed.  When a system is changed errors may arise, this is when regression techniques come into play.

• Retest All: this re executes all the tests that exist in the test bucket. This usually requires a large amount of time and resources making a very expensive resource.
• Regression test selection: this executes the selected part of the test suites for example re-usable test cases or obsolete test cases
• Test case prioritization: Prioritization of test cases depends on business impact and used functionalities.

The benefits of regression testing come from its basic idea, when your system is not working prior to changes made. Regression testing increases the possibility of tracking bugs caused by these new changes. It also helps in finding unwanted side effects that might have been caused due to a new operating environment. Of course, this will help identify bugs and errors in the early stage as well. Where this probably shines the most is when constant changes are required in the product. There are different types of regression testing as well. Corrective regression is used when there are no changes introduced in the existing product specifications, usually used to conduct a desired test. Progressive Regression is used when modifications are added in the specifications of the product and new tests cases are created. There are many more types of regression testing that is listed in the article such as Selective, Retest-All and complete regression. Some of the best tools for regression testing are WinRunner, QTP, vTest, Regression Tester and AdventNet QEngine.

All and all I thought this article was very informative, as I learned about a new testing method I have yet to learn or know about. It also seems to be very important especially if your system is working then after a change something goes wrong after said change occurs.

https://reqtest.com/testing-blog/regression-testing-types-techniques-tools/

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

CS443 Blog Post

https://reqtest.com/testing-blog/bug-report-template-good-bug-reports/

For this week’s blog I looked at bug reports and a template to perhaps help create better bug reports. Firstly, a software bug essentially is an error that produces unexpected or incorrect results, therefore when something is not working in the software as it should be it is inferred as a bug in the software. A bug report is a document that is extremely useful in communication to the developers that tell which parts of the software/application are not behaving as expected. These reports should have enough information that helps the developers pinpoint the exact issue helping them resolve it. The quality of the bug reports is crucial as a high-quality report reduces the chances of the bug in the future. While a bad bug report may cause the developer not to replicate the bug and not be able to fix it. Well what does a good bug report consist of? Well a good bug report has the following characteristics

• A good bug report has a unique identifier number to easily identify the bug and set it apart from the rest
• It contains all the information required to reproduce the bug and fix the issue while prioritizing the bug for fixing and outlining the expected behavior
• It usually covers a single bug, for multiple issues multiple reports should be created
• A good bug report can be easily understandable by the tester and the developer, implicating that the bug report should portray the same meaning between those who created the report and those who will be trying to fix the bug
• A good bug report follows a standardized bug report template while promoting collaboration between others and allows the bug to be fixed in the shortest amount of time

Bug reporting software’s such as ReQtest will help you in your bug tracking initiatives. Usually bug reporting software will help you report, document, store, manage, assign, close and archive bug reports. ReQtest is one of these tracking software’s that allows you to create a professional bug report. The template consists of fifteen different fields of information ranging from the ID number used to uniquely identify the bug report to the frequency of the bug occurring to the linked requirements that are linked to the bug report. Looking at the site you can see what each field requires and does exactly. Finally, after the bug report template has been used a checklist is usually required. Is the bug report clear to follow? Was the bug reported previously? Have you tried to reproduce said bug with the help of your own bug report? And so forth.

I thought this article was interesting as it gave me some good insight on how a bug report should be and such. The way it explains the bug report template is straightforward to pretty much any audience along with the entire article which is very nice to newcomers of the topic. Coming into this I had a general idea of what bug reporting consisted of but this article made me understand more of it. Overall I liked this article as it was informative and straight to the point.

From the blog CS@Worcester – Matt's Blog by mattyd99 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 user interface programming for software. Most of the hard-core C++ programmers Joel knows hate user interface programming. This surprised him, because he found UI programming to be quintessentially easy, straightforward, and fun. It’s easy because you usually don’t need algorithms more sophisticated than how to center one rectangle in another. It’s straightforward because when you make a mistake, you immediately see it and can correct it. It’s fun, because the results of your work are immediately visible. You feel like you are sculpting the program directly. Most programmers’ fear of UI programming might come from their fear of doing UI design. They think that UI design is like graphics design, which is the mysterious process by artistic-minding people creates cool looking artistic stuff. Programmers see themselves as analytic, logical thinkers, being strong at reasoning, weak on artistic judgment. Therefore, they think they can’t do UI design. However, UI design is quite rational. It’s not a mysterious matter that requires a degree from an art school. There is a rational way to think about user interfaces with some simple, logical rules that you can apply anywhere to improve the interfaces of the programs you work on.

User interface interacts with users working with software. UI is important because it affects the feelings, emotions, and mood of users. If the UI is wrong and the user feels like they can’t control software, they literally will not be happy and they’ll blame it on software. If the UI is smart and things work the way the user expected them to work, they will be cheerful as they manage to accomplish small goals. So, UI must respond to the user in the way in which the user expected it to respond; other way the user is going to feel helpless and out of control. A psychological theory called Learned Helplessness, developed by Dr. Martin E. P. Seligman, is that a great deal of depression grows out of a feeling of helplessness: the feeling that you cannot control your environment. To make people happy, you have to let them feel like they are in control of their environment. To do this, the user interface needs to correctly interpret user’s actions.

The post gives us a thinking about designing and programming user interfaces for software. UI design should be considered as rational and logical process rather than a mysterious process that needs highly artistic judgment. UI must behave in a way that users feel like they are able to control the environment when they are using software. The cardinal axiom of all user interface design: “A user interface is well-designed when the program behaves exactly how the user thought it would.”

Article: https://www.joelonsoftware.com/2000/04/10/controlling-your-environment-makes-you-happy/

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

We just wrapped up a section going over various design patterns used in software, so I wanted to do a bit more research on a different design pattern to get more of an idea about how they work. One pattern that looked interesting was the composite design pattern (https://howtodoinjava.com/design-patterns/structural/composite-design-pattern/), which appeared to combine a couple of concepts that I had seen from taking data structures: inheritance and trees. This structure of the composite design pattern essentially takes on the form of a hierarchy, with 4 types of items: a component, a leaf, a composite, and a client.

The component is the abstract entity in which common behaviors and operations are defined so that repeated code can be prevented. In the example provided in this post, a program to simulate the retrieval of banking information, the “component” expressed a list of other Component objects, methods to add and remove from such list, as well as other abstract and non-abstract methods that can be utilized by other classes extending from the component.

The composite and the leaf (or leaves) both inherit from the component. For this example, the CompositeAccount class served as the composite. This class implements the methods defined as abstract in the Component class. Because the composite and the leaves all inherit from Component, all of these objects from the different classes can be defined as Component objects. Thus, in the CompositeAccount class methods, all of the leaf objects are taken into account by traversing through the list of Component objects. For this example, the DepositAccount and SavingsAccount were leaves, with their own behaviors that were exclusive to the leaves.

Finally, the client puts it all together as the driver for this design pattern. New objects are created in this class, and each individual object is treated appropriately with the correct behaviors (i.e. the DepositAccount and SavingsAccount), while also being part of the bigger system, in this case the CompositeAccount, all of which are underneath the Component umbrella.

This was a great read for me! It was simple enough to understand coming from an extended introduction to design patterns and other programming courses using this kind of structure. I’m currently reading more about the Decorator design pattern for an assignment, so I hope to post more about that soon!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

As I take another step into Software C.D.A. I remain in design pattern. I will point out the bases of adapter pattern and will also talk about a new pattern I just learn about the Facade pattern, and the Memento pattern. I will also point out the main difference between adapter pattern and facade pattern. I chose to do this topic because I was mainly trying to just focus on the facade pattern but my search in the internet for podcast on this topic lead me to “Design Patterns Part 4 – Adapter, Facade, and Memento by Joe Zack”. Where as the topic indicates its topic is on the design pattern of adapter pattern, facade pattern, and memento pattern. For this blog I will briefly summarize what they discuss on adapter pattern and memento since my main focus is the facade pattern. Since I must do my own research on that pattern for a homework assignment and I might as well hit two birds with one stone. That being said if you wish to listen in the podcast click on the highlighted link above of the podcast tittle.

Alright let’s dive into the facade pattern…

What is Facade Pattern?

Facade pattern is used with object-oriented programming it is an object that aids as an interface masking complex code structural.

What is facade intention?

The facade intention is to make combined interface available to a set of interfaces for example wrapper.

When to use Facade?

We use facade when there is a complex system you wish to make more simpler either by necessary or for your own personal wants in a system.

Okay now that we pointed out the basic of facade lets cover adapter bases and then compare them both.

What is Adapter Pattern?

Also known as wrapper, the Adapter Pattern is a software design patter that allows the interfaces of an existing class to be used as another interface. In software development the adapter pattern has the same concept of those in real life, for example phone adapters.  Meaning adapter patter are similar to phone power adapters in the sense that one adapter can be used with many different USB devices cable. Say you’re at your friend’s house and you have an i-phone USB charger cable but no power adapter, and let’s say your friend owns an android and only has an android charger. He can unplug is USB android cable from his power adapter and hand you his power adapter for you to use with your USB i-phone cable so you’ll be able to charge your phone. An adapter is convenient because it enables incompatible objects or devices to be used for the same purpose. The adapter pattern is also convenient because it allows you to use existing class or interface by introducing a new class that adapts between classes and interface without changing the existing class that is known as an adapter class.

What are the differences between facade and adapter?

Although both of them are consider to be wrappers. The difference is that an adapter only wraps one object while a facade wraps multiple. Adapter solves non-compatible interface problem by making them compatible by using an existing interface. While facade takes complicated interfaces or systems and transform them into simpler interfaces/subsystem by defining a new easier interface a wrapping them up.

What is the Memento Pattern?

The memento pattern has the ability to undo its previous state by restoring the object. Also described as “undo via rollback”. As described in the podcast memento aims to “rolling back changes to an object”.

How is memento pattern implemented and how it works?

The memento pattern has three objects of implementation known as the originator, a caretaker, and a memento. The originator has an internal state, a caretaker is able to undo the change and does something with the originator, but the care taker must first ask the originator for a memento object. The idea of “undo via rollback” is done once the caretaker returns the memento object to the originator. Another way to think about how memento is implemented is by taking a snapshot of the internal state and then you can restore your object to the internal state by passing that data back (this is similar to how describe in the podcast).

The memento pattern is categorized as a behavior design pattern. Both facade and adapter are categorized as structural design pattern but are used for different reasons. I will end this blog by saying Design pattern is a very important skill to have for software developers. That being said do your research on Design Pattern and look for examples and understand how it works in order to be a successful software developer.

Thank you for your time. This has been YessyMer in the World of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

For today’s blog I am going to be referencing another blog called “What is Boundary Value Analysis and Equivalence Partitioning?” by Ulf Eriksson. The article talks about boundary value testing being a way to test values between the valid input ranges in test cases. Boundary testing is important so that we as testers can figure out where our valid input range lies, and we do not mistakenly use inputs outside of the valid range (the invalid range). This is also important to do so that if an end user does enter an invalid input, then the program knows how to handle it rather than crashing and burning. One other area the article talks about is called equivalence partitioning. This one is a little different from boundary value testing in that it divides the test into a range of values and selects one input from each range. This is a form of black box testing because you are testing the value without knowing what is going on inside and in turn, not knowing the exact output. There is, however, an expected output that you determine before testing and it will be proved either true or false based off the actual output of the test. The best way to differentiate between boundary value and equivalence partitioning is summed up very nicely in the article. The basic idea of the point being made in the article is that boundary value testing is testing for the valid range of inputs whereas equivalence partitioning is slicing that valid input area (as determined in the boundary value tests) into equal parts and selecting one value from each partition to test. I think this is is a very constructive way to test within a valid value range because you are getting a “good spread” of test values. In other words, the test values you are getting will be from across the spectrum of valid test values because of the equal partitions and selecting a value from each partition. I have been using this idea of equivalence partitioning in class by selecting test values such as min, min+, nom, max-, and max. We have learned in my software class that testing from each of these values will give you a good showing of how accurate your tests are and how good your tests are. Thinking about these five test values as equivalent partitions within the valid boundary range will help me find these values easier in the future.

Link: https://reqtest.com/testing-blog/what-is-boundary-value-analysis-and-equivalence-partitioning/

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.