The “Read Constantly” pattern is described as a way to create a strong base of knowledge and an even better understanding of the industry around you. There seems to be such a vast amount of information out there today that it seems very intimidating to even fathom where you should start. Reading is the best way to start learning more about the industry and more abstract yet fundamental concepts. The idea of reading everyday may seem like a lot of work at first but the key is to completely immerse yourself into the context of the text. Find new ways to apply what you learn to what you are working on and familiarize yourself with patterns before they become more popular and widespread. Another good way to read is to section parts of the book into manageable pieces to organize your learning experience such that it flows easier reading from one chapter to another. The book also talks about momentum when finishing books by allowing a brief but not long period of absence from reading. Find your next book and move onto it as fast as you can without creating a disturbance in your work life.

            This pattern was interesting because it showed me a way to read without making it too overwhelming. Every book I find on coding seems to become very overwhelming with the amount of content inside. The content itself becomes boring when reading for too long, it begins to sound repetitive which leads to a lack of interest. I found the tactic of breaking these large amounts of reading into smaller portions a great idea. I’ve been currently applying this tactic with great results as I can retain the smaller amounts of information better and this allows me to keep a more vested interest in the book. I also found that focusing on the portions of the book that interest you can make it easier to read. Focusing on ideas and aspects that you want to learn more than the rest makes the reading go by much faster. I agree with this pattern because of the amount of information that is available at all times to us. It’s very important to use our resources to the best benefit we can take from them. Books and online readings are everywhere these days and it makes information much easier to obtain, so to sharpen your skills you must broaden your skill set as well.

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

During the first sprint, our goal was to get everyone set up with the development environment so that we could all build the AMPATH project and get to work as soon as we were given user stories/had tasks. I believe of the time of the last blog post, we still had to finish getting one or two of my teammates set up, but that was resolved rather quickly. After that, it was learning testing in Angular while playing the waiting game for AMPATH’s team to get in touch.

And well, wait we did. That was no fault of AMPATH’s, though. They’re a rather small development team with a big project. They’ve got their work cut out for them and they’re seemingly very busy.

Unfortunately, with how busy they were, we didn’t get any new tasks to work on at all this past sprint. What was nice was that we got plenty of time to familiarize ourselves with angular and testing. Reviewing testing was important because, for the upcoming tasks we got, we’re trying to figure out whether or not we’re going to be using mocking or a real database with random values for our “back-end” data. If we go with mocking as AMPATH has suggested to us, then our time spent learning testing with Angular over this sprint will be put to good use. I’m also pretty thankful for my Software Quality Assurance and Testing course that I took last semester, because that went in depth about a lot of these same topics.

Overall, Sprint 2 was fair uneventful. However I feel as though my team got more accustomed to working with one another and got a bit more comfortable with each other, too. So for those reasons, I think that it was a positive sprint. I’m excited for the next few weeks of Sprint 3 so we can start working on some coding!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

This is blog post on chapter five “Perpetual Learning”, the book build on software development is composed of two primary activities: learning and communication. “The Perpetual Learning patterns are applicable for your entire career, but with the apprentice’s emphasis on learning”. For new developer, learning is the most important part. In this “Expand Your Bandwidth” pattern, they are talking the most important process for most of developer. Expand your learning, in this continuous new information business. We will never stop learning, so learn how to learn without being so overwhelmed is extremely important. I think this is important skill to have, although everyone learns differently.

In software developer, there is no “know all” skill. We are learning as we go, we learned the basic skill at school and more specific as doing project/job. So how to learn while working. The book suggest that we develop expanding our ability to take in new information. “The discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it” and this is what really think is the CSS learning model. We must be active learner; we use the tools we must keep up with news/ learn new skills/ communicate with others. They also suggest that we understand when to Expand You Bandwidth. This is different to everyone, but if you test out your methods and see which work best for you.

