For this week, I chose a blog which talks about the future of software testing. Although these are just predictions by Ryan Yackel who is a senior sales engineer at QA symphony, they really seem plausible and get you thinking about where software testing is going to be in the next decade or so.

Ryan talks about how Everything will be blurry in the beginning and gets clearer after. what he means by that is the fact that agile software development methodologies are now becoming the standard and that will lead to a lot confusion and misconceptions. Because everyone is considered tester in a agile environment which is not true in a lot of cases, this really leaves testers questioning the severity of their role.  Agile methodologies’ popularity is increases among companies and they will soon have a better understanding and mastery of these agile techniques. Once this occurs, the role of a tester in a agile team will become much clearer. This leads to his next prediction.

Software testers expectation is on the rise and Ryan mentions that the expectation will be even greater in the future. Now, software testers need to expand their horizons and embrace new enterprise software testing tools and strategies. Just being knowledgeable about testing software is no longer sufficient. Software testers needs to be knowledgeable about software development, code functions, business logic, and technical competency. Testers a now playing an assertive role in guiding software quality assurance and development broadly.  As a tester, if you fail to adapt to these new higher level expectation, you will have a hard time making it through.

Ryan also talks about how the use of automated testing will increase significantly. It will be difficult for companies to maintain efficiency due to fast growing data in software development. Therefore, many companies will rely on automation in order to maximized their level of productivity. Ryan predicts that automation will become the default method of testing and all the challenges that holds automation testing from being the best way to test software will soon be refined.

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

This week I decided to read a blog post for my blog entry. The blog post I read is titles “Writing Clean Code” by Jason McCreary. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

One major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have everything labeled to where my audience can understand. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

Source: https://dev.to/gonedark/writing-clean-code

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

The podcast episode this post is written about can be found here.

This week I listened to a podcast in which the podcasters stage an argument between a 1990s “traditional” test manager and a modern test manager. I chose this podcast from about 4 I thought sounded interesting, because I wanted to know the current state of the industry and where we came from. It was enormously helpful in demonstrating the difference in how software gets tested these days compared with how it was done previously.

The one playing the role of the 90s manager explains how at his company, testing is kept largely separate from development. After software is implemented, it’s sent to software testers, whose job it is to find bugs. If they do find bugs, the project is sent back to the developers for them to fix. The second round of testing might reveal that the bug wasn’t fixed after all, and the result can be an endless game of ping-pong where the product doesn’t get released for ages.

Laid out in this way, it was clear how this inefficient setup led to the modern strategy of integrating software development and testing. The modern test manager explains that at his company, test specialists are embedded in the development team from the beginning, and the whole team is in charge of ensuring the quality of the product. The developers actually write most of the tests for their own code as they go along and end up finding most of the bugs. Test specialists may write more complex tests or write diagnostic tools, but mainly their job is to see the big picture and make sure that all the testing that needs to get done gets done. In fact, the modern manager says that most of the bugs that the team members who specialize in testing find don’t find them through writing typical tests or test automation, but through data analysis and looking at how customers use a product.

I gathered through listening to this conversation unfold that the basic idea of the modern setup is that catching bugs earlier makes them way less hassle to fix, so testing isn’t pushed to the end. Everybody in the team is capable of doing everything required for both implementation and testing, but they each specialize in a particular area. Going forward, I’ll make sure I don’t conceive of the testing process as entirely separate from the development process, but rather as something that goes along with code implementation in order to prevent headaches down the line.

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 blog post, John Sonmez talks about “soft skills” and how they can help you become a better software developer. Here are some tips from the author:

1. Instead of trying to learn several programming languages at the same time it’s better to have one language that you know in and out, that you are comfortable writing.
2. Structure your code well by writing “good, clear, understandable code that doesn’t require a large amount of comments because the code itself is communicative.” – John Sonmez
3. Having a good understanding of object-oriented design and managing complexity as most popular languages rely heavily on object-oriented design and analysis.
4. Understanding how to create algorithms, and how to modify known algorithms to match your specific needs.
5. Understanding of data structures like arrays & vectors, linked-list, stacks, queues, trees, hashes and sets. These are important to know well, especially if you are being interviewed.
6. Knowing a development platform well is a good idea because some places design for specific platforms (PC, Mac, etc)
7. Learning a framework, or a complete stack. “A framework is simply a set of libraries that are used to develop code on a particular platform or on multiple platforms.” and “A stack is a set of technologies, usually including a framework, that are commonly used together to create a full application.”
8. Basic Database Knowledge, how to add, modify, delete and work with different database systems.
9. Source Control, understanding how to use tools like GIT.
10. Testing, more often projects are being created in small increments and tested as they go, this is allowing developers to catch bugs before they begin to cascade.

