Breakable Toys was an interesting pattern to read about. The premise is that in order to develop your skills, you should spend some time single-handedly developing small software projects. The example the text gave was maintaining a Wiki, which over time develops many skills in different areas. Ideally you will be able to find enjoyment in your toy so you can continue to grow from it. This toy is also something you can take with you, and something you can continue to learn from.

The idea of Breakable Toys was one I’d never really thought of before, but after reading it I can say that I’ve probably used the pattern to some extent. I can recall a time where I was learning HTML and CSS just to customize a web-page on an online game. At first, I had no idea what I was doing, but after some research and a lot of experimentation and trial and error, I began to have a much better concept on designing a web page. Meanwhile, I was enjoying the learning experience and the progress towards building something of my own. The ability to find enjoyment in what you learn is what eventually lead me to where I am in the first place.

After having read the chapter on Breakable Toys, I think I will try to be more intentional with my use of interesting and fun things that simultaneously develop my programming skills. One idea would be to develop a game in a new language, that way I can learn a new programming language and do something I enjoy.  Eventually, I can also develop the same game for any new programming language I wish to learn, as an interesting way to see some of the differences and similarities between them.

Something I’m learning about a lot of these patterns is that they are all sort of things that people just tend to do naturally to try and aid their own development. I guess that’s the whole point of the patterns, but it is really insightful to have some of these ideas put into words.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

For this weeks blog post I will be looking at the pattern called “The Deep End”. The context behind this one is that taking small safe steps leaves you unsatisfied and you are beginning to fear that you may be in a rut. Instead of diligence that could attain the next level you are in a rut where bland competence eventually will decay into mediocrity. The problem with this is that you need to grow your skills, confidence and portfolio of successful work. Challenging yourself with bigger things like bigger projects, larger teams and more difficult and complex tasks, new workplaces and more. This will again help you grow as a developer instead of settling for a rut. The solution to this is to jump in at the deep end, taking it head on almost. Waiting until you are “ready” can turn into a disaster or a pattern of never doing anything. When offered a higher profile role or a more difficult problem grab onto it with both hands take it head on. Personal growth will only occur if you are doing something out of your comfort zone and doing things that stretch your boundaries. This of course will have its risks without a doubt. If you get it wrong and way in over your head you could drown. But thankfully in the business there are many places where you can take risks without destroying your career if you were to fail. These risks are opportunities that will help you grow. It means taking a foreign assignment when its offered, even if the possibility of failure is staring in your face. Acting on this will be extremely beneficial to you when in a rut. Thinking of the biggest projects you have worked on and then writing down the answers to these questions pertaining to the difficulty of other projects is a good way to start. Using metrics to measure every project, in a sense, of your own projects. I find this pattern to be very on par with the be the worst mentality. In a sense you are putting yourself in an environment that may or may not cause you to fail miserably but if you succeed you will grow immensely.

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

For the ninth week’s reading, I chose to read the pattern, Record What You Learn. The problem this pattern addresses is keeping a journal or history of what you learned but not casting it aside. It suggests that a journal, personal wiki, or blog of lessons can help you in the future. This can be either for mentoring purposes, or a source of information for yourself and others. However, the biggest trap stated is that you will write down the lesson and forgetting them. The next step of writing them down is to revisit them regularly and review what you have written down. Eventually, the outcome is that you will achieve an accurate self-assessment of what you actually know. An example of a successful journal is about a guy named Dave who kept quotes that shaped his learning and eventually totaled over 500 quotes. With this he was able to share it with others and was helpful when he started writing articles and this book in particular!

What I found useful about this article is that it made me do a self-assessment on the spot about how I’m currently retaining information from school. Notes, projects, presentations, and papers are all evidence that I have been actively involved in my learning. However, once the course has finished, all those notes, papers, projects, and presentations are forever locked away in my drive, closet, or thrown away. Valuable information that could be useful in the future is now stacking up somewhere that can’t be maintained in a practical way.

What I found interesting about this article is the portion of the personal wiki. I did not know that you could create a personal wiki and it answered a question along the way. The question is what happens if there is something you learned but don’t want to share publicly. As such, you could have private and public records with no issues. This sparked an interest for myself, as I need a breakable toy to mess around with and learn but didn’t want to create a blog from scratch to do the job. Overall, this pattern is meaningful as it’s a good place to start if you don’t have anywhere to begin.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

          The “Rubbing Elbows” pattern is described as a way be able to branch out and meet other developers instead of working alone. The book talks about how productivity and learning can understandable plateau if you constantly work alone. The best learning experiences come from balancing private learning with team learning whether that be in a large team or simply coding with another person. It allows you to learn things that can only be understood when you and another person have a shared goal in mind. There are little quirks that you can pick up when working with someone that a mentor may leave out or find trivial to teach due to the small scope of learning it provides but over time these quirks can add up. This being said, there are also negative effects of this pattern to watch out for. An example would be to not pick up bad habits that your partner may develop or have. Another example is to make sure to not fall behind on your part of the work because it then hinders your partners learning progress as well if he has to pick up the pieces behind you.

          I found this pattern to be understanding of solo programmers and shows them a way to learn more through working in teams. It showed that working in groups and teams can build communication skills and increases exposure to several coding styles. I found that when the book mentioned pair programming as an example, I got much more interested in the topic. The idea of switching off coding seems very interesting to me and makes me want to learn more for an experience programmer. I want to incorporate this mindset in my work environment to learn better from my peers. The pattern did a good job on the negatives as well by going into subconsciously learning habits that aren’t good for you. This can be helpful to keep me mindful that some habits should be avoided or corrected to increase proficiency at the language. I agree with this pattern very much as it has taught me to value pair programming much more and has instilled a new interest to find a coding buddy to learn off of.

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

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my sixth individual Apprenticeship pattern I have chosen “Dig Deeper”.

