The “Practice, Practice, Practice” pattern is explained as one of the better ways to develop your skills in new areas and get better with hands-on learning. The book continues by saying that being able to learn skills on your own time gives you multiple benefits that can’t exactly be emulated in a work environment. In a work environment, you constantly feel the pressure of learning new skills and learning them quickly while practicing by yourself allows you to control the rate at which you want to comfortably learn. The main idea of this pattern is to have a stress-free environment for you to experiment and eventually learn in. The idea of integrating feedback loops should also be in the back of your mind since it could prove useful here. It is possible to develop bad habits as you practice so making sure that someone can give feedback on your practice afterwards is also crucial. This allows a better learning experience in the long run by quickly correcting any habits that form rather than letting them sit with you for an extended period of time.

            I found this pattern to be important and useful as a reminder to make sure that I keep practicing. It outlined the positives of practicing code and how to set a personal pace for learning compared to a work environment. I found that when the book talked about the fast pace of work being different from learning at home, it resonated with me much more. I want to incorporate this pacing technique for personal learning more to find out how it can affect my overview on a subject. I predict that it will allow me to continue learning without getting too burned out since I would be able to control the pace at which I want to digest information. This can be helpful because there are some days where I don’t feel like working a lot which allows me to control the learning load compared to days where I want to learn a lot. I agree with this pattern for that very reason, to be able to personally create my own time schedule as long as I continue practicing at a continuous rate. Practice can only make my knowledge base greater and it allows me to experiment with ideas that I wouldn’t be able to in a work environment at my own pace.

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

Agile Testing

For this week’s blog post I will be discussing Agile Testing, describing what it is, its principles and more. First of Agile Testing is a software testing process that follows agile software development-based principles. Essentially agile testing is a continuous process rather than being sequential. The testing begins at the start of a project becoming integrated into the testing and development of the entire project. Now there is a testing like this called waterfall testing where waterfall testing is a bit more structured and detailed while agile testing is more minimal. From the blog I list down below there is a large compare between the two that I will save for the viewer to visit as it covered in fall better detail there than what I could write here.

Main Principles of Agile Testing

The main principles that come out of agile testing are as follows. Testing is continuous ensuring the continuous progress of a project with Continuous feedback that provides an ongoing basis for what your project’s requirements are going to need. Tests are performed by the whole team, the developers and the business analysts of a project also test the application instead of just the test team. The decrease in time of feedback response, this is essentially due to the continuous testing allowing a better understanding of what is happening allowing for a better response rate. Simplified and clean code, Less documentation, and test driven  are all key principles that arise from the continuous testing as listed above several times, allowing for all of this to be done in a much cleaner fashion.

Advantages of Agile Testing

The benefits from agile testing are simple as it all comes from the continuous model it follows. First and for most it saves time and money, due the testing taking place right from the beginning and not at the end. Less documentation is needed, along with it being very flexible and adaptable to changes throughout its progress. Regular feedback is provided once again due to the continuous model.

In conclusion the agile testing not only facilitates early detection of bugs/defects but reduces time spent on fixing them. This model of testing can yield a much better-quality product/project due to its constant testing processes. The article written here is very informative about agile testing, I just only wish that some of the ideas were fleshed out a little more with perhaps a few examples showing how it works in reality.

https://reqtest.com/testing-blog/agile-testing-principles-methods-advantages/

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

For this week’s blog post I will be discussing the decorator design pattern discussed in Derek Banas’ Design Pattern Video Tutorial’s found on YouTube. Here you can find pretty much any design pattern you are interested in where he will discuss it in a video usually under 15 minutes.

You use this design pattern when you want the capabilities of inheritance with subclasses but know you need to add functionally at run time. You can modify an object dynamically because of this. Decorator Design is more flexible than inheritance. Simplifies code because you add the functionality using many simple classes, causing you to be allowed to extend with new code. The example he uses explaining the pattern is a great one. You have a pizza and you want to be able to put multiple toppings on top and such. He shows how messy it can be with simple subclasses and an inheritance-based system. Then he shows how to do it in the design pattern showing how useful it can be in situations like this. Essentially you make a pizza interface, with a concrete class being a plain pizza where you can modify its toppings. Then you have a Topping Decorator abstract class where the bases for the toppings will go, followed by a topping class for each topping you’d like to have. Next, he runs through what this would like in code. He writes the code out improving upon the previous inheritance-based code he had down before. What he writes is a much cleaner and simpler version of what he set out to do which is made possible by the decorator design pattern.

This entire YouTube channel, specifically this playlist of his is perfect for learning any of the design patterns we may or may not discuss in class or you want to learn on your own. Like I said above he explains everything in detail in a good pace where almost anyone could understand what is happening in the video. Along with the examples he shows and writes in real time, I recommend this channel/playlist to anyone who is interested in learning design patterns.

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

Source: https://www.softwaretestinghelp.com/automation-testing-tutorial-1/

