Category Archives: testing

Week 11

Deciding on a topic this week I decided to delve into Test Driven Development (TDD). I found an article with an engaging title “Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software” by Ferdinando Santacroce. This would be very useful for me and the whole class because it’s fresh in our minds and we will continue to work with this concept. Getting a firmer grasp on this topic will help me with future assignments and homework. It’s always great to get an insider view with experience inside the field connecting it to what we learn in class.

This article begins with the history of TDD giving credit to Kent Beck one of the first “extreme programmers”. At the time nobody had ever reversed the idea of testing starting with a test instead of the actual code. The purpose of writing a test before the code would help programmers put them in the perspective of the maker making it easier to create the software. This would make more tunnel-focused code with much more simplicity because of just focusing on the test. Plus the codes get rapid feedback because all the tests have been made. TDD has the fastest feedback loop only surpassed by pair programing. Currently, TDD is widespread inside the field and several teams utilize it day to day. It’s hard to adapt to this type of coding scheme but with time it is proven to be a key to success. Minor grievances may also come up because this type of process can be too rigid or the lack of tools.  

After reading this article getting a glimpse into the history of how this came to be. It didn’t specifically specify when it started but I assume it was around the 90s because it mentions how common it is now. Understanding the benefits of doing this test answers my question why would you decide to do your coding process in reverse? What we have been learning is that it will be conventional to have code and then write the test connected to the already processed code. The benefits of cutting down time because of the faster feedback times and leading to less complicated code, I now understand its purpose. That is a recurring theme with code the simpler the better because you are never working alone. Maybe it is a self-contained project but your future self may not understand your complex code and updates to the code should be easy to do not a headache. 

https://semaphoreci.com/blog/test-driven-development

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 10 Blog Post

Searching for an article this week I looked for something relating to mocking. Considering last week I did the negatives on mocking I think it’s valuable to have various perspectives. Seeing multiple ideas with mocking can give us an idea of how to implement them in the future. The writer of this article is a reliable source being a Java script developer. Getting information from someone in the industry can give a perspective inside the workforce and how people inside see different ideas. Not everyone may agree with using the same coding language but seeing how developers see different concepts can give an idea of the drawbacks to stuff and where in our own experiences can we improve. Overall this article is a great way to see how mocking is seen inside the workforce by an experienced professional.   

In this article, Eric Elliot focuses on the drawbacks of excessive mocking. He points out how brittle tests and how they can be easily broken. There broken simply just from the change of implementation even though the behavior stays the same. Another point is a false sense of security because of there lack of accuracy that occurs from not using accurate real behavior. This is a fault in the test because the test will pass even if it isn’t supposed to. Third, he focuses on complexity overload which is just adding too much complexity can make the code harder to understand and maintain. Elliot still believes in mocking but a more balanced approach can overall help the program. Mocking should be used sparingly and when there actual weight for its use. All together Elliott wants the audience to create a strategy that will have confidence in their code correctness while also minimizing any negatives of excessive mocking. 

Reading this article at first I thought it would be more of a pro mocking but it’s more in between. It says its flaws while still sharing the positives. After reading this article I understand that mocking can cut time but it can bring flaws to testing. The best time to utilize mocking is when time is scarce and later it can updated with time. It still isn’t the ultimate be-all to testing but with a balance, it will work. Understanding these flaws can foresee issues that may come up when mocking. Mocking should never bring up complexities that can complicate the code and should always have a priority in simple to understand and easy maintenance.

View at Medium.com
https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a

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

Week 9 Blog Post

Choosing a topic for this week I tried to find something we had recently touched upon. Last week we went over mocking and expanding my knowledge of this topic can benefit me and the class. Searching for articles about mocking I stumbled upon one that shares the negatives of using mocking data. To counter-attack the ideas we learned in class it is always great to know both sides to using a concept. 

This article doesn’t fully dispose of mocking but gives ideas when it’s good to use. It gives a variety of examples including “Isolating the unit under test from other components or dependencies that are not relevant to the test, Speeding up the test execution by avoiding network calls or database queries that can be slow or unreliable, and Controlling the test input and output by creating predictable and consistent data that can be easily verified”. These ideas are then counterposed to the negatives such as “Introducing errors or inconsistencies between the mock data and the real data, which can lead to false positives or false negatives in the test results, Reducing the coverage and confidence of the test, by not testing the actual behavior and logic of the external source or the interaction with it, and Increasing the maintenance and complexity of the test, by requiring extra code and logic to create and manage the mock data”. The flaws of mocking data are mainly it does not use real data making it much more different from the real data creating disparities between the two. These tests ignore scenarios with much more complexity and these error and bugs can go unseen. The author assures the reader to use a data source to improve the tests.