I chose this resource because I’m always looking for information on becoming a better software developer and want to become an asset to wherever I dedicate my work. Some of the information is general information but I do think it’s important to work on maintaining these core skills to improve the quality of your work. I learned the importance of working on knowing at least one language very well, along with knowing one platform very well knowing how to implement popular data structures, writing good algorithms and knowing when to use what. I learned the importance of object oriented design and how prevalent it is today. I learned about frameworks and stacks and what they are, and the importance of understanding how databases work. I also learned that more recently developers are being expected to know how to test their code, especially with agile testing.

The post The Technical Skills You Need to Have as a Software Developer 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.

We recently went over how to test our programs and code using decision table testing. Decision table testing is extremely useful for laying out the requirements and conditions so that it is easier to comprehend and understand. This blog goes over, in detail, how to set up a decision table for a problem with an ATM and what conditions must be met to withdraw money. You can find it here: http://reqtest.com/requirements-blog/a-guide-to-using-decision-tables/ (I also used their pictures.)

I chose this blog to share with you because it relates directly to the assignment we were given for decision table testing. It has a section before the steps that give you the advantages and disadvantages to using the decision table which I thought would be useful to know and highlight. It also has every step for creating a decision table and is easy to understand.

“One advantage of using decision tables is that they make it possible to detect combinations of conditions that would otherwise not have been found and therefore not tested or developed. The requirements become much clearer and you often realize that some requirements are illogical, something that is hard to see when the requirements are only expressed in text.” – Ulf Eriksson, ReQtest

This advantage to decision table testing is a big one. Being able to easily cover every single case without being confused is extremely helpful. Essentially, decision tables give you a visual to go with the words.

The disadvantage to using decision table testing is that the decision table does not represent the complete test cases. Meaning you will have to think a little harder about how you write your cases.

With this being said, decision table testing can be used anywhere and this blog stresses that the tables should be constructed during system design so that the designers and testers are able to take advantage of the tables.

The steps are pretty easy to creating a decision table, the blog goes into more details with pictures (I recommend checking it out).

First, you want to figure out the conditions and actions in your problem. Conditions will be a requirement while actions will be the thing that happens if specific requirements are fulfilled.

Second, You want to figure out how many rules you are going to have. This is found by 2^n where n is the number of conditions in your table.  Your going to want to fill out your table with the different possibilities of conditions being true/false.

Third, you want to reduce your table by combining redundant cases. The “-” means that you don’t care if credit is granted sense you have enough money in your account regardless.

Notice how Column 1 and 3 were the same? Now they are combined.

This is the final table you would use to write test cases for this program! Overall, Decision Table Testing is a great way to lay out all requirements in front of you to ensure you do not miss any possible combinations of input!

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Source: https://blog.codinghorror.com/flattening-arrow-code/

Stumbling across this week’s blog post Flattening Arrow Code by Jeff Atwood, I found myself reading about arrow code, which is self-explanatory. Basically, Jeff explains how he deals with Arrow Code, which is considered an Anti-pattern that is deemed a bad practice and should promptly be avoided wherever possible. The main benefit from refactoring is to reduce the cyclomatic complexity value, this value being used to determine how complex a piece of code is. The larger the value, the higher the complexity, the lower the value, the lower complexity. Another would be, from Jeff’s words “…to have code that scrolls vertically a lot… but not so much horizontally.”

When I look at code, I never suspect that there would be distinct patterns that are deemed as a bad practice. By reading about arrow code, I first thought, “Hey, I’ve seen that before” but left with “Oh, that is probably not the way to go about writing code”. In other words, I should probably learn this now. Anti-patterns, although the only one focused on in this blog is the arrow pattern is a great way to help avoid certain practices in the future. Even though, as of right now, I don’t understand most of what he said about converting negative checks into positive checks or decomposing conditional blocks into separate functions. Other things like guard clauses, being a conditional statement at the top of a function that bails out as soon as it can. Which I assume contributes to reducing time spent/resources spent running that function. Also, includes the idea of not sticking to the idea that there should only one exit point at the bottom of the function. Sometimes, it can be possible to exit at a different point rather than the very bottom. These two points, are good information as standalone practices.

Using this simple example, I can see that it is like YAGNI, KISS, Code Smells, etc., which means by understanding or being introduced to the bad practices early on. One, I am able to identify and solve the problems using common strategies already developed and tested. Two, I will be able to avoid putting myself into those situations where I would need to refactor the sections to be easily modifiable and maintainable. Although cyclomatic complexity is mentioned scarcely in the blog post, it reminded me of time complexity in algorithm analysis. Even though they are two different concepts, understanding that aiming for a smaller cyclomatic complexity value should result in a less extensive testing phase for the code. Which should save time, for future reference of course.

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.