I am agreed with most of the points of this pattern. Computer science is active learning, there are million thing we could learn. We need to know to pick and learn what we interesting and benefit to our career. I heard on a tech podcast, one way to learn is to try use technology for a week. After that move to different tech and see which one is for you.

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

The Deep End describes the situation where you feel like your skills have plateaued and you are having difficulty finding ways to improve. As it sounds, The Deep End is a pattern that encourages you to “dive in” to the deep end. That is, to take challenges that you know you could fail, knowing at least that you can learn form your failures and improve yourself as a result. It is not about taking uncalculated risks or lying to get opportunities, it’s more about taking on things that you aren’t certain you could do, but have the means to do so.

The Deep End is a pretty intuitive pattern. When you feel like you aren’t improving, push yourself in ways you haven’t before and turn it around. However, it can be very intimidating in practice to take on projects that you aren’t certain you can complete, especially if you think you have to worry about potential consequences. Although learning from failure is a very effective way of learning, it can also be very costly, and that definitely gives me anxiety.

That being said, it is important to take risks and leaps in my life and my career. It is the only way I am going to improve myself and get what I want, and being too nervous to take chances and opportunities as they come my way certainly wont help. I will make note of the lessons taught by this pattern and try to take more risks in the future. I think it will especially help me with my directed study this semester, which has begun to push me into learning many new languages and concepts all at once.

The Deep End is a cool pattern, and the it makes sense practically. Most people are definitely aware of the idea of taking on harder tasks to sharpen their skills. Most people want to improve, but it can be scary to tackle hard challenges and face the unknown. However, getting over that anxiety is crucial to becoming a smarter, more well-rounded individual. Life isn’t easy, and you need to be ready to solve hard problems at any moment.

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.

We’re computer science seniors at Worcester State University so that means we should be able to write a full fledged technical documentation for the program we have written am I correct? Yes and no. We were taught the importance of writing documentation and very lightly touched upon what should be included in documentation but after reading ‘Software Documentation Types and Best Practices’ I learned there are actually different types of documentations for different projects.

The image below shows a general guideline for the steps to be taken when it comes to writing a project documentation.

We know that the main goal of effective documentation is to ensure that developers and stakeholders are headed in the same direction to accomplish the objectives of the project. The image below is a breakdown of the two main categories of software documentation:

The author then goes on and describes the different types of documentation:

System documentation represents documents that describe the system itself and its parts. It includes requirements documents, design decisions, architecture descriptions, program source code, and help guides.

User documentation covers manuals that are mainly prepared for end-users of the product and system administrators. User documentation includes tutorials, user guides, troubleshooting manuals, installation, and reference manuals.

Process documentation represents all documents produced during development and maintenance that describe… well, process. The common examples of process-related documents are standards, project documentation, such as project plans, test schedules, reports, meeting notes, or even business correspondence.

All in all I learned that there is not one special or main way to write documentation but there are actually many.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

CS 443 has taught me many things: how to test code, the different ways to test code, collaboration among peers, what is possible/not possible in Java, mockito, the list goes on. What it has not taught me is how code is actually tested in the field professionally; what should I expect to do or know if I were to shift towards the QA Engineer path?

‘A Day in the Life of a QA Engineer’ by AJ Larson talks about what he does in a professional setting and I compared it to the daily tasks we performed in class and it seems it is not completely opposite. He starts off by comparing software developers to QA engineers and stating that it is not too different; some companies even combine the two into one where you are a dev and a tester. He talks about how the team communicates; telling each other where they are in the project, what their plan is and if they have been encountering any problems. I guess in a way we have been doing that in class.

Onto the more important part of this blog is where he talks about testing ‘stuff’. He spends his time running manual tests and when he encounters a failed test how he goes about it. I learned that communication is key in both school and professional work environment; pretty much anywhere there is teamwork there must be communication.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Regression Testing

