Security testing is an important part of software testing, it makes sure to find any weaknesses in the software and if our data is protected from intruders. Security testing is important because it helps us ensure that our software has no weak spots and that our data and information are safe. There are so many versions of security testing like password cracking, penetration testing, and vulnerability. Those three topics are some of the main ideas of security testing and understanding the importance of keeping personal information safe. Password cracking testing is when the system identifies weak passwords and helps make sure that people use stronger passwords. Penetration testing is done by assessing the system by using different techniques, the purpose of it is to protect the important data of the users who don’t have access to the system. Vulnerability testing is used to identify the weakest attributes in the system that can be used by destructive software. A lot can cause the software to be vulnerable like a bug in the software, wrong software testing, and the presence of a bad code. 

I chose this topic because security testing is important in our software testing class and this blog has a lot of information on how it works. It’s important to know more about how our private data is saved from hackers and how safe our software is. I believe that this helped me learn more about security testing like how penetration testing uses different techniques like the black box and white box testing method to detect any vulnerabilities in our software. Security testing is to make sure that applications are not able to leak private information and can handle a threat like hackers. I already knew before reading how important it is for our information and making sure that our passwords are not easy for hackers to figure out but I thought penetration testing was interesting to learn about because I didn’t know it used so many different techniques to find any vulnerabilities. Security testing is about keeping our information safe as well as our software safe from any intruders and I believe that this blog gave the best explanation and information about it.

https://www.idexcel.com/blog/tag/security-testing/

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

Behavior-Driven Development (BDD)

Behavior Driven development is an approach where the focus is set on the behavior of an application for the purposes of a business. This focus is to find a common ground between developers, quality assurance teams, and business professionals. Common ground is found by defining behaviors that are written in plain language, allowing everyone to understand and agree upon the software’s behavior.

BDD Process

Behavior driven development begins with defining behaviors in “feature files” which are used throughout the development process. Behaviors are straightforward statements that outline a specific process in a predetermined format.

Behaviors are written in a language called Gherkin, which use simple words such as “Given”, “When”, and “Then.” An example behavior would be, “Given the user enters an incorrect password, When they click the login button, Then they should be prompted with an error to reenter their password.” These behaviors are turned into tests with tools that check if the software behaves as intended. Because everyone is involved in this process, and agrees on the final product, confusion can be avoided.

Advantages to BDD

Behavior driven development leads to advantages that would otherwise be lost with other development approaches. A key advantage with BDD is better communication and collaboration. This is due to the nature of BDD as everyone from business, to quality assurance, to developers, meet together and plan everything. Because there is better communication, requirement understanding also increases. This is because requirements are explicitly defined, and everyone agrees what should be done. Due to the increase in requirement understanding, testers are made aware exactly what requirements should be tested. Ultimately the chances for the final product to be different than what was intended is less, saving time and effort.

Disadvantages to BDD

Because BDD is different from other development approaches, adopting the practice can be difficult. This is because teams are used to working amongst themselves, then meeting with the other teams once a final product, or an iteration of the final product has been completed. Waiting until a product has finished development before meeting the other teams can lead to wasted time and effort because what is actually delivered may be different than what the business team intended. Another reason why BDD can be hard to get used to is the overemphasis and learning curve with the tools necessary for BDD. Teams can get off track because they get caught up in learning Gherkin syntax and other tools.

Conclusion

This article was chosen because topics were easy to understand with the use of real world examples. Once past the learning curve, behavior driven development seems like a useful approach that fosters strong collaboration and communication. I was unaware of tools like Gherkin and Cucumber that are used to process the feature files, so learning about them was interesting. This approach is unlike others I have seen in the past; however, I am curious about how is all works. I will be looking into these tools in the future.

Resources:

https://www.browserstack.com/guide/what-is-bdd

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

The last few weeks of class have all been about Test Driven Development. Test Driven Development is when you use tests in order to guide you into developing software. According to a website called martinfowler, there are three main steps that we follow repeatedly. Those steps are:

1. “Write a test for the next bit of functionality you want to add.
2. Write the functional code until the test passes.
3. Refactor both new and old code to make it well structured.”

