Author Archives: adestinyblog

Software Technical Reviews

Last week we covered software technical reviews and we got to experience it with in a group of five developers. There are a few different types of reviews like walkthroughs, technical inspection, and audits. Walkthroughs are informal and often between colleagues, where technical inspections are conducted formally by a carefully selected team. As for Audits, that is typically conducted by an external group like a software quality assurance group, a project group or outside agency whose main concern is conformance with expectations. This is an important topic because in software development, we will always be in teams where we work with each other’s code. Therefore, technical reviews allow a developer to receive feedback on how to improve their code’s style, structure, or even how to write better comments. Although we did not have an in depth practice with the technical review, we were able to fill in the roles in a review. I was an individual reviewer, my job was to be technically inclined and not have any bias or personal agenda on the work product. The goal was to find issues in the code and document them by location, line number, item type, and severity on our individual reviewer spreadsheet. Even though technical reviews are supposed to be brief, I had to run the code and understand the SirTommy solitaire game to provide a better feedback. I did find a few issues; our group came up with twenty-four issues in total.

Software technical reviews are beneficial in many areas, however as a recent college graduate, it is important to understand that reviews will help us improve our code and conform to company standards. Every company may have a different standard on how they structure their code, so I can see how reviews are extremely useful when It comes to training new personnel. Personally, after college, I hope the company I work for will conduct reviews, so I can quickly adapt to their coding standards. This will not only lead to improvement, but also strengthen the communication among all developers.

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

Test Automation vs. Automated Testing: the difference matters

More companies are gravitating towards practicing continuous development. When it comes to a DevOps and delivery model where software is constantly being developed, it is important to know that there’s is a difference  between test automation and automated testing.  Automated testing is the act of conducting tests via automation as opposed to doing them manually. Test automation is automating the process of tracking and managing different test. in this article, Kyle McMeekin explains how test automation is a huge when it comes to continuous testing.

If something stalls or break down during the development pipeline, this can drastically delay the delivery of the following releases. This is a roadblock in a continuous testing environment because speed and consistency is imperative to support a continuous testing model as McMeekin describes. Test automation eases the burden of tracking which environments have deployed new code, when each piece needs testing and how those requirements integrate back into the moving process of continuously delivering software; it does all that through automation leave more time for testers. The extra time can be focused on creating effective test cases to ensure the quality of the software since they’re no longer bogged down in managing all the minutia of testing needs. Continuous development and DevOps are becoming the norm and so will continuous testing. with the help of test automation, managing the changes that comes with injecting testing throughout the entire development pipeline can much easier.

https://www.qasymphony.com/blog/test-automation-automated-testing/

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

The Future of Software Testing

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.

Introduction

Welcome to my blog for Software Quality Assurance and Testing.

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

The Software Craftsman chapter 11 & 12

Chapter 11 is titled “interview anti-Patterns”. This chapter talks about the wrong processes to go about conducting an interview as a developer. They should avoid doing things like being a smart-ass interviewer, using brainteasers, asking unnecessary  questions, and trying to seem superior in knowledge. After we’ve worked hard to find a qualified candidate, the last thing we want to do is steal the opportunity they have to shine. We want to convince them that our company is the best they can work for, because a good developer will also be looking for a company that is best for them.

Chapter 12 talks about the cost of  low morale and how unmotivated people seem to represent that very well. Unmotivated people tend to destroy companies because this can change the motivation of other workers significantly. I believe that the attitude of the people you work with can have a huge impact on the way you work; they can either motivate you or suck the morale out of you. In this chapter we learn that people become like that and that is mostly due to companies beating the passion out of developers. Manager and agile coaches are the last people to motivate developers because they are demanding and punctual about everything. The only person that can motivate a developer is another developer. Not just any developer, but a software craftsman that every team needs.

 

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

The Software Craftsman chapter 9 & 10

Chapter 9 talks about recruitment, essentially how recruiters should go about searching for qualified developers. One of the problem with finding developers is how recruiters write their job description. Adding things like years of experience, academic background, certifications is how most companies job description looks like. I have done a lot of job searching in this field and i can agree that most of the description are just specific requirements needed from developers. They fail to focus on the companies culture and values and that is why they are not satisfied we developers they’ve hired.

