White box testing includes the use of all of a program’s internal structure to your advantage in the testing phase. A component of this internal structure that usually makes up a small percentage of the code body, but can contribute to the most amount of problem cases, are variable/data type declarations. Testing for these cases is called dataflow testing. In the blog, “All about dataflow testing in software testing”, by Prashant Bisht, the author details how dataflow testing would be implemented, and some examples of how it might look.

The implementation of dataflow testing, before any interaction with the code is done, is first executed with a control flow graph, which tracks the flow of variable definitions and where they are utilized. This type of organization allows for the first important internal component of dataflow testing, the tracking of unused variables. Removal of these unused variables can help narrow the search for the source of other problem cases. The second anomaly commonly testing for in dataflow testing is the undefined variable. These are more obvious than unused variables, since they almost always produce an error, due to the program relying on non existent data. The final anomaly tested for is multiple definitions of the same variable. Redundancy that can be introduced by this anomaly can lead to unexpected results or output.

Subtypes of dataflow testing exist, and are specialized to test different types of data. For example, static dataflow testing is the tracking of the flow of variables without the running of the tested code. This code only includes the analysis of the code’s structure. Another example, dynamic dataflow testing, focusing only on how the data relating to variables changes throughout the code’s execution.

To show how dataflow testing would work in practice, the author provided an example. This example concerns variables num1, num2, and num3. First, initialization of these variables is checked, i.e. if num1 is initialized as int nuM1 = some_int, the testing phase would catch this. Then, it ensures that the use of these variables don’t cause errors. This depends on program specifications, like if the program is meant to add each variable. The data flow is then analyzed, ensuring that operations including multiple variables are functioning properly. i.e. if num1 + num2 = result1, and num2 + num3 = result2, the dataflow phase would ensure that the operation result1 + result2 = result3 is functioning properly (though result3 being defined is a problem that would be handled by the first phase). The final phase is the data update phase, where the values of operations are verified to be what they’re expected to be.

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

In many software testing situations, white box testing, where the internal code of what is being tested is visible to the tester, and black box testing, where the internal code of what is being tested isn’t visible to the tester, are some of the most often used methods. However, integrating elements from both methods into a single testing method is slowly seeing more widespread use, also known as Gray box testing. In the blog “Exploring gray box testing techniques” by Dominik Szahidewicz, the author details different examples of gray box testing, and the benefits of those examples compared to the use of only white or black box testing.

Gray box testing has noticeable benefits that are absent from both white and black box testing. By the using the principles of white box testing (internal structure and design) and of black box testing (output without the context of internal structure), the testing process can be robust and able to account for any problem case.

A specific testing example where gray box testing can be implemented is pattern testing, where recurring patterns are leveraged to improve programs. With the use of gray box testing, the internal structure of the software can be related with the output to create more helpful and efficient test cases.

Another testing example where gray box testing can be implemented is orthogonal array testing, where data for testing is organized into specific test cases. This method is commonly used where exhaustive testing using every possible input is unreasonable because of the amount of inputs. By using the internal structure of the program and the outputs of the program, more efficient test cases can be created.

A basic guide as to how to implement gray box testing includes 4 steps detailed by the author. The first step of of the implementation is acquiring system knowledge. This includes documenting the internals available for use in testing, as well as the available documentation of outputs from the tested program. The second step is to define test cases according to known information and specifications. The third step is the use of both functional and non functional testing. The fourth step is to analyze the results of testing.

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

In complex programs, choosing valid test cases often means choosing from many different possible combinations of inputs to find the correct cases. Doing this could take an unnecessarily long time, slowing down the development process, and possibly causing some important cases can be missed. In the article, “Combinatorial testing: What is it, how to perform, and tools”, author Shanika Wickramasinghe explains the details of combinatorial testing, and how it solves the aforementioned problem.

Combinatorial testing involves using multiple combinations of variables for testing, with the goal of this being to verify which/how many inputs of test data, with this information then being used to design future tests. Some of the benefits of combinatorial testing include a larger coverage of possible test cases than normal testing, since multiple inputs are used, reduces the cost and effort of the testing process through the fact that it’s a faster method of testing, and avoiding redundancy, as combinatorial testing ensures that the same cases aren’t tested multiple times.