Essentially what this means is you create a list of things that you want included in your test, then you create a test for just one of those items. Once you create the test, you implement the code in order to get the test to pass. Once it passes, then you move on to creating the next test and getting that test to pass. If it causes the previous test you fail, you refractor until all of the current tests pass, then you repeat until all of the items you need are done. I personally find writing the test first to be a lot easier than writing the code first. That way, while you’re creating the code, you have an example to look back at so you know exactly what you want it to do. On top of that, focusing on one part of the code at a time makes it a little easier to develop the code without making mistakes, as you aren’t focusing on the entire program at once, just one small part at a time. According to the article, this form of development has two main benefits. It says “Most obviously it’s a way to get SelfTestingCode, since we can only write some functional code in response to making a test pass. The second benefit is that thinking about the test first forces us to think about the interface to the code first. This focus on interface and how you use a class helps us separate interface from implementation, a key element of good design that many programmers struggle with.” I chose this article as my source because I thought it did it a really good job explaining what to do step by step so you don’t get confused. On top of that, it explains the benefits and consequences of this method and how to avoid/achieve them. This article helped me further understand Test Driven Development and why it is useful.

Source: https://martinfowler.com/bliki/TestDrivenDevelopment.html

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, “The 3 Biggest Software Testing Mistakes” from Daniel Knott focused on highlighting vital mistakes that software testing groups frequently come upon in their testing strategies. 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 mistakes that could be made as a tester so we can avoid these in the future. 

 The first mistake that Knott highlighted was the mistake of not asking enough questions. When you are working as a tester your first job should be to ask as many questions during the development phase of the product as possible. This will allow you to verify that the product will work as intended for the customer. These questions should be highlighting product features, limitations, etc. The second mistake is trying to automate everything. Automation if done right can be very helpful however there are scenarios where automation can do more harm than good. Knott says that many teams mistakenly aim to automate everything, often driven by those unfamiliar with automation’s true benefits. Some parts of the code that are still in development, may not be ready for automation, while other areas will require detailed quality checks that automation cannot provide. Due to this, a risk assessment and informed questioning should precede test automation while working. Once suitable areas for automation are identified, decisions on the level of automated checks should be made by the team.The third mistake in software testing is reusing the same test data repeatedly. Software testing heavily relies on data such as text, images, or voice, and system configurations. Reusing test data compromises its integrity. The system’s state or configuration may change between tests which could affect results. To effectively test an application, the development team must define and generate appropriate test data. Generating test data can be complex, depending on the system’s intricacy and technologies involved. Ideally, scripts can create test data for specific tests, allowing for deletion or reset afterward. The conclusion of the blog post has Knott describing how mistakes can be good as they are a part of growing as a software tester. The best thing we can do is to be transparent about our mistakes to allow for a culture of learning.

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 identify common mistakes will be beneficial so I can avoid doing those mistakes in my own work. I found it interesting the fine line between automation since it can be both beneficial and harmful depending on just what you are working on. This is why as I read it is best to be left to a team decision as automation has its own list of pros and cons.

https://shiftsync.tricentis.com/testing-strategies-methodologies-42/the-3-biggest-software-testing-mistakes-95

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.

For this week’s blog post, I decided to discuss the article “Object-oriented Testing in Software Testing” by Mitali Varatiya. I chose this article because it compliments the object oriented testing topic in the syllabus. This article discusses what object oriented testing is, how you can develop test cases with object oriented testing, how to implement object oriented testing, different techniques with implementing object oriented testing, and challenges associated with the implementation of object oriented testing.

The author first discusses how object oriented testing can be done at multiple levels of a program, for example the algorithmic, class, cluster, and system levels. “Object Oriented testing can be performed at different levels to detect the issues. At the algorithmic level, a single module of every class should be tested. As discussed earlier, testing of classes is the main concern of the Object Oriented program. Every class gets tested as an individual entity at the class level. Generally, programmers who are creating the classes are involved in testing. Test cases for Object-Oriented Testing in Software Testing can be constructed based on the requirement specifications, programming language, and models.” The author then goes on to discuss how, at the class level, testing focuses on the integration of individual classes and their interactions with other classes in the program. “Once class-level testing is done, Cluster level testing will be performed. Cluster-level testing is the integration of individual classes. The main purpose of doing integration testing is to verify the interconnection between classes and how well they perform interclass interactions.” The author also discusses some ways in which object oriented test cases can be developed.

