Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Link to blog: https://www.computer.org/publications/tech-news/trends/application-security-testing

The whole semester we have been exploring various ways of testing code, namely styles that ensure the code works as it should. However, there is another aspect of testing we have not discussed yet; security testing. 

It is of the utmost importance to ensure that your software, database, website, etc. is safe from hackers and leaks. Security testing would help just that: making sure your system is unbreakable, or at the very least mostly protected from vulnerabilities and flaws. I think it is important to learn about this aspect of testing, which is how I came across Adam Stead’s article What is Security Testing? How to Check The Security Strength of Your Application.

Stead stresses the importance of security in software and also lists some important security testing techniques, such as vulnerability testing, black box testing, penetration testing, and more. There are many benefits of security testing besides identifying vulnerabilities. Some examples listed by Stead include protecting sensitive data, enhancing customer trust, and cost-effectiveness. Data leaks have been pretty common as of the past several years and it is a huge deal for those companies to lose their customers’ trust and their own reputation. With increased security comes increased trust, which is beneficial to both the business and the customer. 

Stead mentions some security testing best practices, and reinforces the idea of starting early and prioritizing risks. Security testing early on in development can help prevent flaws in your code, and you should continue to test throughout production. Prioritizing risks ensures that your important flaws don’t go unnoticed, and you fix your biggest holes before fixing the smaller ones.

Stead ends the article by discussing some attributes of effective security testing (thoroughness, continuity, scalability, etc.) and stresses the importance of checking the security strength of your software regularly.

I selected this article because this is a topic we have not discussed much in class even though it is still a very important part of software testing. This article emphasizes the key elements of security testing and how important it is to include it as a part of your testing regime.

The content of the resource was very informative and understandable for someone who already has a bit of understanding of software testing. An interesting thing I learned was about fax online, which is a method that businesses use to securely send documents. I did somewhat enjoy the article, it was informative, however I wish it included some examples of certain testing types. I expect to apply my newfound security knowledge to future jobs and software practices.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Our class discussed many code-driven testing methods, including Test Driven Development and Unit Testing. I thought it would be interesting to research what goes into performance testing, which doesn’t need coding to test but is still important to determine if there are any bottlenecks in your code. Many errors in our code go beyond whether it provides the correct output. If our software cannot function quickly and with many users, it doesn’t matter if our code functions if it doesn’t work in practice. The article “Performance testing, best practices, metrics & more” by Tricentis is a comprehensive look into how performance testing works and its role in software development. 

This article mainly provides the fundamentals of performance testing. It discusses why it’s important, the tests involved, what is measured, and a step-by-step process for ensuring your code functions correctly. It also discusses whether coding is necessary, when to conduct performance testing, and clears up performance and load-testing misconceptions. 

Reading the section on why performance testing is important had me finding a parallel to behavior-driven development because both focus on the user’s experience. If BDD provides an understanding of how the user is supposed to interact with the software during development, then performance testing is how users will interact with it when completed. If the users are stuck waiting for their application to load, find that it crashes often, or are unable to access it, then user experience will fall. That negative experience could lower revenue or reputation for the application’s company.

The section describing the testing methods highlighted how many ways you could poke and prod a system until it breaks. When I think of performance testing, I usually think of testing speed and user capacity, so seeing the other methods was enlightening. As I have not dabbled in performance testing, seeing the sequential steps to ensure speed and stability in our code was informative. It is vague enough for those new to performance testing to use it as a guideline. It was also interesting to learn that with agile methodologies at the forefront of software development, companies are looking for automation when doing performance tests to keep up with faster software development.

Overall, this article covered many aspects of performance testing, and those interested in learning would find it helpful. I plan to use performance testing to ensure users have a better experience, expose bottlenecks, and find where my code’s stability is weakest. 

The Article: https://www.tricentis.com/learn/performance-testing

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

