In this blog, we are talking about test plan. Test plan is one such important testing deliverable offered during the release of the product. A software product, once developed and tested completely, is prepared for its release, during which various documents, reports, screenshots, etc. are also delivered to the client and other stakeholders of the project. Known as deliverables, these documents and reports are an integral part of software development life cycle (SDLC), in my last blog, as they necessary information related to the product to the concerned individual.

Test plan encompasses all the activities performed during the testing process. A test plan document offers all the necessary and relevant information to the developers, business managers, as well as the customers. There are different types of test plan:

• Level specific test plans: These include Unit test plan, Integration test plan and system test plan.
• Type specific test plan: these include plans for major parameters like performance testing plan.
• Master test plan: This is one single big plan combining all the other plans to be carried out on the software product.

Test Plan Template, the testing team or the test management team ensures that it follows a set template, which allows them to log all the necessary details about the testing process in the document. There are fixed set of parameters such as test items, testing approach, pass/fail criteria, approvals … there are all defined by the standard IEEE 829.

Creating a test plan by following guidelines, to make sure to create test plan accurately. It is important for them to consider few guidelines, which can assist them in recording all the necessary information in the document with precision. Create a concise test plan, with all the necessary information. The information provided should not be redundant and superfluous. While preparing a test plan it is necessary for the team members to be specific and precise. Create points, list, and tables wherever necessary, to increase the readability of the document. Review the document constantly before it is released with the product. Update the test plan with all the recent changes and modifications.
We know to make sure the test is in good quality, we need to know what we are looking for in testing. A testing plan would help us, a well written test plan ensures that all the aspects of the software are covered and tested. This combine with a check list would make further ensure the accuracy of out test.

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.

Today I read an article on baeldung.com about HashMaps. I have used HashMaps before in Data Structures as well as Unix systems and have found them to be a very resourceful way to store and retrieve data. Most developers know about HashMaps but don’t completely understand how they work, in todays blog we will be cover HashMaps in JAVA.

HashMaps have an inner class called an Entry Class which holds the key, values and will return a value at the end. Two important main methods in the class are put() and get(). put() associates the specified value with the specified key in the map, it checks if the key given is null or not. If the given key is null, it will be stored in the zero position. The next internal part of the put method is that it fits the values inside of the limits of the array. The get() method is very similar to the put method but instead of storing, it returns a value. Get() gets the hashcode of the main object and finds the location of it in the array. If the right value is discovered, then it returns the value but if it cannot find it then it returns null. Put() and get() are two major internal parts of HashMaps and looking back at some of my old projects with HashMaps I now fully understand what is going on internally when I execute the program. I will use HashMaps more frequently in my projects now and I hope that after reading this you will be able to understand HashMaps better and will be able to give them a shot.

https://www.baeldung.com/java-hashmap

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

Welcome back to Dcanton’s blog. This week I’m going to be talking about  a blog posted on Apiumhub, a tech hub that specializes in software architecture. The blog talks about the benefits of unit testing. The author starts by giving the goal of unit testing which is to segregate each part of the program and test that the individual parts are working correctly. He then continues to list why it is beneficial. One of the benefits is that it improves the design of the program, it makes you think about if your code is well defined and if it reflects what the outcome is supposed to be. Another benefit of unit testing is that reduces cost long term, since bugs are found earlier in the process, they won’t be as costly and much easier to fix than later in the process.

I chose this blog to discuss this week because it has a lot of information on how effective unit testing is. Since there are other ways of test such as black box testing and grey box testing, this gave me a good understanding of it and the benefits that come from using this method. One thing I learned is that white box is tested by tester while others are tested by developers. Thank you, Dcanton blog will be back next week with another blog

https://apiumhub.com/tech-blog-barcelona/top-benefits-of-unit-testing/

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

Hello, again my friendly neighboorhood readers!

This week I have been again been reading up on those crazy Antipatterns I discovered week. As you can probably tell by the title, the Antipattern I am writing about this week is a Halloween themed Antipattern. I know it’s a little late but today’s Antipattern is the Poltergeist.

A Poltergeist is a class that has a limited role to play or limited responsibilities in a system. This practice adds unnecessary abstraction and their short life cycle means more wasted resources. Poltergeists normally appear to initiate some other action of a class that has a more permanent status. A Poltergeist is easily identifiable as they will typically bear the “_manager” or “_controller” title in their name. The main three disastrous effects of the Poltergeist Antipattern is a waste of resources every time they are called, they utilize redundant navigation paths, and the clutter the object model, getting in the way of proper object-oriented design. If a Poltergeist Antipattern is left alone it can result in such occurrences as transient associations, stateless classes, redundant navigation paths, short duration, temporary classes, and objects, and single operation classes. Some typical causes that lead to a Poltergeist Antipattern manifesting are a lack of object-oriented architecture, using the incorrect tool for the job, and of course, a specific disaster such as management incompetence.

Now how do we fix this Poltergeist problem? Well, they gotta go. Of course, once the Poltergeists are gone, the functionality they had must be replaced with an adjustment to the architecture. Another solution is to utilize the 80% solution that we discussed in the post discussing the Blob Antipattern.

Now, I do not know about you reader, but I believe that this is definitely an Antipattern that every programmer falls prey too, especially when they are beginning. I can think of many programs that I have many over the years that have had at least one Poltergeist stalking around in them. This does make me rethink how I will program in the future. While the programs I may write now do not need any real optimization, in the future, optimization is going to be a required skill for me.

