The Automatic Test Pyramid

Ham Vocke in his blog about The Practical Test Pyramid says “Traditionally software testing was overly manual work done by deploying your application to a test environment and then performing some black-box style testing e.g. by clicking through your user interface to see if anything’s broken. Often these tests would be specified by test scripts to ensure the testers would do consistent checking.

pry

 

It’s obvious that testing all changes manually is time-consuming, repetitive and tedious. Repetitive is boring, boring leads to mistakes and makes you look for a different job by the end of the week.”

 

 

From this thought you ask yourself how you can make something boring not boring. Well as a great computer scientist you decide to “pawn” that work off on the computer. This automation was thought up by Mike Cohn in his book Succeeding with Agile

Mike Cohn’s original test pyramid consists of three layers that your test suite should consist of (bottom to top):

  1. Unit Tests
  2. Service Tests
  3. User Interface Tests

Although this pyramid can be overly simplistic it still serves as a good rule of thumb to follow when establishing your own tests. The names of the layers may not stand out to everyone specifically Service Test, but given the shortcomings of the original names it’s totally okay to come up with other names for your test layers, as long as you keep it consistent within your codebase and your team’s discussions.

Ham Vocke offers an extremely detailed and long blog entry that goes into much more detail. I plan to introduce more ideas from this blog as a continuation, but the main idea to grasp from this first post is the idea of automated testing, and introduce the metaphor of the pyramid. If you want to read ahead of my post check out his entry at the link below.

-Computing Finn

Andrew Finneran

 

 

https://martinfowler.com/articles/practical-test-pyramid.html

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

ReportPortal.io

For my blog for this week, I listened to a podcast with Joe Colantonio. His guest for that particular episode was Dzmity Humianiuk who is a product manager for an application called ReportPortal.io. ReportPortal.io is an Artificial Intelligence powered test automation on dashboarding. It is open source and works with almost every test automation tool out there. Dzmity worked 11 years in IT and switched to software development. He had thought of his idea five years ago when he was trying to find a way to collect a large amount of data. This was the first idea that started with implementing something that is robust and would be the standard for all test automation results within his company. ReportPortal.io is really cool because it is like magic, where you are able to get everything with one click. The key benefit being the real time reporting. For example, if you need to execute a lot of cases when you have a pretty big scope of test automation, there is no need to wait for the full execution of all test cases. There is not waiting up to ten hours, and instead you will see results within the portal in just a few seconds after the execution has just started. Usually, any problem or test cases that start to fail, you will be able to the next day. With ReportPortal you are able to notice it within a few seconds, make it click, fix it and execute it again. ReportPortal uses machine learning and implements some of its algorithms that utilize all the historical data that is given in the database. Then it analyzes the most recent execution. Dzmity also talks about how making the tool customizable was crucial and from the beginning they were assuming it would be open sourced. It i built on microservices architecture which means that it is perfect extension point for the report portal. This allows user to be able to implement their own tiny micro service which can use their API which in hand can use any other microservices that are inside. It also allows everyone to see the code and contribute to it. Lastly he talked about how they are even able to integrate it with Silk testing which is very old school testing and make it compatible with the modern software. Again, a very interesting podcast! I have never heard of ReportPortal.io an it was really cool what the product manager had to say about it!

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

Regression Testing

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.

Bug Reports

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.

INTEGRATION TESTING

This blog post is about second of level of software testing. Integration testing is when individual units are merged and tested as a group. The purpose of integration testing is discovering errors in the interaction between integrated cases. A good example of integration testing is a basketball hoop, the rim, the pole, and the net. They are created and tested separately in the same facility but when two unit or more are ready they are tested together which is integration testing. Black box testing, white box testing and gray box testing can all apply to this method. There are many approaches to integration testing:

 

  1. Big Bang – when every or most of the units are merged together and tested at the same time.
  2. Top Down – when lower level units are tested after top level units.
  3. Bottom up – when top level units are tested after lower level.
  4. Sandwich/Hybrid – combination of both top down and bottom down testing method.

 

Integration testing is important level of software testing because for example if you have a two separately created and tested units like a door and door knob, even though both door and door knob were tested you don’t know if they would fit because they weren’t tested together. There could be many faults for example like the door was inch in width smaller or the door knob was didn’t fit with the door. With integration testing the door and door knob would be tested together after each of the unit is ready so if there any error that makes the door and the door knob to be non-compatible then the test cases will fail which shows that there’s an error and you can fix it.

 

After reading this article I have a better understanding of integration testing. This article changes the way I think about software testing because I more knowledge about one of the levels of software testing. I now know why integration testing is so important. I find this method useful in many ways in testing in general outside of software testing. All in all, integration testing is important level of software testing.

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

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

Controlling Your Environment Makes You Happy

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.

Dynamic and Static Testing

This week’s post is going to be about Dynamic and Static testing from testbytes. Static and Dynamic testing are the two major methods of software testing.