In this week’s reading was about a test automation tutorial. It defined test automation as a technique to test and compare the actual outcome with expected outcome. Mainly used for automating repetitive tasks which are difficult to perform manually. Test automation allows testers to achieve consistent accuracy and steps towards testing. This in return would reduce overall time towards testing the same thing over and over. As the tests should not be obsolete, it would allow new tests to be added on top of the current scripts when a product evolves. They also suggest that these tests should be planned so that maintenance will be minimal, otherwise time will be wasted when fixing automation scripts. The benefits are huge but there will be challenges, risks, and other obstacles. Such as knowing when not to automate and turn to manual testing which would allow a more analytical approach towards certain situations. Which is directly related to the perception that if no bugs are introduced if automation scripts are running smoothly. It is concluded that test automation is only right for certain types of tests.

I found this tutorial to be incredibly helpful as it provided real-life situations as examples for many of the topics covered. It is effective at making the user see the reality behind test automation, through the five W’s – who, what, when, where, and why – even not stated explicitly. I can conclude that I took test automation for granted as I assumed that all tests would be automated regardless. That way of thinking is a wrong step for a tester to make, as not all bugs can be discovered through pre-defined tests in static test cases. Manual testing is necessary to be able to nudge bugs to appear through manual intervention as it pushes the limits of the product. Overall, the main take away for myself would be the planning phase of test automation. By splitting different tests into different groups, we can easily set a path for testing in an ordered way. For example, it would be best to do tests for basic functionality then integration before testing certain features and functionalities. It would logically be more difficult to solve complex bugs before smaller bugs. It goes to show that test automation is not as easy as it looks.

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 tutorial What is REST API Design? on mulesoft.com is a beginner friendly description of how REST API’s operate. The first section of the tutorial focuses on defining RESTful API’s and how they are typically used. However, the majority of the post describes the five key criteria that turns a regular API into a RESTful one.

What makes Representational State Transfer (REST) API’s different than other API’s is adherence to predetermined protocols. Like how IP and TCP are a set of guidelines that allow information to be shared over the internet, REST API’s have a set of five criteria that every developer designing this system must follow.

The first criteria is the API must be a client-server architecture. This rule says that the client end and the server end of the system should be separate and have no dependencies. Any changes to the database or the program calling the API should not effect the other part of the system.

Second, the API must be stateless, which means that all calls on the API should contain all the data the server needs to fulfill the request. The client end does not need to store data in the server itself.

Third, when the REST API’s respond to requests, data that is sent to the client should be stored in cache memory, which is faster and reduces stress on the server end.

Fourth, there should be a uniform interface handling communication between the client and server end. Usually, this is done by using HTTP and URL’s. This is a crucial function of the REST API, as there needs to be a common lifeline between the requests and responses.

Finally, the API should be a layered system. This constraint ensures that the program will be divided into layers, each focusing on a particular responsibility and handling communication to the next level above/below. This gives a certain level of security and flexibility between layers of the system.

This tutorial definitely helped my understanding of REST API’s, as the author went into some detail describing each of them and what role each constraint plays in achieving the goal of RESTful API’s.

From the blog CS@Worcester – Bit by Bit by rdentremont58 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.

Blogger Kyle McMeekin writing for QAsymphony.com in his post “Test Automation vs. Automation Testing” explains the definition and distinction between automated testing and test automation, and also goes into their roles in continuous testing and why this type of testing is important  to understand.

McMeekin begins by defining automation as using technology to complete a task. When applied to the field of software quality assurance, there are two different types of automation: automated testing and test automation. While the terms sound interchangeable, the author differentiates them by explaining how the scope of each is different.

Automated testing is concerned with the automation of executing particular test cases, while test automation is concerned with automating the management of the test cases as an aggregate. While automated testing is actually carrying out the tests we are interested in, testing automation manages the pipeline of all of the automated tests. So the scope of automated testing is more local compared to the more global scope of test automation.

After differentiating between these two types of automation, McMeekin describes how they apply to continuous testing, and explains the importance of this strategy in today’s economic climate. While most software testing is done after development is finished, today more tech companies are using models where the software is constantly in development constantly updated even after it becomes released. In this case, testing must be conducted as soon as something is changed. This technique is known as continuous testing.

However, keeping track of every test suite constantly is a huge task itself. This is where test automation comes in. If we are able to automate the process of managing the processes of this ever-growing list of test suites, a massive amount of work is saved on the tester’s part, freeing up time to create effective test cases.

Automation is at the heart of computer science, as saving work by taking advantage of computer’s abilities to handle processes is integral to being a good developer. So learning how to apply automation in the context of software testing is definitely advantageous. Especially since it is so common nowadays for programs to be constantly added to after release, the amount of tests to keep track of increases steadily. By taking advantage of test automation and keeping track of all the testing processes, we don’t need to worry about the timing of the tests, we can spend more time testing and analyzing the behavior of software.

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