As I take another step towards Software Quality Assurance Testing. I start to think and learn about how would I write a good unit test. That lead me to a podcast about “Clean Code – How to write amazing unit test” by Joe Zack. This podcast does a very good job on explaining the idea of clean code and also about how to write amazing unit test. This podcast also touches Test-Driven Developing.

The blog first starts out talking about a few interesting things however unrelated to the topic it finally gets into the topic 17 min into the podcast. For this blog I am only going to touch on the clean code part of the podcast to hear the full podcast please click on the following link https://www.codingblocks.net/podcast/how-to-write-amazing-unit-tests/#more-2483 otherwise…

The podcast mentions the following things about clean code:

There are a few problems with keeping test clean. For example, keeping test clean could outgrow your prod code and become unmanageable. However, there are more problems with having dirty code. Such as when/if code changes the test must also be change causing double work and harder to change. If test is extremely dirty it could become a liability.

Clean test is important because it keeps all test code readable, simple, clear, maintainable, and reusable. When you have tests it makes it easier to change code and less scary. A clean test makes it easier to improve the architecture.

A great way to have a clean code is by using the “Build – Operate – Check Pattern”. Which stands for building up the data, operate on the test data, and check by insuring that the operation yielded the expected results. Test should be written in a specific way so it will be able to be used in different testing platform. Another way to have clean code is to only have one assertion per test. Since, it makes the test easier to read. Although sometimes using multiple assertion is necessary and more beneficial to do so. Clean code can also be achieved by making sure to have a single concept per test. This idea is actually more important then having a single assertion. That is because it makes sure to only test related things, instead of un-related items.  A good general practice to follow for clean code is to remember “FIRST”. The F in first stands for Fast, meaning a test should run quickly and be fast. The I in “FIRST” stands for Independent, meaning each test must be independent. The R in “FIRST” stands for Repeatable, meaning test must be repeatable in different environment without the need of infrastructure specification. The S in first stands for Self-validating, meaning a Boolean output or either true or false is required. The T in fast stands for Timely, meaning a test must be written in a timely manner particularly before writing the production code in order to ensure they are easy to code against.

To sum this up practicing clean code is a very good idea to practice. From the testing to the code production clean code has more benefits then not. It is important to create unit test in order to be confident when needing to change the production code. Over time this practice will prove to be more beneficial since it allows improvements to be flexible and maintainable.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

https://www.qasymphony.com/blog/test-automation-automated-testing/

          The blog post I wanted to talk about today covers the difference between Test Automation and Automated Testing while also explain new concepts like Continuous Testing. The post starts by explaining that there are two types of automation known as Automated Testing and Test Automation. It defines Automated Testing as the conduction of specifics tests through automation while Test Automation is the automation of tracking and managing different tests. It continues to talk about Test Automation and why it is critical to continuous testing. Continuous testing ensures that the test quality is as high as it can be at all times. Usually tests are completed at the end of the development cycle but now tests are done throughout the development cycle whenever they are needed. However, in the real world, testers need to verify and schedule test cases which means they have to be in communication with other members of the team and the product owner to make sure that the original product requirements are still being met. They must break down these requirements to write the tests and track the progress of each test which can take time. These models make continuous testing a viable option and it works very efficiently but now testers need to think about test management more carefully if they are going to integrate it into development.

        I found this article interesting because of the new concepts it showed me for software development and testing. I enjoyed the enthusiasm this post had for Test Automation and Continuous Testing because it paints these concepts in a light that really makes it seem like this is a new step forward in making any generic development cycle more efficient. The post explained the definitions of these terms clearly and then went into detail about their integration into testing while also explain how that would affect the overall development cycle. The most interesting part of this post was when they explained the pros and cons of this testing integration. I found that the pros of having a more efficient development cycle made sense, but I would never have thought about the amount of work that the testers would have to go through as well to make this work. This showed me that even though the system would ideally work, there is a vital part of communication as always in a development cycle that can help or hurt the process. I found this to be a good source of information to learn about how testing is woven into development and through the explanations, shows the reader that there can always be new ways to make testing more efficient.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

