Category Archives: CS-443

Define-Use Testing

A little while ago we learned how Define-Use Testing works as well as how to use it ourselves. However at the time, it still confused me a bit and I wasn’t really sure what it was used for. After reviewing the previous work we’ve done and coming back across this topic, I realized that I still didn’t fully understand what was going on. I decided to look further into it and to do some research in order to understand it more. As a result, I found a website called testsigma which I believe does a really good job at explaining what Define-Use case testing is, its advantages and its disadvantages, and when to use it.

With the website’s help, I’m going to explain everything that you need to know about Define-Use case testing in order to understand it and to know when to use it. As for what a use-case itself is, the website states “The concept of a Use Case can be likened to a real-life scenario in which users and their objectives are present. A Use Case outlines the events unfolding when these users interact with the system to achieve their objectives. The Use Case allows for a thorough understanding of the overall behavior and functionality of the system from the user’s point of view.” Essentially this means that a Use Case shows all of the decisions that were made while the user was trying to achieve their outcome, allowing you to understand all of the behavior and functionality from the user’s perspective. Use Case Testing was designed to make sure that the system that is currently being tested meets all of the expectations. It essentially simulates different real-life scenarios in order to make sure the software does everything that it is supposed to. While the website gives a lot of different advantages and disadvantages of Use Case testing, I’m just going to list a few. Some advantages include helping to identify and validate the functional requirements of a system or software, explaining how the software will be used in real-world scenarios, and helping uncover potential defects. Some disadvantages include it could be time-consuming and require a lot of effort, it may not cover all scenarios which could leave to gaps in test coverage, and it relies on the accuracy of the use case documentation. As for when to use Use Case testing, the website gives a checklist which I found to be extremely useful in my understanding of when to use it. I’m really glad I found this website as it further helped my understanding of the topic, and it has helped me prepare for my final exam. The checklist states:

“1. Review the software requirements, specifications, design documentation, and use case scenarios. 

2. Identify the possible scenarios related to the use case. 

3. Determine the functional requirements of the use case. 

4. Create test cases for each possible use case scenario. 

5. Define the expected results of the use case scenarios. 

6. Execute the test cases and compare them with the expected results. 

7. Retest the fixes after identifying failed test cases. 

8. Check for exceptions and errors for each use case scenario. 

9. Verify compliance and security requirements for each use case scenario. 

10. Monitor the system’s overall functionality across use scenarios. 

11. Validate the overall system performance with user expectations”

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.

Test-driven Development

Test-driven development is a software development approach that emphasizes writing tests before writing the actual code. By using this technique, developers ensure that their code is thoroughly tested, reliable and maintainable. Test driven development typically consists of three main steps, writing a failing test, writing the minimum code to pass the test, and then refactoring the code while ensuring that all tests still pass. In more detail of the three cycles, one is writing a failing test. Developers start by writing a test case that defines the desired behavior of the code. Since there’s no code yet, this test will inevitably fail. Write the Minimum Code: After writing the failing test, developers write the minimum amount of code necessary to make the test pass. The goal is to write just enough code to satisfy the requirements of the test. Refactor the Code: Once the test passes, developers refactor the code to improve its design, readability, and performance. Refactoring ensures that the code remains maintainable and scalable over time. Some benefits of using test-driven development are improved code quality. TDD encourages developers to write modular, well-structures code that is easier to understand and maintain. Faster development cycles. By writing tests upfront, developers can catch bugs early in the development cycle, leading to faster iteration cycles.

Another benefit is enhanced code coverage. TDD ensures test coverage, reducing the likelihood of undetected defects in the codebase. Increased confidence. Developers have greater confidence in making changes to their codebase without introducing regressions. The last benefit is better collaboration. TDD promotes better collaboration between developers, testers, and stakeholders by providing a shared understanding of the system’s behavior. Some practices for test-driven development include keeping tests simple. Write simple, focused tests that verify one aspect of the code’s behavior. Refactor Regularly: Refactor your code continuously to keep it clean, concise, and maintainable. Automate Tests: Use automated testing frameworks to run tests frequently and detect regressions early. Write Meaningful Tests: Ensure that your tests are descriptive and provide clear feedback when they fail. The last one is seeking feedback. Get feedback from peers and stakeholders to validate your tests and ensure they accurately reflect the desired behavior. Test-driven development is a powerful software development technique that promotes code quality, reliability, and maintainability. By adopting TDD principles and best practices, developers can write better code, deliver features faster, and build more robust software systems. I chose this source because it goes into detail explaining everything about Test driven development and what it does, why it is important for developers.

References.

https://testdriven.io/test-driven-development