Summary

Lets say you have a superficial knowledge in a programming language, a problem you’re not even aware of until someone puts you on the spot. This is also a problem because you will have trouble maintaining whatever issues you may come across.  This pattern is an encouragement and gives strategies for you to dig deeper and have a better understanding on your programming knowledge. The way it does this is by telling you to… “Learn to dig deep into tools, technologies, and techniques. Acquire the depths of knowledge to the point that you know why things are the way they are. Depth means understanding the forces that led to a design rather than just the details of a design.”. This approach in learning is important because it gives you a deeper understanding on a topic which can lead you to have confidence that will help guide you to have the strength you’ll need to guide you in new areas. “Another advantage of digging deep into a technology is that you can actually explain what’s going on beneath the surface of the systems you work on. In interviews, this understanding will distinguish you from other candidates who can’t describe the software they’ve helped build in a meaningful way because all they understand is one little portion.” Having deep understanding is an advantage because it will differentiate you from those who are just building rubble to those who are building cathedrals, which will open up many doors for you. In order to be considered a cathedral builder you must really know how to debug, reverse-engineer and be willing to “read the specification, RFC, or standards for the technologies you use”. An action to take will be to find books, open source resources, and anything else that will help you gain a deeper understanding.

My Reaction

This pattern stresses the importance of digging deep in order to have a deeper technological understanding of your programming language that would help you stand out in your team. I agree with this idea. I found this pattern interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I need to dig deeper in order to be beneficial to my team.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

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.

I think it is extremely cool that with a simple tag at the beginning of an individual Junit test, the entire execution of the entire collection of unit tests in a given source file. When reading about tags such as @BeforeEach and @BeforeAll after going over it briefly in class, I came across an article which describes the most common tags used for Junit tests, found here: https://www.testingexcellence.com/junit-5-annotations/.

Some of these tags are repeats from what we have discussed in lectures, but I find it helpful to rephrase the functions of each tag so that I better understand what each of them does.

@Test – This is a broad tag which simply denotes the presence of a Junit test method to be executed. There are no parameters for this tag.

@ParameterizedTest – This tag specifies that the test being executed must be run multiple times, but with different arguments each time. The test method is defined in the same way it would be under a @Test tag. However, along with the switch to a @ParameterizedTest tag at the beginning of the method, the tag @ValueSource is also used below this initial header. The attributes for this ValueSource tag denote the different arguments to be used and consumed by the test method.

@RepeatedTest – This tag describes a test method being executed a given number of times, specified in the attribute field of the tag. The difference between this tag and the @ParameterizedTest tag is that the same arguments are used for the @RepeatedTest.

@DisplayName – This tag allows the given test method to have a custom display name, which is shown by test reports and during runs. The name (as a string) is the single argument of the tag.

The next few tags affect the order that test methods are executed. Each of them are pretty self-explanatory.

@BeforeEach – With this tag, the specified method will be executed before each of the other test methods.

@AfterEach – Likewise, the method with this tag will be executed after each of the other test methods.

@BeforeAll – This tag denotes a test method being executed first in the order of all of the test methods.

@AfterAll – This tag denotes a method being executed last in the order of all of the test methods.

@Tag – This tag allows filtering or grouping of test methods by adding a custom tag name for its argument.

@Disabled – This tag causes its test method to be skipped.

While there are certainly more annotations in these Junit tests, I’m glad to learn the common tags for further testing in my Software Testing course.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

As class has progressed this semester, we have learned several testing methods and strategies. While perusing the internet, I found another intriguing test strategy not discussed in class called the Round Earth Test Strategy. This testing strategy turns the test automation pyramid on its head by adding spheres to the triangle.