Chapter 10 continues the previous chapter and talks about what to look for in an interview. Just like a job description should not always list specific requirements, a developers resume shouldn’t be just about knowledge and years of experience. During an interview, recruiters should be looking for passionate developers who are willing to learn or try new things. Those are the developers where if you put them in the right environment, they can really shine. One thing i can agree with from this chapter is that developers should interview other developers. A good developer will know what their company needs and what to look for; they will hire developers that are even better than they are.

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

The Software Craftsman Chapter 7 & 8

Chapter 7 addresses a number of technical practices such as TDD, pair programming, SCRUM and their usefulness in improving our software delivery process. These agile methodologies are about delivering value to customers in the shortest time frame possible. Even though these practices are very effective in the software development process, it is difficult to convince manger to adopt them. Many companies do not use these practices because they fail to identify why they need them, when to use them, or simply does not believe that they are effective. It is not easy to get developers to adopt to these practices because there is a learning curve and it will take some time to understand. To figure out which practices to use, first we must know what area we need to improve and what we are trying to achieve.

Chapter 8 is titled “The long Road”. This chapter is perfect for aspiring developers because it talks about what to look for when choosing our careers. It summarized the career requirements into three things autonomy, mastery, and purpose. Having a successful career is not easy; we must figure out where we want to be and work hard to get there. We must treat every job as an investment to craft the career that will makes us happy. And if you are among the ones that do not know where they want to be, this chapter has a lot of suggestions to create options that can help decide the next step. Things like attending conferences, blogging, studying new things, and networking with other developers and business-people can open a lot of doors. Our career is important and carefully crafting it is the best way to reach where we want to be.

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

The Software Craftsman Chapter 5 & 6

Chapter 5 of The Software Craftsman titled “Heroes, Goodwill, and Professionalism” essentially covers the communication between the client and the programmer.

There is a limit to satisfying the clients needs. From their perspective, they are not aware of how difficult and elaborate the process for a software project is. They usually have a demand and expects immediate and accurate results because after all that is what they pay us for. However, how we handle situations like this in this field is what determines our level of professionalism. It is our job to communicate with our clients and say “no” when they have unrealistic requests. We need to be upfront on what is possible, what is not, and set realistic deadlines so we can have enough time to work with no pressure. If we fail to communicate, then we end up looking unprofessional.

Chapter 6 is title “Working Software” and it is about keeping the quality of our software as polished as it can be. We must never sacrifice quality for the sake of meeting a deadline; that is bad practice. Our software must be written well enough to adjust to changes, otherwise we will become “hostages of our own software”and that will hinder the business progress. This makes perfect sense because as technology advances, our software needs to be able to adapt quickly. Adding new features should be implemented into with ease if we have good quality software. I like how Sandro relates code to a garden. He mentions that ” with basic and regular maintenance, the garden will always look great but if we neglect it, even for a short period of time, it will require much more effort to make it look good again”. I think this comparison accurately describes how we should treat our code. The same thing can happen to our code if we neglect it; it will deteriorate or loose quality and will require more work to regain quality.

 

 

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

Software Craftsmanship Chapter 3 & 4.

Chapter 3 of this book really translate what software craftsmanship is. It gave us a number of definitions including one from Wikipedia. Each definition shows a different perspective and what stuck out to the most was looking at software craftsmanship on a personal level. The book defines this as

a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques and constantly bettering themselves.

I see this being the most constructive definition or how software craftsmanship should be defined.  If we have this mindset then everything else like team work and professionalism should fall right into place. This also extends into chapter 4 because its about attitude and how software developers should represent themselves. No matter how much we rely on the workforce to gain experience, we have to realize that were in charge of our own careers and our advancement within it.

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

Software Craftsman chapter 1 & 2.

The first chapter of software craftsman talks about how different being a software engineer is today. Knowing how to code is not sufficient to be considered a craftsman, we need to have the knowledge to aid a company in other areas as well. I can see how this is important because in the workforce we have to prove ourselves to be an asset to the company we work for. It is not just about mastering our craft, it is also about showing that we are flexible enough to learn new things and adapt to changes .  Like the book explains having experience in one area is not always the best route. Someone with less experience in the field maybe more knowledgeable in more areas. Chapter 2 Talks about the agile transformation which embraces processes and tools such as Scum and other methods. My experience with scrum has only been in my classes.  But i can see how practicing scrum and other tools alike really contribute to the Agile Manifesto.

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