https://www.browserstack.com/guide/what-is-test-driven-development

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

Test Driven Development

For this week’s blog post, I decided to discuss the article “A Practical Introduction to Test Driven Development” by Luca Piccinelli. I chose this article because it compliments the test driven development topic in the syllabus. This article discusses what test driven development is, the costs of using test driven development versus not using it, and gives some examples of how test driven development is done.

The author of this article is very blunt about their feelings towards test driven development. “These days you read a ton of articles about all the advantages of doing Test Driven Development (TDD). And you probably hear a lot of talks at tech conferences that tell you to “Do the tests!”, and how cool it is to do them. And you know what? Unfortunately, they are right (not necessarily about the “cool” part, but about the useful part). Tests are a MUST!” As mentioned by the other, some of the advantages that come with using test driven development are you write better software, you have more protection from breaking the whole project when new features are introduced, your software is self documented and you avoid over engineering. However, there is a glaring issue with using test driven development: the cost.

The author discusses the costs of using test driven development versus not using test driven development in good detail. The main differences in the costs are not in terms of value but in timing. “It [test driven development] costs a lot! Probably someone is thinking “but it costs even more if you don’t do the tests” — and this is right, too. But these two costs come at different times: you do TDD ➡ you have a cost now. You don’t do TDD ➡ you will have a cost in the future.” The author feels the best way to reconcile this problem is to do what comes naturally for the project’s development. “The most effective way to get something done is doing it as naturally as possible. The nature of people is to be lazy (here software developers are the best performers) and greedy, so you have to find your way of reducing the costs now. It’s easy to say, but so hard to do!” The next section I will be covering discusses how the author feels test driven development should ne implemented.

The author feels that the best way to implement test driven development practices would be to use a top down approach. “[A top down] approach is the best friend of over-engineering. You typically build the system in order to prevent changes that you think will come in the future, without knowing if they actually will. Then when some requirement changes, it typically happens in a way that doesn’t fit your structure, no matter how good it is. For me the key to drastically reducing the immediate cost of writing with TDD has been to take a top-down approach”

Article: https://www.freecodecamp.org/news/practical-tdd-test-driven-development-84a32044ed0b/

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.

Embracing Test-Driven Development for Quality Software (Week-13)

In the evolving world of software development, methodologies that enhance code quality and project efficiency are highly prized. Test-Driven Development (TDD) stands out as a pivotal methodology, advocating for tests to be written before the actual code. This approach is detailed compellingly in the Semaphore article “Test-Driven Development: A Time-Tested Recipe for Quality Software,” offering valuable insights into the TDD process and its benefits for developers and projects alike.

TDD is anchored in a cyclic process known as “red-green-refactor.” Initially, a developer writes a test for a new function, which fails (red stage) because the function isn’t implemented yet. Then, minimal code is written to pass the test (green stage), focusing on functionality before perfection. The final step involves refining the code without altering its behavior (refactor stage), enhancing its structure, readability, and performance.

The significance of TDD in software development cannot be overstated. It promotes incremental development, allowing for manageable progression and easier troubleshooting. The necessity to write tests first compels developers to deliberate on code design and interface upfront, leading to cleaner, more maintainable code. Additionally, TDD provides a safety net, enabling developers to modify or add new features with the confidence that existing functionality remains intact, as verified by the tests.

Despite its advantages, TDD is sometimes viewed skeptically, with critics pointing to its perceived complexity and the upfront time investment in test writing. However, the Semaphore article counters these arguments by highlighting the long-term benefits: reduced debugging and maintenance time, deeper codebase understanding, and ultimately, a more streamlined development process. The initial efforts pay off by preventing future headaches, underscoring TDD’s efficacy in building robust, high-quality software.

TDD marks a paradigm shift in software development philosophy. It prioritizes a meticulous, forward-thinking approach to code creation, where quality, efficiency, and thoughtful design are paramount. The practice of writing tests before code not only ensures functionality but also fosters an environment of continuous improvement and refinement.

The Semaphore article serves as a robust endorsement of TDD, encouraging developers to adopt this methodology for its substantial benefits. TDD is more than a set of procedures; it’s a mindset that values thorough preparation and continuous enhancement. For those seeking to elevate their development practices, embracing TDD could be the transformative step needed, leading to projects that are not just successful but also sustainable and adaptable in the long run.

Delving into Test-Driven Development can significantly impact the quality and sustainability of software projects. For those interested in a deeper exploration of TDD, the Semaphore article provides an excellent starting point with comprehensive insights and practical examples.

Read the full Semaphore article on Test-Driven Development here for an in-depth understanding of how TDD can transform your software development process.

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

Writing Testable Code