After reading this article it gave me insight into the negatives of using mocking. The week prior activities made the use of mocking reduce time in creating classes but it’s good to know when it should be used and when it shouldn’t. I wish there was a perfect solution for every test but to find bugs in your code you must expand your horizon. Reading this article made me see that a variety of tests testing different things can overall benefit you. You never have to completely ignore a type of test but being able to see the positives and negatives can save you in the long run. Plus it will allow you to have a broader knowledge knowing that this may have flaws but there are things I can add to have a satisfactory end product.       

View at Medium.com
https://medium.com/@queenskisivuli/why-mocking-data-is-a-bad-practice-for-testing-a20d2d7104aa
View at Medium.com
View at Medium.com

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

Pairwise and Combinatorial Testing

The article “Combinatorial Testing” focuses on the insights of software testing methods. This article explores the evolution of combinatorial testing, talking about advancements in algorithm performance and constraint representation. The article also talks about the importance in detecting interaction failures within software systems. The article also demonstrates the effectiveness of t-way combinations fault detection across various domains. The article “Pairwise Testing” talks about pair testing as a permutation and combination technique aimed at testing each pair of input parameters to ensure that the system if functioning properly across all possible combinations. The article also addresses the many benefits of pairwise testing and it’s role in reducing test execution time and cost while maintaining test coverage. Also, it talks about the challenges associated with pairwise testing, including the limitations in detecting interactions beyond pairwise combinations.

Pairwise Testing

pairwise testing is a software testing method that aims to comprehensively validate the behavior of a system by testing all possible pairs of input parameters. This method is mainly used when many of the defects in software systems are triggered by interactions between pairs of input parameters, rather than by individual parameters in isolation.

Benefits & Challenges

some benefits that pairwise offers is, efficiency: by testing the combinations of two input parameters at a time. This reduce’s the number of test cases required compared to exhaustive testing. pairwise testing also offers effective defect detection: by effectively finding defects that are triggered by interactions between pairs of input parameters, pairwise testing also helps to identify certain scenarios by systematically exploring pairs of parameters. Some challenges that pairwise testing may face is when it comes to parameter selection. Selecting the right parameters is crucial and requires a lot of knowledge of the software and it’s potential interaction scenarios. If the wrong parameter is selected this can lead to incomplete test coverage and missed defects.

Combinatorial Testing

Combinatorial testing is a software testing technique that focuses on efficiently testing the interactions between different input parameters of a system. This test method involves generating a set of test cases that include various combinations of input values / specific parameter values.

Benefits & Challenges

Some benefits of combinational testing include improved software quality: by being able to identify and address the interaction failures early in the development process. This test method tests various combinations of input parameters, which can help find defects that could impact the systems performance. A challenge that combinational testing may face is the scalability. Combinatorial testing is effective for small to medium sized systems and when scaling it to large and complex systems with a high number of input parameters and values, you may run into some problems.

Why did I pick this Article?

I pick these two article that talk about pairwise and combinatorial testing because both these test methods stand at the forefront of software test methods. The article’s goes into details about how both of these test methods offer an efficient way to ensure comprehensive test coverage while minimizing redundancy. Both of these articles have taught me a lot about pairwise and combinational testing.

Reflection

After reading both of these articles, I have gained a greater understanding of both these test cases. With the new found knowledge, I aspire to apply pairwise and combinatorial testing techniques in my future projects. Both these test methods offer practical solutions to common testing challenges, and by incorporating them into my future endeavors I aim to contribute to the development of reliable software systems.

Article link is here: https://www.sciencedirect.com/science/article/abs/pii/S0065245815000352

https://testsigma.com/blog/pairwise-testing/

From the blog CS@Worcester – In's and Out's of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Understanding Test Driven Development in Software Engineering

Test Driven Development is a method in software development in which tests are created before the actual code. By writing test before hand, developers have a clear understanding of what will need to implemented, which can help avoid unnecessary errors. This approach will help to have the software behave as expected. This method is a structured and systematic approach. This test method is doesn’t just focus on testing, however it also focuses on quality and behavior. The main goal of this test method is to ensure that the code meets the specified requirements and behaves as expected. Test Driven Development helps with clarifying requirements, reducing defects, and improving the code maintainability.

How does it work?

