For this week’s blog, I am choosing test-driven development what is and what it is not by Andrea Koutifaris.

Test-driven development(TDD) is a software development process that relies on the repetition of a very short development cycle. First, developers write a failing test case then produces the minimum amount of code to pass that test and finally refactors it to acceptable standards.

There are three processes that are often described using TDD: Red/Green/Refactor cycle.

Red phase

In the red phase, you write a test that uses a piece of code as if it were already implemented. Without implementation and not thinking about production code, this phase is where you concentrate on writing a clean interface for future users and where you design how your code will be used by clients. The Red phase is the most important phase and it is the rule that makes TDD different from regular testing. You write tests so that you can write production code and not test your code.

Green Phase

For developers, the green phase is probably the easiest part of a TDD. This is the part where you write code but not the whole implementation, just enough for the test to pass. Make all the alarming red on the test report becomes green. In this phase, you do not need to worry about violating best practices since we will do that in the Refactor phase. This phase exists to make your task simpler and less prone to error.

Refactor Phase

In this phase, you are allowed to change the code while keeping the tests green. But there is something mandatory, that you have to remove code duplication. In this phase, you can worry about algorithms and such to make the program better. This is the phase where you can show off your skills to your users.

I really liked reading this blog and I kind of liked the idea of Test-Driven Development. I think doing it this way creates more code coverage and thus fewer bugs later on. This kind of development is a bit unique to me since I have only done behavior-driven development so far. Test-driven development changed my mind in a way. I think that doing test-driven development is more beneficial, kind of like reverse engineering, we start from something that we know is gonna work then proceed from there.

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

Source: https://www.guru99.com/fuzz-testing.html

This week’s reading is on fuzz testing. It is defined as an automated technique that is used to uncover errors that will most likely missed by manual inputs. As it is a black-box testing technique, it deals with the execution itself rather than going through the source code. Due to the way the technique works, it will be able to find serious defects and security loopholes in the software it is tested. It’s also stated that the technique is one of the most common method for hackers to find vulnerability in systems. The general steps to fuzz testing is identifying inputs, generating fuzzed data, executing tests using that data into the system, and logging all of its findings to be reviewed. Typical bugs detected by fuzz testing is assertion failures, memory leaks, invalid input, and correctness bugs. It’s very simple but will improve the quality of the software and improve security overall.

I found it interesting that the article mentions that it is a common method for hackers to use fuzzing in order to gain access into a system. However, I am not surprised that they do considering its overarching objective. Knowing that the technique is used by testers to find vulnerabilities in software, it doesn’t hurt for hackers to see if the common vulnerabilities have been accounted for through testing. Another interesting tidbit would be about correctness bugs, as I do not remember being able to test for corrupted databases, poor search results, and etc. using other techniques available. I also agree that fuzz testing alone will not solve all of the security issues. As it will account for invalid inputs, correctness bugs, memory leaks, and assertion failures. There are probably other methods available that are specialized towards handling complex security threats. In other words, fuzz testing will only help identify common vulnerabilities and sometimes help against major ones. Knowing that this method exists for black-box testing, as with other methods available through white-box testing. By using it in conjunction with other effective methods will create a product that is of high quality, secure, and cost-effective. Its similarity coincides mutation testing as it ensures the software is robust. In conclusion, it is fuzz testing is useful for showing presence of bugs in an application but will not guarantee full coverage.

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.

Source: https://www.guru99.com/mutation-testing.html

This week’s reading is on mutation testing. It is stated to be a technique that changes certain statements in the source code to see if the test cases are able to find the errors. The overarching objective of mutation testing is accessing the quality or robustness of the test cases. These mutations are generally placed in several categories, operand replacement, expression modification, and statement modification. For operand replacement, an example would be simply replacing a variable in an if-statement with a constant. For expression modification, an example would be to replace a less than or equal to operator to a greater than or equal to operator. Lastly, for statement modification, an example would be simplify deleting lines of code, adding code, or modifying data types in the program. This type of testing allows the testers to uncover errors that would have remained undetected. By comprehensively testing the tests, it will provide a large amount of code coverage of the source code. It is a very useful white-box testing technique.

I found that the article provides great depth on mutation testing, steps on how the technique works, advantages, disadvantages, and provide examples. This serves as a great refresher to the activity done in class. Before that, I would have never thought about a software technique that provides such coverage to the tests already created. I can agree with the article that it is powerful tool that brings adequate amount of error detection. It will improve code quality and early bug detection will save costs later on in development if they are caught early using mutation testing. What I found most interesting about mutation testing in general is the mutation score. It is defined as the percentage of killed mutants with the total number of mutants. By observing the percentage of killed mutants, we can see if the test cases are effective against the mutations. Unlike other white-box testing techniques, it is a very unique way of effectively testing tests for their techniques. This is similar to the black-box testing technique fuzzing, where it creatively creates unexpected creative inputs for software to uncover bugs that would have otherwise been missed. In conclusion, this exhaustive technique is very useful for comprehensively testing a program and is very effective.

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.

When we think of AI, we usually think of robots doing certain actions that can replace basic human actions. Sometimes these actions aren’t basic at all. Development timelines have also changed drastically. This Forbes article talks about how AI can potentially take over testing phases due to the shorter time-frames for gold standard releases. With more and more companies releasing software, there will naturally be more competition. Not only is the competition driving this push for AI software testing, but also efficiency. Another thing that drives a push for AI software testing is cost structures. A lot of companies are based on certain cost structures which can heavily impact the quality of a product. With the amount of testing needed for a product to be in working conditions, you may need a lot of people per team to test software. Software testing AI seeks out to have this issue resolved or at least assisted. But, the main reason that AI in software testing is mainly due to narrow constraints of time. Since deadlines are always being set shorter and shorter while standards are being set higher and higher, it seems like the logical solution is to find the easiest and most effective way to combat these restraints