For this week’s blog I decided to dive a bit deeper into writing testable code because I think it is a valuable skill. While searching for blogs that discuss this topic I found “TDD: Writing Testable Code” by Eric Elliott. In this blog, Elliott explains the importance of writing testable code barriers to writing testable code, and different tips to keep in mind to write testable code. 

The first thing he touches on is how a good quality process is essential to continuous delivery. One of the most important principles, he mentions, is the separation of concerns because “simplifies complexity and enhances the overall quality of your work”.

In the overview about testable code, he explains that achieving testable “allows for more efficient and effective identification of defects, ensuring higher quality and reliability”. The key characteristics of testable code are modularity (when code is organized into discrete units), clarity (code that is easily comprehensible), and independence (when code can be tested in isolation).One of the barriers of writing testable code that Elliott describes is tight coupling in code. The coupling in code is the instance where changing one part of the code can heavily impact or even break the functionality of another part in the code. If one part is changed there can be a chain reaction of bugs in various other parts of the code. Right coupling can be caused by parent class dependencies, shared mutable states, concrete class dependencies, event chains, state shape dependencies, control dependencies or temporal coupling. He explains that to write testable code you must reduce the forms of tight coupling mentioned because it makes testing easier and promotes a “more sustainable and scalable codebase”. This is why testable code and maintainable code are the same thing. 

Later he explains the test first vs test after approaches. The test first approach is the test driven development approach where tests are written before the code. The benefits include better developer experience and clearer requirements and design. The test after approach is where the tests are written after the implementation which leads to a probability of biased tests and reduced code coverage.

One of the last sections provided is about the separation of concerns which a  design principle for programs into distinct sections that  addresses separate concerns”. This principle is important because it allows independent testing and allows developers to isolate problems more effectively in addition to allowing the ability to make changes without unintended consequences. He describes that he likes to isolate into 3 distinct sections business and state logic (the core logic of the application), user interface, and I/O and effects (the part of the application that interacts with the database).

I think this source was well organized and easy to follow. It made the text easy to understand and provided great advice for writing testable code. I think the last section about how he likes to isolate the sections was especially helpful and I will keep it in mind for the future.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Week 12 – Comparing Tips

For this week, I wanted to look at what some websites consider helpful tips when it comes to testing software in Java and compare that to what we have learned in class. By looking at each tip one by one and comparing it to the things Professor Wurst has taught us during our lectures.

For this, I will be looking at this website: https://www.code-intelligence.com/blog/11-tips-unit-testing-java

Tip Number 1 is to “Compose Tests before Writing Code”, which is actually what we have been focusing upon for the last few weeks, so it’s good to see that this is being reaffirmed

Number 2: Keep tests small and concentrated. This is another subject that we’ve been looking at as well, as we’ve been looking at strategies on how to concatenate code for test.

Number 3: Defining your Code Coverage. This isn’t actually something I believe we’ve spoken about in this class, however, we have discussed similar things in my previous classes with Process Management.

Number 4: Isolating Tests from External Sources. This one Im not sure if we have discussed it, but it also seems like a given, considering we have been taught to always only use tests in test classes and to pull from testing packages when importing.

Number 5: Automate wherever possible. I don’t actually think we’ve done this yet in Testing, however, this is something we have discussed previously in another class, I believe in Software Design. If you can automate something, always try to.

Number 6: Creating Mock Dependencies. This isn’t something in specific we’ve touched upon yet I feel, however it makes sense. I feel as though when I did our first homework, I kind of did something similar to this.

Number 7: Use Assertions. Yes. Absolutely we have done this in class. All if not most classes we have written use assert.equals(), assert.true(), or assert.false(), amongst others.

Number 8: Using proper names to test methods. This is something we learned way back in CS101. Always name your methods something understandable for you and your team to instantly know what it does. Never write gobbledygook names for methods, be concise.

Number 9: Keep Unit Tests Up to Date. I don’t believe this has been taught yet as most code we have worked with has been static and unchanging. However, Im sure we will have assignments where we focus on this harder. It definitely seems like something that is extremely important, as code changes so too should the tests, or else they wont work properly or even give false positives.

Number 10: Don’t Focus on Implementation. This one is interesting to me. We haven’t really spoken about implementation of code when it comes to testing. It’s very interesting to me because I have never really thought about this before, but it definitely makes a lot of sense to me. Something good to keep in mind for the future.

And lastly number 11: Create independent test cases. I actually unfortunately learned this myself the hard way with the first homework, as each class was accidentally dependent of one another if ran back to back. It’s something I definitely need to keep in mind going forwards.

And thats it! It’s definitely a lot of overlap which is great to see. Until next week!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

