CS@Worcester CS-443
From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.
CS@Worcester CS-443
From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.
CS@Worcester CS-443
From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.
CS@Worcester CS-443
From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.
CS@Worcester CS-443
From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.
CS@Worcester CS-443
From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.
CS@Worcester CS-443
From the blog George C Blog by George Chude and used with permission of the author. All other rights reserved by the author.
This week in class we learned about path testing, which is a white box method that examines code to find all possible paths. Path testing uses control flow graphs in order to illustrate the different paths that could be executed in a program. In the graph, the nodes represent the lines of code, and the edges represent the order in which the code is executed. Path testing appealed to me as a testing method because it gives visual representations of how the source code should execute given different inputs. I took a deeper dive into path testing after this week’s classes and found this blog that gave me a deeper understanding of path testing.
When you have decided that you want to perform path testing, you must create a control flow graph that matches up with the source code. For example, the split of direction between nodes should represent if-else statements and for while loops, the nodes towards the end of the program that have an edge pointed at an earlier node.
Secondly, pick out a baseline path for the program. This is the path you define to be the original path of your program. After the baseline is created, continue generating paths representing all possible outcomes in the execution.
For a lengthy source code, the possible outcomes could seem endless and could therefore end up being a difficult, time-consuming task to do manually. Luckily, there is an equation that determines how many test cases a program will need with path testing.
C = E – N + 2P
Where C stands for cyclomatic complexity. The cyclomatic complexity is equivalent to the number of linearly independent paths, which in turn equals the number of required test cases. E represents the number of edges, N is the number of nodes, and P is the number of connected components. Note that for a single program or source of code, P = 1 always.
Path testing reveals outcomes that otherwise may not have been known without examining the code. As stated before, it can be difficult for a tester to know all the possible outcomes in a class. Path testing provides a solution to that by using control flow charts, where the tester can examine the different paths. Path testing also ensures branch coverage. Developers don’t need to merge code with an existing repository because the developers can test in their own branch. Unnecessary and overlapping tests are another thing developers don’t have to worry about.
Path testing can also be time consuming. Quicker testing methods do exist and take less time off further developing projects. Also in many cases, path testing may be unnecessary. Path testing is used often by many DevOps setups that require a certain amount of unit coverage before deploying to the next environment. Outside of this, it may be considered inefficient compared to another testing method.
Blog: https://blog.testlodge.com/basis-path-testing/
From the blog Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.
I chose this blog because I was interested in learning how to optimize the selection of test cases without sacrificing thorough coverage. During my search, I came across an article on TestGrid.io on equivalence partitioning testing, which was fantastic in removing redundancy from testing. As I develop my programming and software testing skills, I have found this method especially useful in making the testing process simpler.
Equivalence partitioning is a testing technique applied to partition input data into partitions or groups based on the assumption that values in each partition will behave similarly. Instead of testing each possible input, testers choose a sample value from each partition and hope the entire group will result in the same output. This reduces the number of test cases but still provides sufficient coverage.
For example, if a program is able to accept input values ranging from 1 to 100, equivalence partitioning allows the testers to categorize them into two sets: valid values (1-100) and invalid values (less than 1 or more than 100). Rather than testing every number in the valid set, a tester would choose sentinel values like 1, 50, and 100. Similarly, they would test the invalid range with 0 and 101. This is time-efficient but identifies errors simultaneously.
I employed the TestGrid.io article because it explains equivalence partitioning in an understandable and systematic manner. Much other testing material is too complex or ambiguous for newcomers, but this article simplifies it and incorporates real-world examples. This allowed it to be simple not only to understand the theory, but also to apply the method to real-life situations.The article also discusses the advantages of equivalence partitioning, including reducing redundant test cases, being more efficient, and offering complete coverage. As an individual interested in improving my testing methods, I found this useful because it corresponds with my goal of producing better, more efficient test cases without redundant repetition.
Equivalence partitioning testing is a sound approach to maximizing test case selection. It enables the tester to focus on representative cases rather than testing all possible inputs, which is time- and effort-efficient. The TestGrid.io article provided a clear understanding of how to implement this method and why it is significant. For me, learning effective test methods like equivalence partitioning will make me more efficient in my coding, debugging, and software developing abilities, prepared for internships, projects, and software engineering positions.
Blog: https://testgrid.io/blog/equivalence-partitioning-testing/
From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend : created addBarcodeFrontend under our teams project to work on the scanner page.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/64bc3d4f720e6e8a69bafa709276beff820f719b : I added the scanner onto the frontend page, using a vue library to make it look good.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/200cac8ad4de849c3647b1223d9bc6f7075b8da2: I fixed the layout to how it ended up looking by the end of the sprint, as well as working on some other issues like fixing camera mirroring, and also added logos to the page.
As this project is the first time I have worked in a team adopting the scrum methodology, I was a little hesitant at first as to how well we would work together, with possible conflicting problems that would only lead to decreased productivity, but the way that it has turned out isn’t like that at all. An important part of the lack of disagreements comes from our collective trust in each other to produce the outcome that we envisioned from the issue that they were assigned. Our issue allowed us to split our team into smaller teams, focusing on separate issues which would eventually connect to fulfill our team’s original project goal. This delegation of tasks to each subteam has allowed us to focus on our own tasks, while also checking in with each other to see how the rest are doing. This frees us of the burden of trying to work over each other to accomplish one thing which I believe would lead to inefficiencies and conflicting ideas. This subteam workflow allows us to dedicate our time and effort to one topic while checking in on the other topics to stay updated and give feedback.
Although I just mentioned that the subteam system allows us to check in on each other and give feedback, this is somewhat untrue or at the very least an idealized version of what we are practicing. I do feel that I am working well in my subteam, and with my partner we are efficiently approaching our goal, however when it comes time to check in on the other teams, I feel as though I don’t get enough of an idea of the inner workings of what they’re doing to give good, constructive feedback. The same goes for my teammates giving me feedback. I think that is the tradeoff with this system though because it entrusts you with knowing what you’re doing, and I don’t think it’s as detrimental as it could be because each subteam at least has a partner that does give detailed feedback, sacrificing quantity for quality.
The perpetual learning pattern assumes there is always more knowledge to be known and your journey as a learner is never truly over. I selected this pattern because I think the pursuit of knowledge is important to sustain a continued expansion of knowledge and innovation, as well as satisfying a person’s internal sense of accomplishment and fulfillment. The point that this book tries to make about being a software apprentice is that you can become a master within your lifetime, but that doesn’t mean you stop learning. This pattern fits into the sprint because there was never a time I really felt like I fully understood a concept to a point where there wasn’t anything else I could learn by further investigating it or digging deeper. Even in established technologies or languages like HTML or CSS, there are a lot of things that many people may not know and working with it so much means I am more comfortable with it, but it doesn’t mean I am anywhere near mastering it, following this pattern of perpetual learning.
If I had thought of this pattern before the sprint started I would have gone into it more open-minded, knowing that anything I encountered would be surface level and that if I really wanted to I could go down a rabbit hole for each new thing I learned. There’s so much information out there that is almost impossible to get to, especially for me in the time of one sprint. I think to improve as an individual in future sprints, I could go out of my way to learn as much as I can so I can understand what I’m working on as best I can.
From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.
This week, our class learned about path testing. It is a white box testing method (meaning we do not actually run the source code) that tests to make sure every specification is met and helps to create an outline for writing test cases. Each line of code is represented by a node and each progression point the compiler follows is represented by a directed edge. Test cases are written for each possible path the compiler can take.
For example, if we are testing the code block below, a path testing diagram can be created: also shown below. Each node represents a line of code and each directed edge represents where the compiler goes next, depending on the conditions. Test cases are written for each condition: running through the while loop and leaving when value is more than 5 or bypassing it if value starts as more than 5.
I wanted to learn more about path testing, so I did some research and found a blog that mentioned cyclomatic complexity. Cyclomatic complexity is a number that classifies how complex the code is based on how many nodes, edges, and conditionals you have. This number will relate to how many tests you need to run, but is not always the same number. The cyclomatic complexity of the example above would be (5-5)+2(1) = 2.
Cyclomatic Complexity = Edges – Nodes + 2(Number of Connected Components)
The blog also explores the advantages and disadvantages of path based testing. Some advantages are performing thorough testing of all paths, testing for errors in loops and branching points, and ensuring any potential bugs in pathing are found. Some disadvantages are failing to test input conditions or runtime compilations, a lot of tests need to be written to test every edge and path, and exponential growth in the number of test cases when code is more complex.
Another exercise we did in class was condensing nodes that do not branch. In the example above, node 2 and 3 can be condensed into one node. This is because there is no alternative path that can be taken between the nodes. If line 2 is run, line 3 is always run right after, no matter what number value is. Condensing nodes would be helpful in slightly more complex programs to make the diagram more readable. Though if you are working with a program with a couple hundred lines, this seems negligible.
When I am writing tests for a program in the future, I would probably choose a more time conscious method. Cyclomatic complexity is a good and useful metric to have, but basing test cases off of the path testing diagram does not seem practical for complex codes and tight time constraints.
Blog post referenced: https://www.testbytes.net/blog/path-coverage-testing/
From the blog CS@Worcester – ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.