This is an interesting topic because it’s something that you wouldn’t really think would make much sense. If you development an AI to test software, then this could still potentially leave the software vulnerable to bugs. This is due to the fact that there are added variables and “middlemen” added into the equation if you have automated testing. Now, not to say that AI testing is useless, as it is probably extremely efficient at testing a lot of smaller things at once, however it seems like it could be added overhead. New roles would have to be assigned for teams just to test the software for the AI that is testing the software. In concept, AI testing seems like a great idea. However, there are bound to be bugs and whether or not it is worth the risk and cost to implement AI software testing is ultimately up to the companies do it. It is a very unique topic and will be interesting to see just how companies will implement this in the future.

Article: https://www.forbes.com/sites/forbestechcouncil/2018/12/17/ai-in-software-testing-will-a-bot-steal-your-spot/#63c50ce36710

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.

In recent times, it seems as though a few companies are letting major security flaws slip through their developer tools. A few days ago, Facebook had a massive 8+ million user exposure due to a flaw in their Photos API. This bug allowed photos of users using certain apps with this API to have their data leaked and pulled without their knowledge. Facebook didn’t realize this until 12 days after this had occurred. Now, Google is in a similar boat. A few days ago, on Monday, Google revealed that it’s Google Plus social media network site (that was in the process of shutting down) also had an API bug that, again, exposed the information of users. This time on a much larger scale. Google’s API exposure hit over 51 million users. Interestingly enough, this happened just two months after they had discovered another bug that exposed data of 500,000 users. This was the initial reason for Google Plus to ultimately shut down. Although Google reported that there was no evidence of this data being “misused”, this information is still out there and the attention will surely seek the eyes of many who will misuse it.

So why is locking down an API so important? An API is a predefined set of tools that are used by developers to perform multiple actions in program. A lot of these are protocols that either pull certain information or perform various tasks. The API is the middle ground of how software can talk to each other. When there is an API bug, this can lead to information that is not suppose to be able to be pulled, get exposed to fields that should not be able to. This was the case with Facebook’s Photo API, and now the case with Google’s Google Plus media API. What we can learn from this is, whenever you are modifying or testing with API’s, always make sure that boundary tests are in place to make sure that certain data can not be pulled by any alternative means. Most of the time, only authorized developers are only permitted access to certain API’s, nullifying any outside attacks. However, if an API does not have the correct stops and security in place, user data is at a massive risk as shown by these two examples of mass user data exposure.

Article: https://www.softwaretestingnews.co.uk/17470-2-google-plus-closure-api-bug/

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.

And the biggest question if the software testing is manual testing vs automatic testing? Why do we need automated testing?

@All Welcome to my last blog post for my Software Test class. As a last blog post for this class I wanted to talk about the Automated Testing.

From the name we can tell that Automated Testing is automated. Automated testing is done through an automated tool, which is needed in exploratory tests and in maintaining test scripts while increasing overall test coverage. Automated Testing is usually used for large projects that require testing the same area lots of times.
Automated Testing has its own implementing strategy which consist in the shape of a pyramid. This strategy calls for automating testing at three different levels. The biggest percentage of this test automation pyramid goes to unit testing. The is followed from API testing and UI testing.

Software tests have to repeated often during development cycles to ensure quality. Every time the source code is modified, software test should be repeated. From my experience at my work, we recently automated the testing and deployment process for one of our systems. For every deployment, we had to test every connected system. One of the benefits of Automated Testing is that is much faster than the manual testing and it also can reduce the time to run repetitive tests all the time. In my opinion time savings equals cost savings. Another benefit of Automated Testing is it increases the test coverage.  It can easily execute thousands of different complex test cases during every test run, providing coverage that is almost impossible with manual testing.

https://www.qasymphony.com/blog/test-automation-automated-testing/

Kyle makes a good point in explaining the differences between the test automation and automated testing as its important to know the difference.

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

REST is a term coined by Roy Fielding to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.  It represents the state of database at a time. REST is an architectural style which is based on web-standards and the HTTP protocol. In a REST based architecture everything is a Resource. A resource is accessed via a common interface based on the HTTP standard methods. You typically have a REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.  Every resource should support the HTTP common operations. Resources are identified by global IDs. REST allows that resources have different representations, e.g., text, XML, JSON etc.

HTTP Methods

The PUT, GET, POST and DELETE methods are typically used in REST based architectures. The following table gives an explanation of these operations:

POST –> INSERT (adds to an existing resource)

PUT –> UPDATE (overrides existing resource)

GET –> SELECT (fetches a resource, while the resource is never changed via a GET request)

DELETE –> DELETE (deletes a resource)

USE NOUNS BUT NO VERBS IN PATH/URI:

USE PLURAL NOUNS

Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all resources.

/cars instead of /car

/users instead of /user

/products instead of /product

SOME TIPS FOR YOU:

• Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET method or Query parameters for state changes.
• If a resource is related to another resource use sub resources.
• Both, client and server need to know which format is used for the communication. The format has to be specified in the HTTP-Header.
• Make the API Version mandatory and do not release an un versioned API.
• Use a simple ordinal number and avoid dot notation such as 2.5
• Use a unique query parameter for all fields or a query language for filtering.
• Allow ascending and descending sorting over multiple fields.
• Use limit and offset. It is flexible for the user and common in leading databases.
• To make the API experience more pleasant for the average consumer, consider packaging up sets of conditions into easily accessible RESTful paths.

References:

https://en.wikipedia.org/wiki/Representational_state_transfer

https://restfulapi.net/

https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

Thank you for your time!

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