A Software QA Student’s Guide to Impactful Code Documentation

Hey everyone! I found the article “Elevating Your Test Automation Projects With Meaningful Code Documentation” to be a valuable resource that directly relates to the course material. The article begins by highlighting the common challenges faced when trying to understand existing automated test code, such as unclear naming conventions and a lack of explanatory comments or documentation. Dickson emphasizes the importance of documenting code to ensure that both new and experienced team members can easily comprehend the purpose and functionality of the automated tests.
One of the key points discussed in the article is the effective use of comments. Dickson outlines two simple rules for writing meaningful comments: avoiding redundancy and being informative and concise. She provides an example of a Cypress test where the description of the test case made the additional comments unnecessary, as the test was already self-explanatory. On the other hand, Dickson suggests adding comments to explain the purpose and implementation of more complex code.
Another valuable documentation technique covered in the article is the use of docstrings. Dickson explains how docstrings, which are associated with specific code blocks, can greatly improve the reusability of the code. She demonstrates the power of docstrings by showing how they can provide information about function parameters, return values, and usage examples, making it easier for collaborators to understand and effectively utilize the code.
Dickson outlines several popular naming conventions and explains the benefits of using descriptive and consistent names for variables, functions, classes, and files. She highlights how these naming conventions can enhance the readability and organization of the codebase, ultimately making it more maintainable and collaborative.
As a software quality assurance student, I found this article to be particularly relevant and helpful. The author’s clear explanations and examples have assisted my understanding of the role that code documentation plays in the success of test automation projects. I can already can imagine applying these practices in my own future work, where I will continue to create well-documented and easily understandable test automation code.
Furthermore, the article’s emphasis on collaboration and code reusability stays with me, as I recognize the importance of working effectively with cross-functional teams in the software development process. By prioritizing meaningful code documentation, I can make sure that my fellow team members can understand and build upon the automated tests I create.
In conclusion, “Elevating Your Test Automation Projects With Meaningful Code Documentation” is a vital resource that has pushed my thinking for the role of code documentation in software quality assurance. The author’s practical advice has provided me with the knowledge and tools to enhance the readability, maintainability, and collaboration within my own test automation projects. I am confident that applying these principles will lead to more efficient and effective test automation, ultimately contributing to the overall quality and success of the software I help develop.

April 7, 2024
andicuni
https://www.ministryoftesting.com/articles/elevating-your-test-automation-projects-with-meaningful-code-documentation

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Workstations: The best setup for CS Students

Here’s the thing, having the right workstation isn’t just about keeping up with the cool kids anymore, it’s about finding the right blend of power, ergonomics, and style to run through coding marathons, debug sessions, and endless project nights. Let me guide you through what, in my opinion, is the best (somewhat cheap?) setup you could have as a CS student.

First off, the centerpiece of your digital dominion: the Laptop. You know that for CS students the laptop is not just some tool you use, it’s your best friend, your main weapon, your Excalibur and as such It needs to be powerful enough to compile the code faster than you can say “runtime error”. Try to find a laptop that has:

  • Powerful CPU: Intel Core i7 or i9, or AMD Ryzen 7 or 9. If you’re into Macs, Apple’s Silicon chips have proven their efficiency these past years so if you can afford it, go for it.
  • Plenty of RAM: 16GB should be your starting point. If you’re into machine learning or running multiple Virtual Machines, 32GB should be your sweet spot.
  • SSD Storage: Waiting for your IDE to load is so, 2010’s. Most laptops now come with 256GB SSD, if you juggle multiple projects you can upgrade to 1TB.
  • Graphics Card: Look into a graphics card that is affordable but also new, It will be useful not only for GPU programming and A.I. work but also for winding down by running some of your favorite AAA studio games.

Some people might be content with only a laptop as their workstation and I can’t say they are wrong as some of you living in dorms might not have the space for your workstation, but trust me when I say that setting up peripherals is a game changer.

  • Hi-Res Monitors: A single 27-inch, 4K monitor can drastically change your coding experience by reducing eye strain and improving readability. It works great for having your code on one screen and your reference material on your laptop. I’m running a 34-inch ultra-wide + 15.6-inch laptop on the side. Maximum real estate.
  • Mechanical Keyboard: Once you go clack, you never go back. The tactile feedback is not only satisfying but also reduces typing fatigue. Plus, it makes you feel like a hacker from a 90s movie.
  • Ergonomic Mouse: Your wrist will thank you if you get a mouse that is fit for your hand, try to find something that feels right for you.
  • Quality Headphones with Noise Cancellation: For when you need to zone out and focus, or just vibe to some tunes while debugging.

