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.

https://qacomplete.com/resources/articles/test-scripts-test-cases-test-scenarios/

          I found a blog post this week that talked about Test Cases and the differences between Test cases and Test Scenarios. It starts by explaining Test Scripts and how they are the most detailed way to document testing. Test Scripts are usually a line to line description of actions within the code. It holds a lot of information on the software to relay data to the tester. It goes on to talk about how Test Cases are the second most detailed way of documenting testing work. Test Cases hold less information than Test Scripts because they only describe a specific function or idea to be tested. It allows more flexibility for the tester to find different inputs to test. It allows more detailed testing for testers that are familiar to the application for the program. The blog then introduces Test Scenarios that are known as the least detailed type of documentation. Test Scenarios hold a simple description of a function or intent a user might have when using the program. Like Test Cases, this allows more flexibility for the tester but also causes more areas that are likely to not be tested due to the undetermined scope of the problem.

          I chose this article because Test Cases were the most interesting subject when learning about the process of testing. I wanted to understand the difference between cases and scenarios which is what sparked my initial curiosity. I found that this blog was really interesting because it explains how testing can be structured based on the amount of information given. I enjoyed how the post explained the levels while also explaining how they benefit the tester through the expansive flexibility while also stating that this can lead to more grey areas of testing. I was able to grasp an understanding how these testing terms differ from each other and it expanded my visibility when looking at the testing process as a whole. The most interesting part of the blog post was the when it explained that testers can choose any of these terms to test programs depending on their knowledge of the product. This leads to the point where understanding the application of the product can also have great effects on how the tests are created. I found that there was a lack of diagrams within this post, but the information and definitions were easy to understand. I enjoyed this source very much as it easily explained the testing terms and how they differed from each other.

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

Michael Bolton’s post How Long Will the Testing Take? on his blog DevelopSense goes into depth on how long testing takes. Bolton claims good software testing as a process takes just as long as development, because the two are actually interwoven as processes and should happen simultaneously.

I think a lot of people brush off testing systems and software because of the idea that it takes additional time and can make the release of a project come later. However, as Bolton states, testing actually occurs simultaneously to development, as things are tested as they are implemented into the system to make sure they interact correctly. With this in mind, the program should be fully tested not long after it is completely developed. It doesn’t really cost much extra time, just the extra costs of developing tests. However, doing it this way also allows you to fix issues that come up along the way, before they become larger issues.

In some of my earlier programming classes, students were often encouraged to write one test and make sure it works before moving onto the next test. We were also encouraged to write tests after every method we made in our programs. In a way, we were clearly being prepared for this approach to development and testing, and it was clear even then why it is a good way to work on a program. It is logical, as incremental development seems a lot safer. You avoid getting overwhelmed with errors and issues that all compound on each other at once when you write your tests this way.

The blog post also covers the silliness of the question of how long testing will take. If your developers and testers are working together and doing what they’re supposed to, testing will finish as soon as development does. Although you can test the system in post-production, it is entirely optional, and is only done with good reason. So in the future, if I am ever managing the development of a system, I will be able to recognize what the testers are doing and ask more productive questions.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

In the post Grouping Components by Use Case, Robert Annet discusses a strategy he uses when making context diagrams. After determining the use cases of his program, the components involved in each of the seven use cases are divided into groups within the diagram with different colored barriers. Structurizr, the web application Annet used for his diagrams, allowed him to filter the diagrams by the use cases. This makes observing which components are involved even easier visually.

The benefits of using this strategy of dividing your context diagrams into use cases is clear if you are working with a program that is complex enough to warrant it. A complex program in this case being one with a lot of different components which all are involved in several different interactions. If you have to make changes to a certain interaction withing your program, you can look at the components involved in the use cases and identify what you have to change to make the desired effect. Since your program has a lot of different and interlaced interactions and components, using these use cases and filtering your diagram into smaller parts makes it easier to understand the interactions and whats happening with the involved components without being overwhelmed by a ton of different components that don’t have any involvement. In my opinion, it is much clearer when you only have to see two or three components when you want to change an interaction in the program.

Using this strategy can also help you find other issues or reliances in your program. For instance, you may find that most or all of your use cases use the same component. Since this component is so integral to the interactions in your program, it is likely not one you are going to want to change much. This strategy also can help you find components that are not being used in your program, and thus may be unnecessary or you may need to reassess your use cases.

