Decision Graphs

The article I chose to cover for CS-443 this week is a research article titled Decision Graphs and Their Application to Software Testing by Robert Gold. This article goes in-depth on one of the subjects covered in our Activities, DD-path testing, as well as other decision-based testing methods. One of the things I like about this article is that it uses a lot of mathematical notation and logic to represent how the methods work. It also has very detailed proofs to show why the necessary branch/edge coverage is reached. There are several different examples of code that have corresponding decision graphs, to show the different parts of making a decision graph.

Looking at the example of the function f1 given in the article (Figure 3), there is something this article did with DD-path graphs that we did differently in class. whereas our DD-paths were just all the nodes in between with an in-degree and out-degree of 1, when Robert combines several D-nodes into one DD-path, he includes the first node that has an in-degree of 2 and the last node which has an out-degree of 0 along with the rest of the nodes. Therefore, his DD-Path graph for f1 is a lot simpler than what we would have made doing what we did in class. I’m curious which way is better. The article also dives into a topic about path testing we discussed but did not have an example of, that is when code branches into multiple different endpoints. In order to achieve branch coverage in these examples, you have to have multiple tests with different inputs that satisfy every branch.

Overall, the abundance of examples in both code and their associated graphs, as well as the very clear mathematical notation and rigorous proofs makes this article a really interesting read if you are a Mathematics major/minor. The conclusion at the end details a major application of this are modeling programs with flow graphs to represent programs. There are many different kinds of decision based testing methods that you can use, and if you have any questions about one of them or how they work, this is an amazing resource.

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.

Static vs. Dynamic Testing

Greetings reader!

Today’s blog,  will discuss the differences between static and dynamic testing. I will be briefly explaining the benefits for each test, as well as pointing out their distinct features. I will also be sharing my analysis of Software Testing Help’s-” Static Testing and Dynamic Testing – Difference Between These Two Important Testing Techniques” article from which I read. Without any further babbling, let’s start.

Static testing is a testing technique that takes the form of design reviews, functional requirement reviews, code walkthroughs, business requirement reviews, and test documentation reviews. It is a ongoing activity that is not just done by testers.

In static testing, code is not executed; instead it checks the code, requirement documents, and design documents to detect errors.  The goal of this technique is to improve the quality of software by finding errors in early stages of development. Static testing is often called as non-execution technique or verification testing.

Static Testing Techniques:

  • Informal Reviews
  • Technical Reviews
  • Walkthrough
  • Inspection
  • Static code Review

Dynamic testing is more hands-on and develops on the product itself and not on an a representation of the product. A much formal process of test cases, considerations, and execution explain the dynamic testing methods. Dynamic testing is when you are providing an input, receiving an output, and comparing the output to the expected behavior. It is a system made with the intent of finding errors.

In dynamic testing, code is executed. It checks for working behavior of the software system, memory, and the performance of the system. The goal of this technique is to ensure that the  product works in agreement with  the business requirements. Dynamic testing is used at all levels of testing and it can be either black or white box testing. Dynamic testing is also known as validation testing.

Dynamic Testing Techniques:

  • Unit Testing
  • Integration Testing
  • System Testing

In conclusion, both static and dynamic testing reveal mistakes and coding errors using different methods. Verification (Static) and Validation (Dynamic) are two measures used to check that the software product meets the requirements specifications. Together they try to help improve software quality.

Software Testing Help’s-” Static Testing and Dynamic Testing – Difference Between These Two Important Testing Techniques” helped me a lot when reading about Static vs Dynamic testing.

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

Designing for Disability

Through learning how to code alongside a diverse group of people who learn best using a variety of methods, I myself have learned a very fundamental principle: different people with different skills and knowledge learn differently. This is similar with learning across all subjects and skills. While some people are visual learners, others are more attune to a more hands-on learning experience. It’s important that all designs for public use embrace the diversity of its users to change the design of their display to be more effective, since some designs will work better than others. When dealing with the internet and any public source, most things must be easily interpreted by the most number of people.

With that, we turn to the code writers and program design groups who study what makes the user interface easier to use. How do we develop and design websites and applications for those with cognitive differences? Not all effectively written code is considered “effective” by those with inattention, anxiety or depression disorders. Knowing that, how can we make our code better for those in the general population who are affected?