So for this week, I have decided to read “What is Test-Driven Development?” from the Rainforest blog. The reason I have chosen this blog is because from what I understand of test-driven development, it is hard to apply in practice and requires a lot of time when doing this process, the first time. This will help me in understanding the advantages and disadvantages of using this process.

For this blog post, it goes over what the benefits of test-driven development are, who needs the development in question, how does it work, and the disadvantages of using it. Test-driven development is a software process that follows a short, repetitive, and continuous cycle of creating unique cases for companies want in their applications. Unlike traditional software testing, test-driven development implements testing before and during development. The benefits provided in this process are quickly sending quality code in production, efficiency building coverage on the building’s application, and reducing resources required for testing. This development is good for teams for fast release cycles but still want to ensure their customers are receiving quality results and teams with little practice in-house QA practices instilled but still value quality. The disadvantages are product and development teams must be in lock step, difficulty maintaining transparency about changes, and initially time sensitive.

What I think is interesting about this content is it does give scenarios for each part to express the process and why companies would use this development. From the blog, it breaks down to the meaning of the titles, giving the details of the scenarios, and finally the charts to give the idea of the process when working together. The content has changed my way of thinking in understanding the process and not believe that it is very difficult in introducing this process to a person that is learning programming the first time.

Based on the content of this blog, I would say this is straightforward to understand once going over the fundamentals a few times. I do not disagree with this content given by this blog because it helped me understand the idea of test-driven development with the short descriptions and charts that show it. For future practice, I shall try to refer this process when teaching those who have difficulty with programming.

Link to the blog: https://www.rainforestqa.com/blog/2018-08-29-test-driven-development/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

https://reqtest.com/testing-blog/load-testing/

This blog post is an in-depth look at load testing. Load testing is a type of performance testing that identifies the limits to the operating capacity of a program. It is usually used to test how many users an application can support and whether the infrastructure that is being used can support it. Some examples of parameters that load testing can identify include response time, performance under different load conditions of system or database components, network delay, hardware limitations, and issues in software configuration.

Load testing is similar to stress testing, but the two are not the same. Load testing tests a system under peak traffic, while stress testing tests system behavior beyond peak conditions and the response of the system when it returns to normal load conditions. The advantages of load testing include improved scalability, reduction in system downtime, reduction in cost due to failures, and improved customer satisfaction. Some examples of load testing are:

• Testing a printer by printing a large number of documents
• Testing a mail server with many concurrent users
• Testing a word processor by making a change in a large volume of data

The most popular load testing tools are LoadView, NeoLoad, WebLOAD, and Load Runner. However, load testing can also be done without any additional tools. The steps to do so are:

• Create a dedicated test environment
• Determine load test scenarios
• Determine load testing transactions for the application
• Execute the tests and monitor the results
• Analyze the results
• Refine the system and retest

This blog post did a good job at defining load testing and explaining why it is an important process. I had heard of stress testing previously, so I appreciated how the author described the differences between the two. The part that I thought was most useful was the section on the advantages of load testing. It makes it easy to see why load testing is important if you are building something like a web app. It was also useful to read about some of the most popular tools because I now have a reference if I ever need to do this kind of testing in the future. I’m glad I read this blog as load testing seems like a very important practice in the field of software testing.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

http://news.mit.edu/2018/mit-csail-machine-learning-system-detects-fake-news-from-source-1004

This is an interesting article about how researchers are trying to make a program that will decide wether or not a news soucre is reliable. This program uses machine learning and scrapes data about a site to makes its determination and it only needs about 150 articles to reliably detect if a source is accurate or not. Researchers first took data from mediabiasfactcheck.com, a site that has human fact checkers that analyze the accuracy of over 2,000 news sites. They then fed that data into their algorithm to teach it how to classify news sites into high, medium or low levels of factuality. As of now, the system was 65 percent accurate at detecting these levels of factuality and 70 percent accurate at deciding if a source is left-leaning, right-leaning or moderate. The researchers determined that the best way to detect fake news were to look at the language used in a sources stories. Fake news sources were likely to use language that is hyperbolic, subjective and emotional. This system was also able to read wikipedia pages on sources that were fake news and noticed that those wikipidia pages contained an abnormal amount of words like extreme or conspiracy theory, even making correlations with the strcuture of a sources URL, sources with lots of special characters and complicated subdirectories were associated with being less reliable.