Static Testing is done manually or with a set of tools. This type of testing is useful in finding flaws. It is mainly done in the early stages of the development cycle, also referred to as verification testing. Specifications, design documents, source code, test plans, test scripts, test cases, and web content, all have to pass the static testing. Some advantages of Static Testing are: identifying flaws in the code since it is done in the early stage of development, the testing is conducted by trained software developers, and it is a fast and easy way to find and fix errors. Some disadvantage to using it are:  it demands a great amount of time when you’re doing it manually, not all automated tool works with the language, and that automated tools only scans the code.

Dynamic Testing is done when the code is executed and checks how the software performs in a run-time environment. This testing checks the functional behavior and performance of the system. The purpose of this testing is to ensure that the finished product is designed according to the specification given by the clients. It is also known as validation or execution testing. Some advantages to Dynamic Testing is that it identifies weak areas in a run-time environment and it can be applied to any application. Some disadvantages are: it is not easy to find a trained professional for dynamic testing, and it is difficult to trace vulnerability in the code and would take longer to fix the problem.

 

At first, I thought that Static and Dynamic testing are different kinds of testing but it’s actually more like a primary and secondary test. I really like this blog because it lists the advantages and disadvantages, for me it makes it easier to understand if the layout is like that. Also, they mentioned that eighty-five percent of flaws of the software can be detected during Static Testing, I think that is really interesting. You would’ve thought that most of the flaws in the software would be found in the Dynamic Testing where they test the end product.

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

Composite Design Pattern: What It Is and How To Use It

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.

Post #5: The Difference between Integration and Unit Testing

Hello and welcome back to Benderson’s blog where we talked about computer science related topics. This week I’m pulling a blog posted by STC Admin at Software Testing Class where it discusses the difference between Integration and Unit Testing. The author begins with an analogy where he talks about a Personal Computer with all it’s separate parts and how they all work together but in order for them to see if they will work together, you must do a compatibility test after the integration test. Then it goes into a system test and lastly an acceptance test. This leads into his next paragraph where he discusses how a software application is developed where it goes through the same type of tests that a Personal Computer would go through. The author even has a neat little diagram in the blog showing you a flow chart of how the testing goes. Then the author goes into each of the individual testing that he talked about before: Unit testing, Integration testing, System testing and Acceptance testing. Giving a brief explanation on what each of them do. The next paragraph talks about the advantages of system testing and lastly the differences between Unit Testing and Integration testing to wrap up the blog.

I chose this blog to discuss this week because it has a lot of information jam packed in there about two types of testing that I had little knowledge about. After reading the blog, I like to think I gained a decent amount of knowledge on the topic. Like for example, now I know the order of the system testing approach which begins with unit testing and ends with acceptance testing. I even learned the importance of each of the parts of testing like with unit testing I learned it is also known as white box testing that is carried out by the developer or with System testing it is known as black box testing which tests the overall functionality of the system. I also learned some reasons why it is advantageous to some system testing such mitigating after production go live issues and defects. Lastly, I learned the difference between the Integration and Unit testing such as one is white box and the other is black box, one surfaces from interface specifications and the other is from module specifications and lastly one is conducted by testers and the other is conducted by developers. This blog was very interesting and was a great read.

Link: https://wordpress.com/read/feeds/39452620/posts/2017866494

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

The D-Sign of C-Sci

CS SERIES (6)In my software design course, I recently learned about how using design patterns helps you code better. I thought it would be a good review to go over the concepts this article introduces and potentially link it to things from class and maybe even add some things we did not get through during class.

The three categories Frederico Haag, a computer science engineering student at PoliMi, wrote about are creational patterns, structural patterns, and behavioral patterns.

Based on the design pattern I chose to work on for my individual assignment, I wanted to focus on the facade section–which is a structural pattern. The main take-away of the facade is how it “provides a simplified interface to a larger body of code.” I like how the name itself actually relates to the word facade’s definition: “an outward appearance that is maintained to conceal a less pleasant or creditable reality” (Dictionary.com). As a person who likes the aesthetic side of things, this seems like a convenient design pattern, especially if people who are not working on the code end up seeing it; it may be less overwhelming to some.

Another one of the options my class had for the same assignment above is for the decorator class–which is also a structural pattern. This “adds behavior to an object dynamically without affecting the behavior of other objects from the same class.” For some reason, when I imagine this concept, I think of a decorated cake. Since it is useful for adding the same behavior to many classes; it’s like when you add a spread-out layer of fondant or frosting to a cake, it could either cover the whole section(s) of cake or just some, but it doesn’t mess up the inside of the cake.

Overall, I found this content very useful to reiterate what I had learned and Haag incorporated visual UML diagram examples along with actual snippets of code to help us compare and contrast what he was showing. The content has not changed how I think about the subject because there is no arguing here, it just shows different ways people can structure their code overall. I do appreciate how Haag also listed “typical use cases” for some of them as it makes it easier to imagine.

Article: https://medium.com/federicohaag/coding-better-using-design-patterns-4d7385a9e7ac

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