Don’t be afraid to express yourselves whether it’s with LED lights, action figures, or posters of your favorite GitHub repos, make it yours. You’ll be spending a lot of time here, so make sure it’s a place that inspires you.

By now you should have what is essentially a perfect workstation. You have your laptop around campus, your station to hook it up and unleash its potential.

This is my personal working space,I hope it inspires you. Till next time,

Ano out.

References

https://www.techradar.com/pro/best-laptops-for-computer-science-students

https://simpleprogrammer.com/best-laptops-for-computer-science-students/

https://medium.com/technonerds/desk-setup-2020-peek-into-the-gear-i-use-daily-as-a-student-f88ea8be16f5

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Understanding Integration Testing and System Testing.

When it comes to software development, ensuring that the final product meets the desired standards is crucial. This is where testing comes into play, and two significant types of testing are Integration Testing and System Testing. Let’s delve into what these testing methods entail and how they contribute to the quality of software products.

Integration Testing

Integration Testing focuses on testing the integration or interaction between different components or modules of a software system. In simpler terms, it examines how well individual units work together as a whole. This testing phase occurs after unit testing, where individual units of code are tested in isolation.

During Integration Testing, developers verify the interfaces between the units to ensure that they communicate correctly and exchange data appropriately. The main goal is to detect any defects or inconsistencies that arise when integrating these units. Integration Testing helps in identifying issues such as communication failures, data corruption, or incompatible interfaces early in the development process.

There are several approaches to Integration Testing, including top-down integration, bottom-up integration, and incremental integration. Each approach has its advantages and is chosen based on the software architecture and project requirements.

For more in-depth information on Integration Testing, you can refer to this link.

System Testing

System Testing takes a broader perspective by testing the entire software system as a whole. Unlike Integration Testing, which focuses on unit interactions, System Testing evaluates the system’s behavior and performance concerning the specified requirements.

In System Testing, testers validate various aspects of the software, including functionality, usability, reliability, and performance. This phase involves executing the software in an environment that closely resembles the production environment to simulate real-world usage scenarios. The goal is to ensure that the software meets the stakeholders’ expectations and functions correctly in different scenarios.

System Testing encompasses different types of testing, such as functional testing, usability testing, performance testing, and security testing. Each type of testing addresses specific aspects of the software to ensure its overall quality and reliability.

To learn more about System Testing and its types, you can visit this link.

In conclusion, Integration Testing and System Testing are integral parts of the software development lifecycle that help ensure the quality and reliability of the final product. While Integration Testing focuses on the interaction between individual units, System Testing evaluates the system as a whole. By conducting thorough testing at each stage of development, developers can identify and address issues early, leading to a more robust and reliable software product.

By understanding the concepts of Integration Testing and System Testing, developers and testers can effectively ensure the quality and reliability of their software products, ultimately enhancing user satisfaction and trust.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Decision Table Testing

The blog post, “Decision Table Testing: Everything You Need to Know”, discusses the concept of decision table testing in the software quality assurance field. Decision table testing is a systematic technique used to test the behavior of software systems against various input conditions. The blog post provided a comprehensive overview of decision tables, their components, advantages, and how they can be effectively utilized in software testing processes. In addition, the blog post offered practical insights into creating decision tables and implementing them effectively in test creation. It discussed the best practices for defining conditions, actions, and rules within decision tables, emphasizing the importance of clarity and consistency. Additionally, it provided tips for managing decision tables in a structured manner, facilitating easier maintenance and updates as the software evolves.

I chose this blog post because we have covered this topic extensively as well as incorporating a homework assignment on the topic. Due to this, I wanted to have further instruction on how this method of testing can be put to use and gain further knowledge on the method of testing. After reading the blog, I was able to gain a clearer understanding of decision table testing and its significance within software testing. Decision table testing is a very important testing method that will be a very useful tool to know and understand in use when testing for software quality assurance.

The blog highlighted the benefits of decision table testing, such as its ability to identify redundant test cases and minimize duplication efforts which are great to learn as it will help increase functionality of my tests as well as efficiency. From the blog post I was able to gain a greater understanding of Decision table testing and with that deeper understanding of decision table testing, I hope to be able to have real world scenarios that I would be able to apply the theory to. In conclusion, the resource not only expanded my knowledge of decision table testing but also equipped me with practical insights that I hope to be able to apply in my academic as well as my professional career in the future. As I continue to write and develop code for class and hopefully for career opportunities the more knowledge I have when it comes to software testing the better as it will help improve my level of design. Understanding one of the fundamental testing methods is just a step in the right direction for my career.

https://testsigma.com/blog/decision-table-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.