I think this is noteworthy because of how important accurate information is on the internet. There are a large number of people that spread misinformation on social media and influence the behaviors and thoughts of their readers. There are constantly news stories on bots from Russia or other countries trying to spread misinformation to not only the United States but anyone they consider a threat. The spreading of this fake news can cause a lot of problems and pose a serious issue for the information age to the point that I have heard people refer to our current time as the “misinformation age”. If automated software is able to detect fake news at a near perfect accuracy it will help the entire planet in combating such a large and seemingly unbeatable problem. Something that takes hundreds of fact checkers could take a program a few minutes and it could be accesible to the general public for all of thier needs. Although the algorithm in its current for is not accurate enough, it is a step forward and a look at a possible solution that we desperately need.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

“The White Belt” is all about setting aside your previous knowledge and approaching new situations with the mindset of a beginner. To demonstrate the general idea, the writers give the example of a family therapist who is skilled at facilitating constructive communication, but doesn’t assume he has expert knowledge on the unique circumstances of a particular family. The writers suggest learning your second language as the most likely time to run into problems from not maintaining a stance of not knowing.

I experienced this myself when learning C/C++. My first language was Java, which is object-oriented, while C is imperative. One of my biggest stumbling blocks in learning the language was failing to understand that writing classes wasn’t necessary, when I assumed it was from my knowledge of Java. I didn’t have the luxury of sacrificing productivity to spend time improving my skills, as this pattern suggests, since I was in the middle of an accelerated summer course. But I’d certainly have understood more quickly if I’d approached learning the language from the ground up. I will avoid this in the future by trying to consciously set aside my previous programming knowledge when starting a new language.

As this pattern explains, bringing your preconceptions about how things work to a new technology or context actually impedes the learning process, whereas keeping in mind that being competent in one area doesn’t mean you have expert knowledge in a different area will speed up the process. You will be open to new ideas you otherwise might not have considered.

The three side-by-side comparisons of how to generate random numbers in different languages is a good demonstration of this. Reading it for the first time was mind-blowing to me, especially the one-line solution in J. Even though such terse code comes with its own problems, it’s still effective at showing the contrast between different approaches in different languages and the benefits of setting aside the attitude that you’re already an expert. You might overlook the possibility of such a simple solution otherwise.

“The White Belt” reminds me of “Expose Your Ignorance,” because it emphasizes not allowing your fear of appearing ignorant to get in the way of your learning. In fact, the insight from this pattern I liked most was from a quote asking whether the key to a genius’s success is allowing themselves the freedom to look foolish, which we tend to interpret as eccentricity.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

In this Apprenticeship pattern “Retreat Into Competence”, it explains that at times, an apprentice might need to take a step back from their ideas or objectives in order to fully approach the idea or objective effectively. This could mean that you as an apprentice may need to take a step back in order to clear your mind from what you know, and what you think you know to be able to allow new ideas and motives to flow into your mind, which would allow you to develop new crafts as an apprentice. Attaining these newfound ideas can be learned from your teammates and experts.

“Pull back, then launch forward like a stone from a catapult. Retreat briefly into your competence to regain your composure. Take some time to build something that you know how to build. Then use that experience to recognize how far you’ve come and how much you are currently capable of.”

I agree with this statement of retreating briefly into your competence. The way I see this idea is that it is basically telling you to reset yourself or revert yourself back into a new apprentice. This means that you have a fresh mind and you feel open to new ideas because you have the motive to learn new things from others around you.

“This pattern is most relevant for people who have stretched themselves far beyond their ability. If your apprenticeship has you taking reasonable-sized steps forward, taking on gradually increasing responsibilities and technical complexity, then you may not need to take shelter in this pattern. But if you are really struggling or are barely keeping your head above water in The Deep End, look for opportunities to temporarily retreat. Sometimes you need to take one step back in order to take two steps forward. When you do this, it is important to turn that backward movement into forward momentum as quickly as possible. That forward momentum is revealed in your possession of more knowledge and greater skill than you had yesterday.”