Overall, I thought Robert Annet’s idea of dividing programs into different use cases is very interesting and obviously useful as a concept, so I’m sure I’ll use in the future. Whenever you are dealing with a large enough system, you should consider looking at the diagram from this angle to see if you can identify any problems or vulnerabilities.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

For today’s blog I will be discussing the topic of testing with mocking. I recently read an article called “Mock? What, When, How?” by Lovis Moller. So let’s jump right in. What is mocking in terms of testing? Think about your code as a giant puzzle. All the pieces fit together, but they fit together in specific ways. Say you’re missing a piece of the puzzle because your partner hasn’t finished their part of the code yet. The new problem is this: how can I test my code without my partner’s piece of the puzzle? The answer is by using mocking. Mocking allows us to emulate or “mock” our partner’s puzzle piece that we are missing so that we can test our code without having to actually have the rest of the puzzle pieces. So mocking seems like a pretty good idea and like something we should use all the time, right? Wrong. The article talks about some of the pitfalls of mocking, which we will now talk about. First, the article says to mock only code you own. Do not mock third-party code simply because it’s not yours and you do not know how it works or how it should work. Another rule of thumb is to avoid mocking values and concrete classes. You should avoid mocking values because the objective of mocking is not to test for specific values, but rather it is meant to test the relationships and interactions between different classes (pieces of the puzzle). Concrete classes should not be mocked because of all the extras (methods, unused lines of code, etc) that come along with the  concrete class. It is more efficient to use mocking with an interface in this case.

In the past few weeks we have been doing testing with mocking in our CS class. I think it is a really neat and useful way to test because you can get stuff done on your end without having to wait for someone else to finish. In a world where we work as groups to complete projects, human error is always an issue. We could have our parts of the code done weeks before a deadline while our partner waits until the night before the deadline. Problem here is that we might not be able to proceed in testing and fixing our code because what our code does as a function relies on our partners code. We certainly do not want to wait until the night before a deadline to test and fix everything. Mocking helps us with this by emulating the code we are dependent on. I hope to use this more in the future.

Here’s the link to the blog: https://blog.codecentric.de/en/2018/03/mock-what-when-how/

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.

This article from softwaretestingmagezine.com talks about how testing and monitoring live and active services is a key element of software quality assurance. After deployment, making sure all of the bells and whistles of a service are up-to-date is a very important thing. Not only is it important on the programmer’s end, but it is extremely important on the client side because you should have a smooth experience for the both of you. Without proper testing of a product or service, it is impossible to correctly gauge how it will perform, which is why pre-launch and post-launch immanence testing is a must, especially today. This article then goes into many online services that monitor performance and uptime of certain services. Let’s go into some of these now.

A very important aspect to tracking a service is by recording it’s uptime. A service called “StatusCake” does just this. StatusCake is a paid monitoring service that can monitor page speeds had extremely high rates. They claim to have a very large system for monitoring big servers. Another nice thing about StatusCake is that it can set reminders about domain renewals. SSL monitoring, and much more. Although at may seem like monitoring uptime of your service wouldn’t make sense, it is actually very crucial in many ways. One thing I learned from this article about how important this is, is by monitoring your up time, depending on how long a service is kept online without failing, you can determine by logging where issues lay when something does occur. Something such a service outage or service lag can easily be tracked and tested if you have tools available to help you track it.

Tracking these issues with a system can be tricky, but there is another testing tool that can help us do exactly this. This tool is called Uptrends. Uptrends is another software testing tool that actually notifies you and double checks when something is wrong with your service. One of the harder things is tracking exactly when or where an error in a service occurs. The interesting thing about Uptrends is that it will actually give you detailed reports and statistics on these errors and also sends out email alerts when something goes wrong. This is another very important aspect of software quality assurance and testing. When something goes wrong you need to have information about the failure as fast as possible. With services such as this, you can receive notifications as soon as the fault happens so you can act accordingly to the issue.

Many services are available to help developers and clients for software testing and quality assurance. Depending on what you need, it is very important to keep a close eye on operations after a service is launched or completed, especially if it is being upgraded or modified in any way.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.