To better understand how combinatorial testing works, lets take a look at the author’s example. Say we’re trying to test a username and password functionality, and we decide we’re using combinatorial testing for this. Instead of each test case only including one username OR one password, like what would happen if normal testing was being used, each test case includes 1 username and 1 password from a pool of multiple usernames and passwords. For example, let the tested usernames be User1, User2, User3 and let the tested passwords be PW1, PW2. Then, test case 1 could be testing User1 and PW1, then case 2 would test User2, PW1, then case 3 would test User3,PW1, and so on. By doing this, every case would be covered with only 6 test cases, with the same case never being covered twice.

Other types and ways of implementing combinatorial testing are available as well. For example, the example listed above would be an example of manual combinatorial testing, where cases are manually selected from the pools of parameters, where in automated combinatorial testing, software or scripts are used to automate this process and create many test cases automatically. This is especially beneficial if there are many possible inputs, and manually picking each case would be too time consuming.

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

Unit testing is a very useful and secure way to stabilize the development process, but despite that, some developers forgo the testing process altogether. In Gergely Orosz’s blog entry, “The pyramid of unit testing”, he covers the relationship between the time it takes to notice the benefit of certain types of unit tests, and the experience of the coder designing the tests. For example, a coder with limited experience may look at a code body, see there are no obvious problem cases to be caught by unit testing, and forgo the process, while an experienced coder may see the same code and choose to design tests for it for reason that aren’t as obvious, and that are more based on experience and intuition.

Gergely details 5 different tiers of the Pyramid of Unit Testing Benefits, with the tiers lower on the pyramid listing benefits that can be noticed immediately, and tiers higher showing benefits that are only noticed in a later stage in development. The lowest tier are the benefits offered by tests designed to validate code changes. These tests are purely designed to validate recent changes, and make no attempt to catch future cases that might not be a problem now, showing an immediate benefit compared to not testing. The next tier up is the benefit of separating concerns in your code, which serves to somewhat force the coder to write clean code, since if a code is to be testable, that usually means that dependencies are declared upfront, leading the code to have an easier to follow structure. The next tier is the benefit of having an always up to date documentation. Well written tests can serve as useful documentation for code, and, unlike documentation of implementation code, these tests won’t get out of date. The second to last tier is avoiding regressions. If changes are made to a code body with no unit testing, than regression and conflicts are more likely to be introduced compared to a code body with tests. Designing tests helps avoid this by catching these regressions/conflicts before they become problems. The highest tier of the pyramid is using tests as a refactoring safety net. While testing is useful for validating small changes, it’s equally as useful for providing a stable environment for refactoring. When required to make large scale changes, a developer is more likely to be comfortable changing a code body with a large amount of coverage over many unit tests, rather than a code body with no means of catching problem cases.

From the blog My first blog by Michael and used with permission of the author. All other rights reserved by the author.

The planning process is an open source project is often created and monitored by the maintainers. This blog intends to go over the commonalities found by Safia Abdalla in open source planning mentioned in her article “Open source excursion: The poetry of planning”. I chose this topic because it relates to both the section in class where we went over licensing, which included open source licenses, and the section where we over different planning philosophies like scrum.

The first shared tendency between open source maintainers Abdalla lists planning with the intent to build excitement in the community that might hold many of your future contributors. Maximizing the outreach your plan gets among possible contributors and consistently providing updates when changes are made attracts attention towards your project, increases your chances of acquiring new contributors, and encourages existing contributors. Another common planning practice Abdalla lists is planning to prioritize. This planning method aims to optimize the process by which user requests and pull requests are fulfilled by distributing the responsibility among a chosen team. This allows for the efficient processing of requests, as well as allows many members of the team to get well acquainted with the user community and their hopes for the team’s project. The last 2 planning methods listed by Abdalla are planning to communicate and planning incrementally. Planning to communicate is a method of planning that, once a projects priorities and goals are well defined, aims to communicate those goals with the community. This leads to more exposure for the project, and possibly more support and contributions to it as well. Planning incrementally is a planning method where members of a team are mindful of the dynamic nature of the planning process, and communicate to the communities interested in the project the same thing, as to not mislead them.

