Imagine being several years into your role as a developer; you’ve had a long week, a big project to push tomorrow and suddenly… you’re stuck on something. And you’ve double-triple-quadruple checked to make sure everything is working by code review but you cannot put your finger on how it is not quite perfect. What’s wrong? Let’s find out.
This is the first course-related podcast I’ve listened to for a blog post and if this is one of the only podcasts you will listen to, I recommend this one.
Jonathan Cutrell started off the podcast by saying “If there’s one thing that makes developers self-conscious it’s probably their googling history–more specifically things that they google that they forgot how to do.”
People can talk about code for days but they do not talk about the toll of what a developer thinks of themself when they are stuck on a part of their code or need to rely on the internet for something. This honesty makes it easier for university students and entry-level developers to understand the pace they are learning at is their own and that not everyone is perfect at coding even after years of experience.
Something that changed the way I thought about this is how important it is to know the pattern or routine of a concept. Things Cutrell says great developers care about is how understanding patterns and principles transfers but not necessarily the actual code itself. “Great developers” focus on the overall concept instead of wasting time on the small details of a language.
Due to this thinking, I realized I never considered how a developer can be the best of the best in one language but if they had to convert it into another language, the translation would be a little different. The real life comparison to this would be if someone were speaking with broken English. This does not mean they are not smart in any way, it’s saying that they are focusing on the main idea instead of a small detail they are trying to get through. They use their time more efficiently by moving on to a big concept instead of worrying about the syntax that they can easily google.
Overall, I appreciate what this article brought up as I was expecting it to be about just googling things but it dug a little deeper and mentioned what a good developer should focus on.
Podcast Episode: https://spec.fm/podcasts/developer-tea/204292
A few weeks ago, I was introduced to JUnit testing in my Software Quality Assurance & Testing course. The blog post tutorial linked below is one I would recommend to those interested in learning about assertion. Reading this post has helped me review the concepts I have learned and I will share what helped me better understand the topic of writing basic assertions with AssertJ.
I found this content useful as it started off by covering whether a user had Maven or Gradle for declaring the dependency and then we get to dive into scenarios when a certain feature would be used. Some examples of what you can test with assertions includes: boolean values (true/false), whether or not something is NULL, comparing the result with a number or string (EqualTo()), object references, and arrays that are equal.
There is a walk-through of what we want to test with a basic scenario of when we would want to use it and this information makes me appreciate how much this kind of testing helps simplify things. It adds more structure to what we would like to do and by being able to import it, saves us so much more time in the end.
Honestly, in class I tend to spend more of my time trying to follow steps instead of absorbing what the material is and this article really helped me realize things like “oh, so this is why we use this line of code” or “so that’s why this is always there.” As a visual person, I appreciate the articles which actual include code examples for us to see what’s being used or added to explain a concept which was very helpful in this case. I do not disagree with any of the content provided as it is much more technical and there is reasoning behind each part of the process.
Overall, I would keep this article bookmarked and may come back to use it as a reference whether it be for a future testing assignment or just for trying to refresh this in my memory. As a side note, installing gradle on our laptops in class enabled us to run our tests through the terminal which was a pretty cool experience.
In my software design course, I recently learned about how using design patterns helps you code better. I thought it would be a good review to go over the concepts this article introduces and potentially link it to things from class and maybe even add some things we did not get through during class.
The three categories Frederico Haag, a computer science engineering student at PoliMi, wrote about are creational patterns, structural patterns, and behavioral patterns.
Based on the design pattern I chose to work on for my individual assignment, I wanted to focus on the facade section–which is a structural pattern. The main take-away of the facade is how it “provides a simplified interface to a larger body of code.” I like how the name itself actually relates to the word facade’s definition: “an outward appearance that is maintained to conceal a less pleasant or creditable reality” (Dictionary.com). As a person who likes the aesthetic side of things, this seems like a convenient design pattern, especially if people who are not working on the code end up seeing it; it may be less overwhelming to some.
Another one of the options my class had for the same assignment above is for the decorator class–which is also a structural pattern. This “adds behavior to an object dynamically without affecting the behavior of other objects from the same class.” For some reason, when I imagine this concept, I think of a decorated cake. Since it is useful for adding the same behavior to many classes; it’s like when you add a spread-out layer of fondant or frosting to a cake, it could either cover the whole section(s) of cake or just some, but it doesn’t mess up the inside of the cake.
Overall, I found this content very useful to reiterate what I had learned and Haag incorporated visual UML diagram examples along with actual snippets of code to help us compare and contrast what he was showing. The content has not changed how I think about the subject because there is no arguing here, it just shows different ways people can structure their code overall. I do appreciate how Haag also listed “typical use cases” for some of them as it makes it easier to imagine.
“Forget about automating your regression tests” is some bold advice from Bas Dijkstra, who has experience as a test automation consultant. It made me wonder what exactly led him to making this kind of statement on regression test scripts and his article, On Ending the Regression Automation Fixation, covered various reasons why.
Two reasons why Dijkstra says starting with automating your regression tests is not ideal includes regression scripts being too long and how regression tests are written from an end user perspective. I find this interesting as a lot of software bloggers are saying automation is not always going to be the answer and their answers have yet to make me disagree.
The reason I chose this is because I am drawn to honesty; two examples above were explained with scenarios with failures Dijkstra has faced from creating inefficient or “plain worthless” cases.
This content will change the way I think about creating potential testing cases as there will be questions to ask myself before proceeding with the task(s) at hand. There will be a lot of reflecting on what could be consuming my test time, which parts are too repetitive, or what can just be done better. I mean of course I’ve already been considering these questions but now there will be a more conscious effort to think about them.
Dijkstra’s process especially considers the difference between how many scripts there could be when a computer is trying to translate what a human could have performed when testing. I realize how that would be an issue when trying to understand what could have went wrong or does not match up fully when there is less (specific) feedback when it comes to automation.
Thanks to this article, I will also try to predict how many layers of regression scripts would be too much of a hassle to develop ways for communication between what is being tested under the application. Overall, this information was useful as we should be reminded that “automation is meant to make your life and testing applications easier”; it should make sense and not be done at random, especially for regression testing.
As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.
Although I knew of the current trend(s) for the most part, I was surprised to see what Apiumhub had to conclude on software outsourcing. It shows an infographic where of the people who did outsource software development fully or partially, only 10.06% of them were “absolutely satisfied” and 51.57% were “somewhat satisfied.” Based on what I’d been hearing of people being worried of getting all the tech jobs outsourced, maybe the scare isn’t as bad as people led it on to be. I mean of course, the total majority of responses from that fall under “satisfied” but it was not fully satisfying—this would probably be best for quick, short-term fixes or work. Which shows how there is still more to people-to-people communication in the company’s direct workforce and it puts my mind at ease a little more.
To kick off this series, I wanted to introduce why Software Quality Assurance (SQA) testing is important not only for testers to understand, but for developers as well. From my experience, I’ve become familiar with manual testing and exploring different types of automated testing for web applications. I wanted to know a little more about how being a good developer also includes being a good tester and found an article on SimpleProgrammer which reveals the importance of knowing how to test.
John Sonmez, the founder of SimpleProgrammer, says that he “owe[s] a large amount of the success [he] ha[s] had in [his] career as a software developer to [his] background in testing.” I can see why he feels that way, as using just a little more time to double-check what you have created could save you even more time in the long-run. For instance, if something you have spent hours working on seems complete and you do not double-check it and pass it on to a QA team, you have to wait for someone in QA or a testing platform to check it. That could take anywhere between minutes to a few days or more. Once it is QA tested, maybe a bug is found and your task falls back into your hands again.
Could the scenario above been preventable? Yes and no. It is a true that “you can never find all the bugs or defects in a piece of [theoretical] software and you can never test every possible input into the [theoretical] software” but you can try your best. This doesn’t necessarily mean having to do your own end-to-end regression testing through the entire software each time you add a minuscule feature but you should thoroughly check what you have changed and the features directly connected to it.
The article continues to describe common testing forms and what they each mean for developers. Sonmez supports the Agile cycle of software development and describes it in the article as well.
Hey guys! This site is going to take a slight change in direction for the next few months; it’s my last year of college so your girl is going to feature some CS content for classes.
Stay tuned for more!
P.S. Please excuse my double-intro.