The author states that conventional methods of developing test cases are sufficient for creating object oriented test cases, but there are some features that may be helpful with object oriented testing that might be looked over when using more typical techniques on their own. “The following points should be considered while creating test cases for object-oriented environments. Which class is going to be tested should be mentioned properly within the test cases. What is the purpose of using particular test cases? What external pre-condition needs to be conducted while performing the test case? All the states should be specified for testing.” The author then discusses some of the challenges with implementing object oriented testing.

Some challenges that are associated with implementing object oriented testing as described by the author are the impossibility of dynamic testing, the necessity of different types of testing to be implemented to properly test the program, and the difficulties associated with the implementation of testing for inheritance in object oriented programs.

Article: https://www.scaler.com/topics/software-testing/object-oriented-testing-in-software-testing/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In a recent episode of the Python Test Podcast, titled “TDD: Don’t Be Afraid of Test-Driven Development”, developer Chris May shared his journey with Test-Driven Development (TDD).  If you’re a programmer interested in improving your code quality and development process, this blog post offers a summary of the discussion and explores why TDD is a powerful technique.

What is Test-Driven Development?

TDD turns the traditional coding process on its head. Instead of writing a large chunk of code and hoping it works, you start by defining the precise behavior you expect from a piece of code. These expectations are written as tests, and they will initially fail because the code itself doesn’t exist yet.

Key Concepts and Benefits of TDD

The core of TDD is the “Red-Green-Refactor” cycle:

1. Red: Write a failing test that reflects a desired feature or behavior.
2. Green: Write the simplest possible code to make the test pass.
3. Refactor: Improve the code’s design and readability while ensuring all tests continue to pass.

This approach offers several key benefits:

• Improved Code Design: By focusing on functionality first, TDD encourages you to create well-structured, modular code.
• Less Debugging: Catching errors as early as possible through tests greatly reduces time spent troubleshooting complex issues later on.
• Increased Confidence: A comprehensive test suite provides a safety net, allowing you to make code changes with less fear of breaking existing functionality.
• Living Documentation: Tests serve as a clear explanation of how your code is intended to work.

Overcoming Challenges with TDD

As Chris May discussed in the podcast, TDD requires a change in how you think about coding. Here are some common concerns and how to address them:

• “It feels too slow”: It’s true that initially, TDD might seem to slow you down. However, the time saved from reduced debugging and a more solid codebase easily makes up for it in the long run.
• “I don’t know how to write tests”: Learning to write effective tests is a skill in itself. Start simple and leverage online tutorials and resources specific to your programming language.

Resources for Learning TDD

• Books:
  • “Test-Driven Development by Example” by Kent Beck
  • “Growing Object-Oriented Software, Guided by Tests” by Steve Freeman and Nat Pryce
• Online Tutorials: Explore the numerous tutorials and guides tailored to different programming languages.

Conclusion

While it may have a learning curve, Test-Driven Development offers a structured and rewarding approach to software development. By embracing TDD, you can write cleaner, more maintainable, and ultimately more reliable code.

Podcast link: https://podcast.pythontest.com/episodes/76-tdd-don-t-be-afraid-of-test-driven-development-chris-may

From the blog CS@Worcester – Site Title by Iman Kondakciu and used with permission of the author. All other rights reserved by the author.

A Path to Enhanced Development

Code reviews are an essential practice in software development, pivotal not only for error detection but also for fostering an environment of continuous learning and collaboration. When executed effectively, they can significantly enhance both individual skills and organizational efficiency.

The Foundation of Effective Code Reviews

An effective review scrutinizes how the proposed changes integrate with the existing codebase, focusing on clarity, correctness, and adherence to established coding practices. Reviewers should critically evaluate the necessity and implementation of the changes, suggesting more granular modifications if the changes are too expansive.