This part of the apprenticeship pattern was useful to me because it states that it is not good to pull back to far because you may find yourself to settle for initial failure and surrendering to the fear of failing. If I was in this position to shortly retreat from everything, I would use the time effectively to relearn what I already know in case if I missed something important such as an important basic fundamental instruction in a specific programming language. I feel as though if I did retreat to far back or for too long, I might not use my time wisely and may feel too comfortable in my retreat. This pattern will change the way I work and operate in my profession because now, I know that it is normal to retreat a little if I’m stuck on a software development problem, or any real world problem.

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

While learning how to be a great apprentice is great, the main issue is getting to that point. Specifically being accepted onto a team or project, being hired by a company. To be a part of a professional team and become an apprentice is the first step and can be the hardest thing to accomplice for some.

As the book states, it is a risk hiring someone new and untested for teams out there. You may not be able to contribute to the teams work and you may not even be able to take care of automating simple manual tasks. So then how does one solve this issue? By having Concrete Skills. Having skills that will first of all get you through the HR filter and technical skills that can and will aid any team you are on. This makes the risk of hiring you on much lower, and makes the decision easier.

This apprenticeship pattern was not really at all surprising. Every step of the way, I was nodding my head. Learning concrete skills just makes too much sense in my head to be something anyone can disagree with as a valid way of making it more likely to be hired on to teams. Reading this apprenticeship pattern has not changed any of my thoughts on my chosen profession but has solidified the path I believed I would have to take in the first place.

The story the pattern offered did make me open my horizons when it comes to what count as concrete skills. Skills gained as a therapist would obviously be helpful in a team setting, but it is not something that would come to my mind readily. I mainly think of only technical skills, but social skills that can aid the rest of the team in ways I or they would not expect are also completely valid avenues to making it easier to hire oneself.

Also, looking at others CV’s and resumes, then pulling out the concrete skills that one can learn themselves and demonstrate easily, is a simple action that I can start doing now. Something obvious in hindsight that I should have been doing from the start.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

This week I have decided to cover the “Stay in the Trenches” pattern. While the title of this pattern seems harsh, it is actually encouraging. One day in your career as a software developer, along the journey of the software craftsmen, you will encounter promotions. These will most likely be in the form of increased… Continue reading Apprenticeship Patterns: Stay in the Trenches →

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

This week I read the apprenticeship pattern called “Breakable Toys”, like the other patterns that I’ve read so far I think that this one is very applicable. This pattern suggests that one of the best ways to learn is through being able to try new things and do experiments that can and likely will lead to failure. The issue that this pattern addresses is that often times, we are not in an environment where failure is acceptable or consequence free and thus by having a “breakable toy” we are free to effectively try whatever we please.

I think that this pattern is extremely useful because it is very applicable in real life. Everyone has been in a situation where they wanted to try a new approach to a problem but didn’t because the risk associated was too high. When applied correctly, the risk associated with trying something new is almost nothing while giving you an increased opportunity of finding new solutions and learning new things. After giving this pattern a little more thought however, I realized that we developers apply it almost daily (often times not to an optimal degree). Take branching for an example, by working against a branch of the master code, you are essentially working on a breakable toy where you are free to try almost anything you please. Having the ability to work on a breakable branch of a product brings a level of freedom and productivity that working on a master branch never could!

This pattern has changed the ways that I look at my profession in the sense that I now have a better understanding the true importance of working on a branch for any change (even if it is miniscule) and test builds/environments. With the former you can for example, try implementing a feature however you please without fear of it breaking and halting the progress of your coworkers, and with the latter you can (for example) load test and try to break a “toy” version of your app without worrying about taking down production.

In conclusion, this is a great pattern that we use to a certain degree daily. This pattern can provide great benefits when applied correctly and result in catastrophic failures when not applied at all. I intend to use this pattern to continue learning as a grow in my career.

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