Week 15

Last week my group and I were discussing behavior-driven development. It is a type of development that refines our previously learned developments. This is a great jumping point to what we were previously learning and it will make for a great assignment. I would like to give more information on this subject matter because it is valuable. This is another practice that is used in the field that can be used in the future.

Behavior Driven Development (BDD) is an agile testing practice that prioritizes creating automated tests first before specifying system behavior. BDD is utilized in a group setting where both agile teams and business participants can see eye to eye. BDD are tests used to capture a story, feature, or capability from a user’s perspective. During this development, there should be three different heads of mentality to considered. Customer minds usually stakeholders understand the business needs and their desire for new requirements. Developers understand what needs to be done to accomplish their responsibilities and technological feasibility. Test-centric minds should consider any exceptions, new edges, and boundary conditions. There are three phases during BDD discovery, formulation, and automation. The product owner or product manager creates criteria that must be used to write a good story. Then, the discovery process where the team finds any additional information that could enhance the criteria. There is an automation phase that automates the acceptance test. This test shares a lot of similarities with Acceptance Test–Driven Development (ATDD) and Specification by Example (SBE). 

This new development strategy was very useful to learn. It’s good to understand different types of development plans and how you can combine them to make a stronger development cycle. During the agile team cycle, I feel like every cycle you can change what type of software development you use for that cycle. Based on the project, resources, and time you can choose different software developments. Learning about BDD gave me an insight into the business side of the development process. These are things you may not think about when creating your software but should be a priority. You would expect your software project to be examined by someone who is informed in the field but to try to explain to someone that is funding it would be a hassle but necessary. It makes sense that people who aren’t on the team would have to understand the development. It’s a group effort between multiple teams that all must work in unison to create a working product.  

Advanced Topic – Behavior-Driven Development

https://scaledagileframework.com/behavior-driven-development/

Week 14

Considering this week we only had one day of class it’s good to reinforce the ideas we learned to spread out in separate classes. I was in a search this week for an article that went into depth about software technical reviews. Software technical reviews are very important; understanding the fundamentals is a key component in the field. 

The main function of a software technical review is to examine a document either in a group or alone and find errors or any defects inside the code. This is done to verify various documents to find if they reach specifications, system design, test plans, and test cases. An important thing to consider is this is a step to make sure the client gets clarity of the project and stays informed on how it’s going. In addition, finalize any changes to reach the requirements before being released to the market. This allows for improved productivity, makes the testing process cost-effective, fewer defects to be found outside the team, and reduces the time it will take to create a technically sound document. The main three types of software reviews include software peer review, software management review, and software audit reviews. The process of software review is simple if you are informed of the implementations taking place. First is the entry evaluation which is just a standard checklist to know the basis for the review. Without a checklist, you will be pulling on strings to find what is wrong with the code or what it’s missing. Then comes Management preparation ensures that your review will have all the required resources like staff, time, and materials. Next is review planning where you create an objective that comes from the team. You then move on to preparation where the reviewers are held responsible for doing their specific task. Lastly, examination and exit evaluation where the group meets up and is discussed to make the team on the same page and verify any discoveries.

Reading this article allowed me to see other steps that are taken to do a software technical review. If we as a team were able to create an objective of what to search for inside the code last week it would have been more goal-oriented instead of randomly searching for faults in the code. As a team, it would have been great to have a more organized group so then when we come together we have an understanding of what we should all find. I would like to see how it would work trying to explain to someone who doesn’t code what has been done and show them that their money is being placed in the right place. Other than that this is a great way to reduce time and be in unison with your team.   

https://medium.com/@vyashj09/software-technical-reviews-in-software-testing-what-is-software-technical-review-321462039f4f#:~:text=A%20software%20technical%20review%20is,an%20object%20in%20the%20software.

View at Medium.com

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

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

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