The Art of Communication

The tone in which feedback is delivered can dramatically influence team dynamics. Constructive feedback should be presented through open-ended questions and thoughtful suggestions rather than direct criticism. This approach encourages a collaborative atmosphere and reduces the likelihood of defensive responses. It is essential to recognize the efforts of developers and maintain an empathetic and supportive tone throughout the review process.

Decision Making in Reviews

The decision to approve changes, request modifications, or leave comments unresolved should be clearly communicated. Reviews should be flexible, allowing for follow-up changes when necessary, with reviewers making themselves available for quick re-assessments to accommodate urgent updates.

From Written Reviews to Direct Conversations

When extensive feedback from a review indicates potential misunderstandings, switching from written comments to direct conversations can be beneficial. This transition can help clarify issues more effectively and expedite the review process, especially in cases of complex or contentious changes.

Navigating Challenges in Remote Reviews

Remote and asynchronous reviews present unique challenges, particularly when reviewers are in different time zones. To mitigate these challenges, it’s advantageous to schedule discussions during overlapping working hours or to utilize video calls, enhancing clarity and collaboration.

Cultivating a Supportive Review Culture

Organizations should strive to create a culture that values thorough and empathetic code reviews, recognizing them as crucial to the development process. Continuous improvement in review practices should be encouraged, and engineers should feel empowered to both contribute to and learn from each review session.

By prioritizing effective communication, thoughtful feedback, and continuous improvement, organizations can make code reviews a cornerstone of development excellence, leading to higher quality software and more productive teams.

Integrating Newcomers through Code Reviews

For new team members, adapting to a new codebase and review process can be daunting. A supportive review culture is crucial in easing this transition. Experienced reviewers should use the initial code reviews to not only evaluate the technical aspects but also to mentor and guide newcomers. By explaining alternative approaches, pointing to coding guidelines, and maintaining a positive tone, reviewers can help new engineers integrate effectively while maintaining high standards. This practice ensures that new developers feel welcomed and supported as they navigate their initial contributions to the team.

Based on this blog link: https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

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

Although I wasn’t present for the class in which code reviewing was introduced, it seems like a pretty simple topic to understand. It consists of… well, reviewing code; the only thing is, it can’t be done alone. Code review’s core and effectiveness lies in cooperation with others, where two or more people are required to even attempt code review. Of course, you can literally “code review,” as in, you review your own code but this refers to something more. 

What does it mean to review when it comes to code? Well, everyone is human, for the most part, and humans are prone to mistakes; and in the case of developers, these end up as bugs, errors, and everything in between. Code review allows others to look through one’s code to find these mishaps that the original developers may have missed or overlooked. I am also human and have had many cases in which I get stuck and have to ask a friend to look through my code just for them to point out something so simple and easy to spot yet I managed to miss. 

Code reviews encompass not only the spotting of mistakes but also the improvement of overall code, so as to have a better, more-refined end product before merging and such. This improvement of overall code includes but is not limited to structure, cohesion, cleanliness, and readability. Clean code is something that I hadn’t heard of until somewhat recently, so that aspect of my code from the past and even now can be improved upon heavily and would be greatly appreciated. 

Code reviews are usually chances for the one being reviewed to correct their mistakes and improve their code but there is also an opportunity for the reviewer to learn. The reviewer may encounter new techniques, solutions, and perspectives through this process, ultimately benefiting both reviewer and reviewee. 

One of the major downsides to code review is that the length and content of them depends entirely on the length of the code; and code can get to some very large sizes. The time spent reviewing especially large code could potentially be put into the current project, workflow, or what have you. 

As someone who is not so confident in their coding skill and proficiency, I believe that code reviews are great opportunities to learn and improve, which will in turn improve my confidence in my skill. There is much to be gained with code review and the downsides seem to only apply to much larger projects; so as a student and novice developer, they will be great to implement to my learning.

https://medium.com/@priyanthinisivasubramaniyam/everything-to-know-about-code-review-as-a-beginner-2a360cdd89ca

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