For this week’s blogpost I will be looking at an article from ReQtest that explains what regression testing is and its benefits. Regression testing ensures that previously developed and tested software applications are working the same as they were before recent code changes were done. Tests cases are re-executed to check to see if this occurs. Regression testing is needed when new features are added or when changes in requirements and code are modified per changed requirements. Bug fixing and fixing performance related issues are also instancing of when regression testing is needed.  When a system is changed errors may arise, this is when regression techniques come into play.

• Retest All: this re executes all the tests that exist in the test bucket. This usually requires a large amount of time and resources making a very expensive resource.
• Regression test selection: this executes the selected part of the test suites for example re-usable test cases or obsolete test cases
• Test case prioritization: Prioritization of test cases depends on business impact and used functionalities.

The benefits of regression testing come from its basic idea, when your system is not working prior to changes made. Regression testing increases the possibility of tracking bugs caused by these new changes. It also helps in finding unwanted side effects that might have been caused due to a new operating environment. Of course, this will help identify bugs and errors in the early stage as well. Where this probably shines the most is when constant changes are required in the product. There are different types of regression testing as well. Corrective regression is used when there are no changes introduced in the existing product specifications, usually used to conduct a desired test. Progressive Regression is used when modifications are added in the specifications of the product and new tests cases are created. There are many more types of regression testing that is listed in the article such as Selective, Retest-All and complete regression. Some of the best tools for regression testing are WinRunner, QTP, vTest, Regression Tester and AdventNet QEngine.

All and all I thought this article was very informative, as I learned about a new testing method I have yet to learn or know about. It also seems to be very important especially if your system is working then after a change something goes wrong after said change occurs.

https://reqtest.com/testing-blog/regression-testing-types-techniques-tools/

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

CS443 Blog Post

https://reqtest.com/testing-blog/bug-report-template-good-bug-reports/

For this week’s blog I looked at bug reports and a template to perhaps help create better bug reports. Firstly, a software bug essentially is an error that produces unexpected or incorrect results, therefore when something is not working in the software as it should be it is inferred as a bug in the software. A bug report is a document that is extremely useful in communication to the developers that tell which parts of the software/application are not behaving as expected. These reports should have enough information that helps the developers pinpoint the exact issue helping them resolve it. The quality of the bug reports is crucial as a high-quality report reduces the chances of the bug in the future. While a bad bug report may cause the developer not to replicate the bug and not be able to fix it. Well what does a good bug report consist of? Well a good bug report has the following characteristics

• A good bug report has a unique identifier number to easily identify the bug and set it apart from the rest
• It contains all the information required to reproduce the bug and fix the issue while prioritizing the bug for fixing and outlining the expected behavior
• It usually covers a single bug, for multiple issues multiple reports should be created
• A good bug report can be easily understandable by the tester and the developer, implicating that the bug report should portray the same meaning between those who created the report and those who will be trying to fix the bug
• A good bug report follows a standardized bug report template while promoting collaboration between others and allows the bug to be fixed in the shortest amount of time

Bug reporting software’s such as ReQtest will help you in your bug tracking initiatives. Usually bug reporting software will help you report, document, store, manage, assign, close and archive bug reports. ReQtest is one of these tracking software’s that allows you to create a professional bug report. The template consists of fifteen different fields of information ranging from the ID number used to uniquely identify the bug report to the frequency of the bug occurring to the linked requirements that are linked to the bug report. Looking at the site you can see what each field requires and does exactly. Finally, after the bug report template has been used a checklist is usually required. Is the bug report clear to follow? Was the bug reported previously? Have you tried to reproduce said bug with the help of your own bug report? And so forth.

I thought this article was interesting as it gave me some good insight on how a bug report should be and such. The way it explains the bug report template is straightforward to pretty much any audience along with the entire article which is very nice to newcomers of the topic. Coming into this I had a general idea of what bug reporting consisted of but this article made me understand more of it. Overall I liked this article as it was informative and straight to the point.

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