To research further, I used the blog post “Designing for Cognitive Differences” by Brandon Gregory, a software application designer and developer, as reference. He explains the common symptoms of common mental disorders such as inattention, anxiety, and depression. He then goes on to explain that the primary solution to such disorders is creating inclusive designs. This means that the user interface is improved to make sure that users who suffer from certain mental disorders are not swayed from using their application through simple things like changing a “submit” button to say “send payment information” or “change sound settings”. These are small improvements, but they make all the difference. Brandon Gregory then concludes his post, by explaining that,

“…  disability takes many forms, and accessibility and inclusive design need to take just as many. In our industry, compassionate discussion around physical disabilities has been a huge benefit, and cognitive differences need to be part of the conversation too. Removing unnecessary distractions, reassuring users that they’re doing the right thing, and keeping things easy for users who are struggling are things we can do to accommodate these users and make them feel like you actually want them to use our sites and apps. As one of these users myself, I can say we would really appreciate your efforts. ” -Brandon Gregory

As someone who knows many people with the listed disabilities, I enjoyed this article. It clearly identifies what people struggle with and how to improve every day websites in little ways to be better used by the general public. Being aware of these disabilities will make the internet more safe and easy to use overall.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Air & VR Testing

For my last podcast I will be doing a podcast from Joe Colantonio. This week he talks with Noemi Ferrera who is a computer Scientist passionate about technology and testing. She has worked in popular companies like IBM, DELL and microsoft and most recently she is working in China for Netease Games. The tool that Noemi is working on right now is called AirTest. AirTest is a solution for automating applications and games. It is an IDE that allows you to use visual testing or tools that use the DOM or object model abstractions which can be used to create your automation correctly. AirTest works on a number of systems including Windows, coco, unity etc. It is open source and partnered with google. The next thing Noemi brings up how she does VR testing. Her approach is that many of the steps would be similar to any application in general, including tools. Other steps might be a little different and it is important to take into account steps and tools that are specifically need for virtual reality testing. She also mentions some of the problems that programmers and testers forget to take into account like the amount of space or how close VR users are. There are certain safety precautions that need to be handled amd better taken care of. One of them being VR motion sickness. This is caused because your eyes are seeing the movement but your body is not feeling it. So you are physically not moving but your eyes are seeing it. She also talks about things that she has been able to add to VR. For example she has added VR capabilities for card board for google. The big difference between VR and any other application is that in VR you have objects that may be behind you. In order for you to see the object and to de certain actions you need to move the camera which is kind of an issue. She was able to rotate the camera on demand either to an object and instead of clicking on the object, you can click on the screen which in hand clicks on the object. This also allows you to check things like location and position and to verify information. Overall for my last blog I found it very interesting. What I really liked what how she mentioned actual problems that she has seen gamers deal with in VR. She is taking into consideration those problems and finding solutions as a tester to fix them. I also found it interesting how much she talked about VR since it is such big upcoming technology that will only get bigger. VR is a very important area to know about and might even be something that I will be working on in my job.

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

Agile Testing

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.

Decorator Design Pattern

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.

Test Automation, are you doing it right?

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.

On REST API’s

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.

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect. 
They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about. 
He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things.
He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something in this field, by establishing why a need exists and then later explaining the concept.
There are three things covered that influence architecture. First, agility, which is the speed and coordination to change. Most companies try to embrace this, but many businesses fail at it. Second, velocity, which is the speed of something in a given direction. Third, modularity, which is when independent parts can be combined in lots of ways. They went over the upsides and downsides to each, and you have to compromise many times at one aspect for another
I thought one of the most interesting parts of the podcast was when he said that if you wanted to see what was coming next in technology, read academic papers from twenty years ago. It takes that long for one level of the level of architecture, hardware, to catch up to another, software. It is only recently that we can implement this technology.
Another interesting thing he said was that one of our biggest inhibiters to evolution is the integration of data and functionality. He foresaw a paradigm shift in how we handled this.
As a parting message, he was asked, “what would one piece of advice you would give to an aspiring software architect,” and his answer surprised me. He said to work on people skills, and that was the “hands down” most important advice he could give. This skill is so key in everything you do, including lead and mentor. I found this incredibly interesting, because I am often reminded about how we never do everything in a bubble, and it is extremely important to be able to “play well with others.”

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

Test Automation and Continuous Testing

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.