There were four tests conducted to ensure that opening the GIF could be performed by Gifitti without any problems.
The first test was the ability of the program to load a GIF. The program is loaded intially and a GIF is selected
The first test was the ability of the program to load a GIF. The program is loaded initially and a GIF is selected
that will be loaded into memory, being displayed to the user. The results of this test matched the expected output.
The next few tests pertain to scenarios where it would cause errors in the program. They all start with the program running but with different errornous inputs such as no file path, null filepath, and inncorrect file type. All these inputs do not cause any change in the
The next few tests pertain to scenarios where it would cause errors in the program. They all start with the program running but with different erroneous inputs such as no file path, null filepath, and incorrect file type. All these inputs do not cause any change in the
running program which is the expected output. All the tests in opening a GIF file has been successful in determining a proper functioning.
\subsection{Save a GIF}
There are three tests conducted that verify that the GIF modify in the program is saved properly on the file system of the user's
computer. They all start with an intial state of a GIF already loaded into the program and are saved either in known, chosen or non-existing locations. When the user selects a valid location, the program will save the GIF as it appears in the program but gives an error if you try to save it in a non-existant location. This is the expected output of the test performed.
computer. They all start with an initial state of a GIF already loaded into the program and are saved either in known, chosen or non-existing locations. When the user selects a valid location, the program will save the GIF as it appears in the program but gives an error if you try to save it in a non-existent location. This is the expected output of the test performed.
\subsection{Start, Stop, Modify Length}
The test pertaining to the stop and start of the animation has the initial conditions of a GIF already loaded in and will take input of a GIF either in an animation or stopped on a frame, with the start and stop button being pressed to pause or resume the animation. The program performs these functions as expected. The testing for the modification of the GIF was successful as the program takes a GIF and cuts it down to the specified frame length. For example, a GIF of 20 frames was successfully shortned to frames five to ten.
The test pertaining to the stop and start of the animation has the initial conditions of a GIF already loaded in and will take input of a GIF either in an animation or stopped on a frame, with the start and stop button being pressed to pause or resume the animation. The program performs these functions as expected. The testing for the modification of the GIF was successful as the program takes a GIF and cuts it down to the specified frame length. For example, a GIF of 20 frames was successfully shortened to frames five to ten.
\subsection{Save In Different File Format}
Four tests were conducted in the exact same fashion where a GIF, already loaded into the program, had its frames exported into an image format. These four tests were extremely successful in exporting the images in their specific file format (JPEG, PNG, TIFF, BMP) that did not overwrite each other. The output matched the expected output.
\subsection{Help Context}
One test was performed to determine if the help section could be easily acccesible and understandable. With the program loaded, the help tab was tested if it opened and the definitions given were viewable. This test proved to be successful in matching what the expected output was supposed to be.
One test was performed to determine if the help section could be easily accessible and understandable. With the program loaded, the help tab was tested if it opened and the definitions given were viewable. This test proved to be successful in matching what the expected output was supposed to be.
\subsection{Resize}
A GIF was loaded into the program and a specific size was specified by the user. The GIF would be resized to that specified size which matched the expected output of that function. There was also a test that went through the exact same process where it utilized edge case to determine if it crashed the program. As expected, it did not crash it.
...
...
@@ -112,13 +112,13 @@ Unit Testing provided by the framework. This ensures the system does not
build the testing package into the consumer version of the software.
\section{Changes Due to Testing}
Through various test plans being enacted onto this program and other brute force testing by persons who had no understanding of code we were able to identify certain areas that were lacking. The general trend is that if a command is successfully inputed, that the expected output, that is the GIF, has been produced accurately for the majority of the time. The main issue the project had to be adjusted to is the different methods and input could be incorrectly given. For example, putting negative values for the frames wanted out of GIF. Through these testing methadologies, no big corrections were required but extensive testing revealed edge cases that were not previously considered that needed to be corrected. For example, one of the testers caught a work around the file selection to be able to select JPEG images as our input. Of course, futher testing can always be done to catch a possible edge case that has not been considered before.
Through various test plans being enacted onto this program and other brute force testing by persons who had no understanding of code we were able to identify certain areas that were lacking. The general trend is that if a command is successfully inputted, that the expected output, that is the GIF, has been produced accurately for the majority of the time. The main issue the project had to be adjusted to is the different methods and input could be incorrectly given. For example, putting negative values for the frames wanted out of GIF. Through these testing methodologies, no big corrections were required but extensive testing revealed edge cases that were not previously considered that needed to be corrected. For example, one of the testers caught a work around the file selection to be able to select JPEG images as our input. Of course, further testing can always be done to catch a possible edge case that has not been considered before.
\section{Automated Testing}
This test plan has utilized automated testing for the verification of the manipulation functionality that changes the GIF. That is to say that the
exported GIF image will match what is created by the user of our product.
The only tool to be utilized to test this product will be the Microsoft Unit
Test Framework that is native with Visual Studio. Through this unit testing framework, we will have it set up that it automatically does comparisons of the GIF output to the expected output where it can in a quick manner compare the pixel values to ensure complete accuracy. Throughout utilizing this framework, we have always gotten successful results which allowed us to identify other areas wher the majority of the problems occured.
Test Framework that is native with Visual Studio. Through this unit testing framework, we will have it set up that it automatically does comparisons of the GIF output to the expected output where it can in a quick manner compare the pixel values to ensure complete accuracy. Throughout utilizing this framework, we have always gotten successful results which allowed us to identify other areas where the majority of the problems occurred.
%\newpage
\section{Trace to Requirements}
Refer to Test Plan to see corresponding Tests and SRS to see corresponding Requirements.