Overall, these commonalities between open source planning all seem like good habits, and practices that would be useful for me to employ as a future open source project maintainer, and would also be useful as a contributor to open source projects to be aware of these tendencies so I can better align my work to the maintainers’ planning strategies. Planning with the intent to build excitement, along with being an effective planning strategy, sounds like it would also help for beginner developers to build a presence for themselves in the communities that are interested in the project that’s employing it.

https://increment.com/planning/open-source-planning/

Link to source blog:

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

Code visibility or the lack of it can introduce many problems that hinder the development process of a project. Some problems that can stem from poor code visibility include the misunderstanding of the function of the code or large portions of it, not defining possible conflicts well enough to avoid future features including them, and generally consuming an unnecessary amount of time. In Allison Wheeler’s blog, “Maximizing developer productivity with code visibility: A Complete Guide”, Wheeler goes over some other possible complications that could arise from poor code visibility, and presents tools like GitKraken as solutions to those complications. I chose this topic as it relates to the importance of clean code and other coding conventions we covered in class.

Wheeler presents the problems of poor code visibility as 3 main points; Lengthy prep time, Risk of conflicts or redundant code, and slow bottlenecked code reviews. The issue of length prep time arises when the function of the code or portions of it isn’t clearly stated and is left to the developer to figure out via time consuming methods, like trial and error. The issue the risk of conflicts or redundant code is related to the previous issue, where, because of time constraints and poor code visibility, the developer has an incomplete understanding of the code’s function, therefore not seeing how an added feature would be redundant or introduce a conflict. The issue of slow bottlenecked code reviews is also related to the misunderstanding of the code function, as when quality tests are conducted to test a change, a misunderstanding of the function of the unchanged code will result in an inaccurate quality test related to a new change. A solution to these problems is presented by Wheeler in the GitKraken DevEx platform, which is a technology with the aim of making the codebase of a project more accessible and decipherable.

Some of the features that improve code visibility include the creation of workspaces, which forgo the need for newly onboarded developers to access repos through the directory and organize all relevant repos in a single space. This removes possible confusion new hires could have with which repo to commit to. Another feature that improves code visibility is the launchpad feature, which organizes inter-repo requests, like merge, push and pull requests, into one space for the user to view. This feature allows developers to see which issues are being worked on and where the progress of the fixes for these issues are.

I can already tell that this information will be useful to me in my professional career, as many of these features resemble those that were in gitpod as we used it in class. Platforms like these seem very useful for streamlining the development process.

Link to source blog:

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

For my first blog I decided to talk about how individual contributors can best fulfill their role in the process of developing a project. This is relevant to the course material because the role of an individual contributor, which is mostly to improve the code and coordinating teams of other ICs, is a similar role the members of a development team would have in sprint.

The position that ICs occupy in most projects is a very impactful and influential position, aside from their ability to directly change the code. Despite their limited access to the management side of most projects, their proximity to the code gives them unique perspectives on the possible directions project could take, and what is and isn’t feasible to implement. In David Noel-Romas’ blog “An ICs guide to roadmap planning”, he introduces the problem of the IC who wishes they had comparable influence to the planning process of the project to their influence on the state of the code. Romas’ suggests several solutions to this problem, including identifying stakeholders and planning around the potential impacts the project will have on them through feedback and other means, making sure the management end of the team is aware of your visions for the project and when would be the most convenient times deliver updates and new features, and rationally bounding the work your team can do in the given amount of time, making an effort budget and working according to it. I think these solutions all take care of the problem of an IC who feels they aren’t offering enough input to the planning process well, and do so in a manner where the team dynamic isn’t compromised.

One of the reasons I think these solutions are effective is because they lend themselves well to the team structure of popular development philosophies. For example, if a development team is using scrum, there are points in the development process where an IC and their team can convene with the rest of the team members, like the sprint review, and offer their opinion on the direction and feasibility of the changes desired by other members of the team. The sprint review also allows the ICs to communicate with shareholders and assess. Since there are multiple sprint reviews per project, this allows many chances for an IC to offer their opinion on the planning process.

I can definitely see where this information will be useful in my professional career, as development philosophies like scrum are commonly used, and the input of an IC in the planning process can be essential to delivering a well made product.

Link to source blog: https://increment.com/planning/individual-contributors-guide-to-roadmap-planning/

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