Test Driven Development operates on a cycle like, first write a test, second make it run, third change the code to make it pass, and then repeat. Developers should first write a test that will analyze the behavior that they want implement. After running the test and writing and rewriting the code to make the test pass, developers will then need to continue reframing the code to improve it’s design and maintainability without changing it’s behavior. This process will make sure that that each piece of code is throughly tested and validate before moving on to the next.

Test Driven Development vs Traditional Testing

The difference between Test Drive Development and Traditional testing is that test driven development method has a different approach and objective. Traditional testing methods usually aim to find bugs or even defects in code, test driven development mainly focuses on making sure that the code meets the specific requirements. A failed test in test driven development method tells the developers to write new code to fulfill the requirement’s, and it also tends to make sure that the code will be lead to higher quality, with fewer defects.

There are also two levels of test driven development that focuses on different aspects of software development. Those two levels being Acceptance TDD and Developer TDD. Acceptance involves writing acceptance test that verify the overall behavior of the systems based on the users requirements. Development TDD, focuses on writing unit tests for individual components or modules of the system.

Why Did I pick this Article?

I chose this article because Test Driven Development is a very important concept in software engineering. This article has taught me a lot about test driven development , which include numerous benefits like improved quality of code, reduced bugs and fewer defects, and faster development cycle. These many advantages are valuable for any software development project.

Reflection

After reading this article, i have learned a lot about Test Driven Development and it’s many advantages. One key take away for me was how in this method developers are to write test before actually writing the code, which can help in clarifying and ensuring that the code is correct and meets the required specifications. I also found how the article talks about the difference between test driven development and traditional testing methods. Learning about the Acceptance TDD framework helped me with my understanding of how test drive development can be scaled for larger projects and integrated into Acceptance methods.

Now that my understanding has been enlighten with this new found valuable knowledge and insights into test driven development methods, I can apply this in my future software development projects. I will also be able to writer better, cleaner, and more maintainable code when using this method.

Article link is Here: https://www.guru99.com/test-driven-development.html

From the blog CS@Worcester – In's and Out's of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

An Intro to TestProject as an Automated Testing Tool

Classes restarted last week, and during the first week I found myself reading and writing a lot of introductory blog posts about upcoming semester course topics. As part of my setup tasks for CS-443 Software QA and Testing, I read about one of the most popular manual API Testing tools Postman and saw reference to TestProject, an automated testing tool from the same company Tricentis. So, I decided to do some further reading into TestProject as I understood the basics of manual testing, but had not seen automated testing in action yet. To do so, I found a blog post on the Tricentis site containing an overview tutorial of API testing and how platforms like Postman and TestProject can be valuable.

The post begins by discussing the value in API Testing and mentions the utility of Postman, but also brings up some of the limitations that are commonly encountered such as test automation, scheduling, and end-to-end test reporting. Intro TestProject → This testing platform offers solutions for end-to-end API testing by providing an environment to not only test API’s, manually but also to automate API-based test flows, schedule and run them periodically, and generate execution reports without the need for third party tools or writing any code.

The blog also contains a six chapter tutorial on using TestProject, so I delved into Chapter 1 – Basic API Test Automation. This emphasizes the platform’s ability to handle a wide variety of input sources like HTML, Databases, and more, then showing the application GUI and taking the reader through how to add ‘test steps’ in TestProject to set up automated testing for a GET HTTP request using NASA’s public APIs including search parameters and discussion on Dynamic Endpoint URLs (and implementing them) amongst others. Chapter 2 offers another brief tutorial discussing the value of scheduling automated tests with image steps (guide) to doing so with interactions to Android and iOS systems.

From these introductory chapters, I was able to get a basic idea of how to use TestProject to design calls, execute tests and access result reports. The other chapters in this TestProject tutorial cover more advanced API testing and validation flows, shell commands, scheduling API automation and more. As an introduction to Quality Assurance Testing and the course in general, this chapter was intriguing and valuable to get an idea of what an automated software testing tool looks like and how to use it in a basic sense. Stay tuned to read more about these other chapters and other topics in software quality assurance and testing and other exciting computer science related topics!

Sources:
General TP Post: https://blog.testproject.io/2020/11/10/automating-end-to-end-api-testing-flows/

Chapter 1: https://blog.testproject.io/2020/11/10/basic-api-test-automation/Chapter 2: https://blog.testproject.io/2020/11/10/api-test-automation-flows-combined-with-mobile-functional-test/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

QAn’t Wait to See You Again

CS SERIES (16)Before I dive into my final installment of this CS series (for now), I wanted to say thank you if you actually read any of these posts and thank you to my new followers for dealing with the notifications you must have gotten.