Well, that is it for today readers. Have a good week until next time!

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.

We learned about Model-View-Controller in class but there are more software architecture patterns, there are different layer is useful for different design. This blog is based on the book Software Architecture Patterns, by Mark Richards, Boston-based software architect who’s been more than 30 years about how data should flow through software. The author made top 5 software architecture patterns, which show how to choose them.

Layered (n-tier) architecture, this architecture arranged so the data enters the top layer and works its way down each layer until it reaches the bottom, which is usually a database. This is where the Model-View-Controller (MVC) structure, as we know, is the standard software development approach offered by most of the popular web frameworks, is clearly a layered architecture. Best use for: New applications that need to be built quickly, enterprise or business applications that need to mirror traditional IT departments and processes and applications requiring strict maintainability and testability standards.

Event-driven architecture helps manage this by building a central unit that accepts all data and then delegates it to the separate modules that handle the type. This architecture is easily adaptable to complex, often chaotic environments, scale easily and easily extendable when new event types appear. This type of architecture best for asynchronous systems with asynchronous data flow, applications where the individual data blocks interact with only a few of the many modules.

Microkernel architecture, the basic routines for displaying a file and editing it are part of the microkernel. The solution is to push some basic tasks—like asking for a name or checking on payment—into the microkernel. Good use for this architecture is the applications with a clear division between basic routines and higher order rules and the applications with a fixed set of core routines and a dynamic set of rules that must be updated frequently.

Microservices architecture, the goal is to create a number of different tiny programs and then create a new little program every time someone wants to add a new feature. It’s used mainly when the different tasks are easily separated. In many cases, different tasks can require different amounts of processing and may vary in use. Best use for this is websites with small components, rapidly developing new businesses and web applications.

This is interesting architecture layers type, it is important to know and compare to real life application. I hope we more type to know more about the architecture, specially about website.

Link

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.

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. SDLC refers to whole process of software development. It defines and describes, each and every phase that contributed towards the development of the software.

What is the need for SDLC? Software Development is a tedious and complex job. As such, standard guidelines and established framework works well to carry out the development process in an effectively organized manner, repeatedly for each unique software product. Segregates the process of development life-cycle into separate phases, for their independent and smooth implementation. And to minimize failures in a software project. There are six phases of Software Development Life Cycle in a subsequent manner:

Requirement Gathering and Analysis: This phase visions the gathering of business requirements, followed by the analysis to study and validate the feasibility of these requirements for implementation in the system. Client and Project Manager are the key persons in this phase.

Design: blueprint/software design is prepared, based on inputs, provided from the requirement gathering and analysis phase. This blueprint helps in determining the requirements, needed in the development of software such as hardware and system requirements. The outcome of this phase is software design.

Implementation: The software design is implemented in this phase through coding and programming. This phase generally involves modules and codes. This phase is developed or working software product that acts as an input for the next stage.

Testing: developed software is handed over to the testing team, to evaluate and validate the functioning of the software product, in accordance with its pre-defined requirements and meet the end users’ expectations.

Deployment: After getting through testing phase, successfully, software product is ready to get deployed on customer’s side for its use

Maintenance: Maintenance phase is all about resolving defects or issues, occurring on the customer’s side, while using the software product. It ensures the fixing of all issues post the deployment of software product at the customer’s site.

This is the main steps of software review, it is a standard practice that empowers organizations to follow systematic & well-defined approach, for carrying out the development in an effective way, so as to achieve desired software product of highest quality. I find this blog helpful to follow and make sure product is going to the direction.  These steps need to apply to future product., as I have seen so many products got issues and have to call back.

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.

For my final blog for “Software Design and Architecture” this semester, I decided to research time management for doing software projects. This is an issue that I ran into creating my final project, and I thought it would be worthwhile to learn from my experience while it was fresh in my mind.

I thought this would be particularly helpful because I would like to do a few projects for fun over the winter break. I don’t think that I’m alone in that without a looming deadline, what little time management skills I have tend to go out the window. I hope this will change this time. I doubt reading an article will transform me into an extremely productive person, but at least it might point me in the right direction. I can only hope.

The article that I found was from *codeproject.com* and was titled “Time Management Tips for Developers.” I thought it gave some good pieces of advice. Even if you are not a software developer, you could benefit from all the advice given. I will focus on three pieces of advice that I would like to work on.

“Set your goals: long term and short term”: This is something that I know I should be doing, but I never do it in a methodical way. I make myself a goal, but never stick to it. I also never write it down, either. It is an incredibly lazy process. Which, funny enough is the next point.

“Do not plan in a lazy way”: Guilty as charged. I don’t put very much effort into planning. It’s no wonder I don’t stick to it. However, I have found it is sometimes hard to plan a project that I have never done anything quite like. Strangely enough, this thought was the topic of the next point.

“If you can’t plan, just track”: You should keep track of what you are able to get accomplished in a day and note where you waste your time. This seems like something incredibly useful for accurately gauging how your time is spent. It is too easy to either get discouraged or have false enthusiasm because you have either under- or overestimated how productive you were.

It seems like the author has some experience in doing projects like I am doing. It is really impressive that he can follow my thought process when reading one point and have the next point agree with what I was thinking in the next point. There were several other points that were good as well. I highly recommend checking it out.

Work Cited:

https://www.codeproject.com/Articles/11502/%2FArticles%2F11502%2FTime-Management-Tips-for-Developers

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.