Test-driven development (TDD) seemed odd to me when I was first introduced to it, much like the majority of others. The idea of writing tests before code felt weird in a way, as you write tests for nothing. However, the more I read about the benefits and how to properly apply TDD, the more obvious it was how useful TTD really is. Jacob Schmitt does a great job explaining TDD along with its benefits and best practices in his blog “Test-driven development (TDD) explained” (https://circleci.com/blog/test-driven-development-tdd/).

What is Test Driven Development?

Test-driven development is a software development approach where tests are written before code. It follows an iterative cycle: write a test, ensure it fails, write code to pass the test, and refactor. This means that a large amount of planning needs to go into the start of a project. Designing tests requires an understanding of what the feature you are adding should accomplish. This includes testing that things should pass when expected and fail when expected.

What Does Writing Tests First Accomplish?

As I mentioned before, it feels counterintuitive to write a test for code that does not exist. That is, until you understand the benefits of having tests. Tests are going to be required for any serious project. Having the tests written first will greatly increase your chances of finding bugs as early as possible. This also ensures that any refactoring does not break any existing functionality. This is great when working with a team, ensuring that everyone is on the same page and that changes made by anyone will be tested. TDD also ensures that all code that is written is tested. This greatly increases the code reliability and ensures functionality aligns with the user expectations.

Benefits of TDD

One of the most impactful benefits of TDD as a developer is the increased confidence that any changes you make in the code will have immediate feedback on if it passed the tests or not. This confidence extends to every developer on the team, as these tests ensure everyone’s code works as intended.

Catching bugs early can save a huge amount of time and money. It makes sense that testing code incrementally as it’s added is better than waiting until it is all developed to test. This also makes sure no code is ever added that isn’t tested. Meaning tests are being rushed near the end of deadlines, and potentially missing some.

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

For our final assignment for the course, we are being tasked to create a sort of activity similar to the activities we have been doing in class this semester for my software testing course. In working on this activity, we chose to write an assignment based on behavior driven development, using the Cucumber tool. As such, before we really get into the weeds of the assignment, I thought it would be a good idea to look into the tool myself and what behavior driven development looks like.

For today’s post, I’m looking at a blog post from Moisés Macero on The Practical Developer blog.

Firstly, behavior driven development is built for fostering communication and discussion around systems and how they should properly be working. Typically, the process is in three stages: discuss, capture, and write tests. We want to talk about what the requirements really should be between the product owner and developers, refine what our requirements and targets should be, then move forward to building the software and testing it.

What Cucumber does for this is introducing syntax, called Gherkin, to enhance the readability of tests even for people who don’t know how to read code. The syntax is styled in a format of ‘given’, ‘when’, ‘then’. You mark these test cases with keywords such as feature, scenario or example to accurately describe what the code should be doing and how it is being tested. One of the examples used in the article is the following:

  Scenario: Users solve challenges, they get feedback and their stats.
    Given a new user John
    When he requests a new challenge
    And he sends the correct challenge solution
    Then his stats include 1 correct attempt

Here, you can see that the syntax is (probably) easily readable and understandable even if you don’t have any software development experience. These statements are stored in .feature files, and act as sorts of definitions for tests.

For the actual testing, you apply these definitions by writing Cucumber expressions in a step definitions file. These are essentially files that not only test the code in a step-by-step approach, but also features readable headers for each function. Here’s an example of a couple of functions using Cucumber expressions (taken from this post in the same series):

    @Given("a new user {word} is created")
    public void aNewUser(String user) {
        this.challengeActor = new Challenge(user);
    }

    @When("they request a new challenge")
    public void userRequestsANewChallenge() throws Exception {
        this.challengeActor.askForChallenge();
    }

    @Then("they gets a mid-complexity multiplication to solve")
    public void getsAMidComplexityMultiplicationToSolve() {
        assertThat(this.challengeActor.getCurrentChallenge().getFactorA())
                .isBetween(9, 100);
        assertThat(this.challengeActor.getCurrentChallenge().getFactorB())
                .isBetween(9, 100);
    }

Cucumber supports a variety of different languages, and also supports testing frameworks such as JUnit, which means it is also very versatile and can be used alongside a testing driven development environment as well.

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

During this semester we have learned about many different testing techniques, some being a lot easier than others. One of the testing techniques that we have learned is called Stochastic Testing. Stochastic testing is a type of black box testing method in which random tests are conducted over time. These tests are performed by automated testing tools in order to see if the software can pass a large number of individual tests.

Another type of testing technique that we have talked about is Property-based Testing. Property-based Testing is very similar to Stochastic testing. In this testing technique, the testing is also automated. However, it isn’t just executing the tests that is automated, it is also generating the tests. While researching the topic, I came across an article called “What is Property-based Testing?” by Alex Robert. In this article, Robert states “Property-based testing automates that work for us. Test automation allows us to generate better tests with less work and less code, so that we can focus our effort on the less mechanical work developers excel at. Instead of writing tests with manually created examples, a property-based test defines the types of inputs it needs. In the example above with CommonPrefix, the input would be two strings. The property-based test framework will generate hundreds if not thousands of examples and feed them to your test function.” He talks about how property-based testing can create a ton of different examples for your test function in order to help you test your program.

In this article, Robert also talks about input generators and what they do. A generator is a function that returns an instance of a given type from a source of randomness. These generators are great for randomly creating new inputs for the test function. However, they are only efficient if the generators have a good framework in order to help uncover more issues with the code. Robert gives a list of qualities that he thinks would make a good generator. His qualities include: a generator should be fast, a generator should be deterministic, a generator should not waste randomness, and a generator should cover the code under test. Most of these property-based testing frameworks come with a built-in generator which can be extremely helpful for testers, depending on the type input parameter. I really enjoyed reading this article as looking at all of the examples given by Robert helped my understanding of the topic. I know that if I ever need to use this type of testing technique, I will definitely use this article as a reference.

Link: https://www.mayhem.security/blog/what-is-property-based-testing

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

The blog post, “Unit Testing Best Practices: 9 to Ensure You Do It Right” focused on highlighting important habits and practices that testers must utilize to increase efficiency and effectiveness. I chose this blog post because as we continue to learn different software testing strategies in class I think it was important to highlight some important aspects that could be utilized as a tester so we can make sure we incorporate these in the future. I thought that this blog highlighted good practices that were covered in class and even added some more.

The blog presented recommendations and strategies for effective unit testing, catering to developers aiming to streamline their testing workflows.The blog begins by explaining the significance of unit testing in software development, highlighting its role in detecting bugs early, ensuring code reliability, and facilitating code maintainability. It emphasizes the importance of adopting a systematic approach to unit testing to maximize its benefits. The blog advocated for writing clear, concise, and focused tests that target specific functionalities or units of code. Emphasizing readability and maintainability, the blog suggests using descriptive test names and organizing tests into logical groups. The blog also addresses the importance of test automation in modern software development. It advocates for automating unit tests to expedite the testing process and ensure consistent test coverage across code bases. By integrating automated tests into continuous integration pipelines, developers can detect regressions early and maintain code quality throughout the development lifecycle.In addition to automation, the blog stresses the significance of test isolation and dependency management in unit testing. Techniques such as, mocking and dependency injection are recommended to isolate units under test from external dependencies. The blog also touches upon strategies for handling test data effectively, including techniques like parameterized tests and test data factories. By managing test data efficiently, developers can enhance test coverage and minimize test redundancy.

After reading this blog post, I believe that I am now more confident and informed about how a software tester should go about testing strategies. Being able to know good testing practices will be beneficial so I can focus on utilizing the skills within my own work. I found it interesting how most of the practices that were being mentioned in the blog were very simple. This makes it even easier to understand and incorporate these rules as they will be easy to remember and become a standard foundation whenever I have to think about writing tests for a project. 

https://www.testim.io/blog/unit-testing-best-practices

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.