Category Archives: Week-17

BDD

In a previous blog post, I had talked about Test Driven Development, or TDD. Today, I’m going to introduce a different approach that aims to almost rectify the potential shortcomings of TDD, that approach being Behavior Driven Development, or BDD for short.

BDD can be described  as “a collaborative approach to software development that aims to bridge the communication gap between business and technical teams” with the core idea of creating a “shared understanding of the software’s intended behavior using concrete examples” (Test Guild).

“The process revolves around writing scenarios using the Given-When-Then format, which describes the preconditions (Given), the action or event (When), and the expected outcome (Then).” This is a format that can be easily understood regardless of what people specialize in. TDD involved writing test cases and coding based on those test cases which mainly involved the developers, testers, and those that are closely linked to the programming and technical development. BDD, on the other hand, can involve the non-technical, such as stakeholders and those from other departments on top of the developers and testers. It can be simply put as, “compared to test-driven development (TDD) which is developer-centric, BDD is a team-wide practice” (Test Guild).

The Given-When-Then format allows for less misunderstanding when it comes to what is required of the software. Developers may use names that are short and to the point to describe something but it doesn’t match the behavior that is desired. The same developer or others that have just started working on the code may simply go along with it not realizing that what is desired of the code is something more or something else entirely. By using this format along with full sentences describing exactly what the code should do, there will be less room for error, misunderstanding, and time wasted fixing the code down the line.

One of the difficulties that seems to arise with the implementation of BDD is the inclusion of implementation details in scenarios. This is because scenarios are meant to focus solely on behavior. Including implementation details is basically attempting to set something in stone; scenarios describe what is desired of the code and how developers achieve that can change many times. It ends up adding more work every time that detail has to be met or changed.

BDD is an interesting topic, it seems to be a direct upgrade from TDD but that isn’t always the case. Take a classroom environment for example, it’s a bit odd as we (the students) could be considered developers but what about the other roles in the process? Would the professor act or technically be a stakeholder? It’s a process that can be learned at any point but it seems it can be only truly put into practice in a real world environment. We can certainly take aspects of BDD into mind, the Given-When-Then format and basing development around desired behaviors seems to have little to no downsides for any situation. 

Source: https://testguild.com/what-is-bdd/

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

Positive vs Negative Testing

The blog post “Software Testing Basics: Positive vs. Negative Software Testing” explores two fundamental approaches in software testing: positive and negative testing. I chose this blog post because this semester we have been taught a variety of software testing techniques and strategies. From this blog post, it has categorized some of the techniques we have learned into one of two categories mentioned, positive or negative testing. I found this useful as it also allows us to know easily when to utilize certain techniques for certain scenarios.

The blog begins by describing the significance of software testing in ensuring the quality and reliability of software applications. Testing is important not only to detect bugs but also to enhance user experience and maintain credibility. Positive testing involves validating the software’s expected behavior under normal conditions. Test cases are designed to verify that the system functions as intended when provided with valid inputs. This method aims to affirm that the software performs its functions accurately and efficiently. By executing positive tests, developers can gain confidence in the system’s reliability and usability. On the other hand, negative testing focuses on the software’s ability to handle invalid or unexpected inputs and conditions. Test cases are designed to provoke errors, exceptions, or failures within the system. This approach aims to uncover vulnerabilities, defects, or unforeseen scenarios that may compromise the software’s performance or security. Negative testing is crucial for identifying weaknesses and enhancing the robustness of the software.The blog emphasizes the complementary nature of positive and negative testing. While positive testing validates the correctness of the software’s intended behavior, negative testing uncovers potential issues that might have been overlooked. Together, they provide comprehensive test coverage and contribute to the overall quality assurance process.Moreover, the blog discusses various strategies and techniques for conducting positive and negative testing. For example, positive testing involves scenarios such as input validation, boundary testing, and functional testing, where the focus is on confirming the expected outcomes. While, negative testing encompasses techniques like boundary value analysis, error guessing, and stress testing, aimed at challenging the error-handling capabilities of the code.

After reading this blog post, I feel like I would be better prepared for software testing or quality assurance. The descriptions of positive versus negative testing in my opinion were very helpful in solidifying my knowledge on software testing as well as teaching me new aspects of it. As previously mentioned, the blog post was beneficial for teaching me to know when to utilize certain techniques for various scenarios.

https://www.testmonitor.com/blog/software-testing-basics-positive-vs.-negative-software-testing

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.

Java vs. Python: Choosing the Best Language for Selenium Testing

Introduction:

In our final group assignment, we explored testing in Python, and just last week, I blogged about using Selenium. Sticking to this testing theme, it’s intriguing to compare Java and Python, two powerful languages widely used with Selenium for automated testing. Drawing on insights from a Testrig Technologies article, this post examines which language might be better suited for Selenium testing, offering perspectives that could influence our approach to future projects.

Summary:

The Testrig Technologies article delves into the strengths and weaknesses of using Java and Python with Selenium for automated web testing. It notes that both languages have robust frameworks and libraries to support Selenium but highlights Python for its simplicity and readability, making it generally easier for beginners to learn and implement. Java, on the other hand, is praised for its performance and extensive community support. The article provides a balanced view, suggesting that the choice depends largely on the specific needs of the project and the familiarity of the team with the language.

Reason for selection:

I chose this article because it ties directly into our recent assignments and discussions around testing in Python, and my personal exploration of Selenium. Understanding the comparative advantages of Java and Python in this context is highly relevant, not just academically but also for practical application in future software development roles.

When comparing testing with Selenium using Java and Python, several key similarities and differences emerge, each influencing how testers might choose one language over the other. Both Java and Python support Selenium with extensive libraries and frameworks that facilitate browser automation, which means testers can script complex user interactions on both web and mobile applications using either language. They also integrate well with testing frameworks and tools like TestNG and PyTest, respectively, allowing for comprehensive test suites and reporting features.

Personal reflection:

Reflecting on the article, I appreciated the straightforward comparison between Java and Python. Last week’s experience with Selenium and Python was quite enlightening, especially seeing how straightforward scripts can be with Python’s syntax. This article reinforced my understanding and opened up considerations on when Java might offer advantages, particularly in scenarios requiring robust performance or when integrating into larger, more complex systems.

Future practice:

With this knowledge, I feel better prepared to choose the appropriate language for future projects involving Selenium. Depending on the project’s complexity and the team’s expertise, I can make informed decisions on whether to lean towards Python for its ease of use or Java for its powerful capabilities and performance.

Conclusion:

Choosing between Java and Python for Selenium testing doesn’t have a one-size-fits-all answer. Both languages offer unique benefits that can be leveraged depending on the project requirements. As we continue to develop our skills in automated testing, understanding these nuances will be key to delivering high-quality, robust software

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.