For this last post, I wanted to discuss the article 5 Reasons You Are Wasting Your Testing Time by Joel Montvelisky. The author expresses how everyone can do testing but not everyone can do “good testing,” which incorporates more than just what is basic checking.

A short list of main reasons why a lot of people tend to waste time that could have been spent testing other things includes:

  • Not having clear goals
  • Not understanding what or how much the feature means to your End User
  • Not keeping track of what was tested and potential discoveries
  • Not consulting what you already know or using references
  • Not giving feedback that could be shared to help others

Sam CS (22)I agree with most of what Montvelisky says as I have personally noticed what has happened from my experience as a Software Quality Assurance Intern when any of the five things above took place based on a task. It is important to understand that sometimes these things may be out of your control but you should still try your best to avoid miscommunication wherever possible.

Montvelisky’s content has not necessarily changed the way I will work as I have already been consciously making an effort to understand what I am reviewing, how stuff is meant to work, logging tasks, connecting tasks to previous occurrences, and communicating with the QA team. If I had read this article before I started working, it would have been more useful as it would serve as a foundation to how one should think of testing beyond the basic functionalities.

Something I wanted to emphasize is the post-test reviews and feedback sessions with peers. I found that if someone else needed to learn about a project or a task had to be communicated with a client, logging any kinds of notes or information was better than not having anything prepared to discuss. They do not necessarily have to be posted for everyone to access but it would be good to note it in any sort of text editor for future reference. I think an example of when to note things is if you found something that does not prevent your current task from being approved but it still affects something for the overall program.

Overall, when testing things I believe you should trust your instincts on reporting things you find. It helps when you try to imagine how much it could affect a program in the long run if not brought to someone’s attention, even if it may seem minimal.

Best of Luck,

Sam

Article: https://qablog.practitest.com/5-reasons-you-are-wasting-your-testing-time/

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

Test Yourself Before You Wreck Yourself

CS SERIES (14)Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.

Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.

The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.

What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.

One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.

Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.

Article: http://www.softwaretestingmagazine.com/knowledge/approval-testing/

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

Is Your Interface Two-Faced?

CS SERIES (11).pngWhen coding, users always have to be conscious about the way their code may be implemented or used in the future by different services leading to potential misuse. After reading Code Health: Make Interfaces Hard to Misuse by Marek Kiszkis, it made me think about how important communication between testing code is.

I found this content useful because Kiszkis featured some examples that can show how an interface could be misused easily. The examples included:

  • Requiring callers to call an initialization function
  • Requiring callers to perform custom cleanup
  • Allowing code paths that create objects without required parameters
  • Allowing parameters for which only some values are valid, especially if it is possible to use a more appropriate type

Sam CS (17)It is also good to remember that at the end of the day, code should be defensive but not too defensive to the point that complexity is increased and performance overall is reduced. Kiszkis says “it is not always practical to have a foolproof interface” because there will be situations where some requirements are things that cannot be expressed in an interface.

After seeing so much content based on being careful about what you code it is surprising how this article says it is not necessary to plan too hard. I kind of understand why Kiszkis would say this but personally, I kind of disagree with this. The reason why I disagree is because if someone does happen to end up with more time to work on something than expected and they know it will make something more efficient, then why not go for it?

Overall, I appreciated what was shared in this article in terms of encouraging users to try and see issues that can arise with their code when it comes to interfaces. The main takeaway for me is that if something is brought up, or triggered by undefined behavior, a user should try and make it impossible for this to happen. A way of doing so is by adding things where necessary, like certain slots in his example. It does not have to be too specific but detailed enough so that it covers different aspects, similar to how we try to prepare for everything when it comes to equivalence class testing.

Article: https://testing.googleblog.com/2018/07/code-health-make-interfaces-hard-to.html

 

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

The Business Case for Unit Testing

In this post, Erik Dietrich talks about the importance of making sure developers are well-trained in writing units tests.

“If you have developers writing good unit tests, you’ll develop a nice, robust unit test suite over the course of time. Developers will run this test suite constantly, and they’ll even have the team build to run it in a production-like environment.”

Making sure your units tests are well written and easy for maintainers to understand helps prevent regression, like a developer editing code and breaking functionality elsewhere.

“Testable code is better code, as measured by how easy it is to change that code.”

Writing better unit tests allows for bugs to be caught earlier and increases functionality and modularity, saving businesses money and making you a better developer with a more productive team.

The post The Business Case for Unit Testing appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.