At the core of these spheres is the Earth, that classic blue sphere we all know and love. We then add concentric spheres around the Earth sphere representing the different levels of testing. Add in some static and dynamic elements such as data and from this we can then take a big slice and lay it out, giving us our Round Earth Test Strategy. One will notice that it does, in fact, turn the test automation pyramid on its head as the base of the triangle is now on top. This maintains that during testing our attention must be towards the surface and the user experience. It also takes our attention away from the lower part of the pyramid which represents the lowest level of the technology, something we rarely test or even can test for that matter. The Round Earth analogy lends itself to good analogies and to deep reasoning as the analogy greases the mental wheels gets the gears turning. The presence of data in the test strategy reminds the testers about data and the model can show testing problems that can occur at multiple levels. Lastly, the model reminds the testers about testability.

The first thing that struck me about this model is that it keeps the user in the forefront of the testing. The author reminds the reader that the worst person to test a program is the developer themselves. The “curse of expertise” puts the developer in the “underground” of the model while the users are living on the surface of the model, a different world compared to the world the developers are in.

Another interesting thing that struck me was that the model puts an emphasis on data. Just recently, in class, we did some work with a half-finished program and tested it using dummy data. What strikes me was that while testing there was little to no concern for what the data actually meant and we only cared in the program compiled and passed the tests, and the Round Earth method puts emphasis towards that data.

The last bit that struck me was that this model lends itself well to the analogy and that makes it easier for people to understand. While this isn’t necessarily helpful for a good model it is always helpful when trying to explain it to your colleagues for a second opinion!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

As I take another step towards Software Quality Assurance Testing. I dive into the blog I found for this week blog post “Top Software Testing Techniques & Tools For Building Working Software” by Ekaterina Novoseltseva.  In this blog I learn about the 4  top testing techniques and tools for building working software. Software testing is very important for program development because it helps reduce the risk, time, and cost that comes with developing a new software.

Top 4 testing techniques important for building software

1. Unit Testing
   • Is used to test each small part of the software system to make sure it is working properly and does what is expected. “The goal of unit testing is to analyze each small part of the code and test that is working correctly.” as put in the blog I am summarizing. The following are a few of unit testing tools:
     • Junit
     • Phpunit
     • Mocha
     • Mockito
     • Chai
     •  Sinon
     • Jasmine
     • Jest, Ava
     •  TestNG
     • Powermock
     • XCTest
2. Integrated Testing
   • Is the act of combining unit test with each other in order to test the program until it is possible the majority of the program together. The way it works is by integrating more than one unit test that leads to a component and as it keeps adding to it becomes an even larger part of the program in order to see how well each unit runs together and how the software program will function. Another thing to note about integrated testing is “that integration test is also about testing units with databases or other external third-party libraries.” as dictated by the blog I am talking about. The following are a few of integration testing tools:
     • Mocha
     •  Jasmine
     • Jest
     •  Ava
3. Functional Testing
   • Is important for testing the quality of the software program and making sure it does what it is intended to do and function the way it should when ever the program is used by its users. “Testing is used to verify that your designed application, website, software executes its functions through a proper response to user commands, a consistent user interface, integration with other systems and business processes, and proper handling of data and searches.” As put by the blog I am blogging about. The following are the functional testing tools:
     • Jmeter
     •  Gatling
     • Supertest
     •  SoapUI
     •  Cucumber
     •  Robolectric
     •  KIF
4. Performance Testing
   • Is the testing process that test how well the software program performs under a certain workload by testing how well it respond and checks the software program stability. It also test the quality of the software by reassuring that the system not only perform as intended but that it’s reliable as well. The following are a couple of performance testing tools:
     • Jmeter
     • Gatling

This wrapps up the 4 top testing techniques and tools for building software. For more information on this read the blog  “Top Software Testing Techniques & Tools For Building Working Software” by Ekaterina Novoseltseva. This has been YessyMer in the World Of Computer Science, until next time. Thank you for your time.

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.

Sanity Testing

As a follow, up to my Regression testing post a few weeks ago, Sanity testing is almost a subset of it because it is performed when we do not have enough time to do the testing. It is used to carry out the checking on whether the bugs reported in the previous build are fixed with regression being introduced to fix these issues not breaking any of the previously working functionality. Sanity checks to see if the functionality is working as intended/expected instead of doing the entirety of regression testing. The test helps avoid wasting time and cost involved if the build has failed. After the regression introduction has been completed Sanity starts to kick into full swing. With it checking the defeat fixes and changes done to the software application without breaking the core functionality. It is usually a narrow and deep approach to testing, needing to concentrate limited and main features of testing in detail. Sanity testing is usually non-scripted helping to identify the dependent missing functionalities. It is used to determine if sections of the application are still working after minor changes.  The objective of this testing is to not verify thoroughly the new functionality but rather to determine if that the developer has applied some rationality while producing the software. For example, if your scientific calculator gives the result of 2+2 = t! then there is no point in testing the advanced functionalities like sin 30 + cos 50. Sanity testing is usually compared to Smoke Testing which is used after software building is completed to ascertain the critical functionalities of the program is working fine. But smoke testing is for another topic for another day. All and all the website I looked at was very insightful into what sanity testing is and what it does.

https://www.guru99.com/smoke-sanity-testing.html

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