Category Archives: Week 8

Dynamic and Static Testing

This week’s post is going to be about Dynamic and Static testing from testbytes. Static and Dynamic testing are the two major methods of software testing.

Static Testing is done manually or with a set of tools. This type of testing is useful in finding flaws. It is mainly done in the early stages of the development cycle, also referred to as verification testing. Specifications, design documents, source code, test plans, test scripts, test cases, and web content, all have to pass the static testing. Some advantages of Static Testing are: identifying flaws in the code since it is done in the early stage of development, the testing is conducted by trained software developers, and it is a fast and easy way to find and fix errors. Some disadvantage to using it are:  it demands a great amount of time when you’re doing it manually, not all automated tool works with the language, and that automated tools only scans the code.

Dynamic Testing is done when the code is executed and checks how the software performs in a run-time environment. This testing checks the functional behavior and performance of the system. The purpose of this testing is to ensure that the finished product is designed according to the specification given by the clients. It is also known as validation or execution testing. Some advantages to Dynamic Testing is that it identifies weak areas in a run-time environment and it can be applied to any application. Some disadvantages are: it is not easy to find a trained professional for dynamic testing, and it is difficult to trace vulnerability in the code and would take longer to fix the problem.

 

At first, I thought that Static and Dynamic testing are different kinds of testing but it’s actually more like a primary and secondary test. I really like this blog because it lists the advantages and disadvantages, for me it makes it easier to understand if the layout is like that. Also, they mentioned that eighty-five percent of flaws of the software can be detected during Static Testing, I think that is really interesting. You would’ve thought that most of the flaws in the software would be found in the Dynamic Testing where they test the end product.

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

CS@Worcester – Fun in Function 2018-03-11 23:50:39

The “Reflect As You Work” pattern reminded me right away of the agile software development practice “inspect and adapt.” This practice is mentioned later in the writing as a more formal and specific version of this pattern, whereas an apprentice reflecting as they work involves self-analysis which encompasses all the projects they’ve worked on. The writers recommend periodically asking yourself whether your practices are up to date or becoming obsolete. They ask you to reflect on both the positives and the negatives about your current work, recognize how things got that way, and think about how the negatives could be improved. As one way of helping to apply this pattern, they suggest creating personal practices maps. Unfortunately the source they give for examples of this is gone, so I’m not sure what this ought to look like. I can take note of any changes in my approach as time goes on, however.

This pattern is all about maximizing the amount of useful information you get from your experiences, and utilizing it will make the difference between being an experienced developer and a skilled one; you can have lots of experiences without extracting much meaningful knowledge out of them. Therefore, the writers emphasize that your goal should be to become skilled, not experienced. I found the highlighting of this difference interesting, and it seems intuitively right that it’s possible to become experienced without gaining skill.

One of the authors is used as an example of the power of noticing and reflecting. He explained to his new teammates the pair programming technique the team used which hadn’t really been discussed, and which had simply emerged from their experiences. Once he’d noticed that this was a specific programming practice that should have a name, he blogged about it, and that quickly led him to writing columns for a prominent Software QA website. For me this connected to and reinforced broader lessons I’d already been taught about the importance of observation and noticing; the person who discovered the smallpox vaccine didn’t invent anything, just noticed that people who’d had cowpox didn’t get smallpox.

The author’s experience is also an example of another application of this pattern, which is to observe and reflect on the practices of other developers and adapt your own accordingly.

It’s already my natural inclination to reflect on what I do, so it should be no problem to incorporate this practice into my future profession.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Walking the Long Road: The Long Road

In this Apprenticeship pattern “The Long Road”, it gives us an overview about “the journey” that an apprentice goes through to study, learn, and develop his own craft. Considering that there may be shortcuts towards mastering your craft, it always best to let the journey carry you as a developer because the little things you experience along the way will help you become better overall. Not only the experience is important, but it is also important to understand that there isn’t a literal “mastered” status for a developer where you stop learning or stop to further develop your craft. It is always ongoing because there will always be something new in the programming realm to learn and study for the simple fact that technology is always a growing and advancing industry.

“First, accept the fact that you may be considered a bit strange for what you want to become. Second, keep your focus on the long term. During your apprenticeship, value learning and long-term growth opportunities over salary and traditional notions of leadership. People aspiring to become masters of software craftsmanship need to plan for the long term. This long (yet bright) journey will bring you a rich set of abilities. You will become skilled at learning, problem solving, and developing strong relationships with your customers. You will come to wield knowledge and technology as the samurai uses his short and long swords. You will come to comprehend and appreciate the deeper truths of software development. But all this will take time.”

This idea stood out to me the most and it definitely changed the way I think about the journey on mastering my craft as a developer. Back when I was just learning my first programming language, which was C++, I thought that quickly becoming proficient proved that I was a “master” at it. Now I realized that wasn’t the case. After realizing this, the process of mastering a craft has to take time. The process can involve making mistakes, but that’s fine. For me as an individual, I learn best after I make the mistakes so I know what not to do and I know how to approach the problem the right way.

Considering that I do want to become a video game developer, this pattern also taught me that aspirations to be in leadership positions such as a manager or other promotional positions can get in the way of the learning and growth opportunities on becoming a master craftsman. Now when I approach the position of a video game developer, I’ll be sure to love the journey to grow and become the best developer and programmer I can be.

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

Reflect As You Work

Our Software Development capstone course is very team intensive. I think it would be helpful to research ways I can improve as a contributor in a team-based environment. I’d like to discuss the Reflect As You Work apprenticeship pattern. A successful application of this pattern ought to not only improve myself as a teammate, but could help boost the overall efficiency of my team as well.

The authors assert we should be assessing our personal identities when applying this pattern. The goal is to identify relative connections in our life achievements. Also known as “Mind Maps,” drawing Personal Practice Maps is suggested as an effective way to evaluate ourselves.

640px-MindMapGuidlines.svg
Image Credit: https://commons.wikimedia.org/wiki/File:MindMapGuidlines.svg

The following is a template of a Personal Practice Map that I found on scrum.org:

personal-map-example
Image Credit: https://www.scrum.org/forum/scrum-forum/12339/personal-maps-management30

I believe this type of mapping is beneficial not only for self-reflection, but for anyone reflecting as they work in any team environment.

One of the primary goals of Personal Practice Maps seems to focus on establishing connections between experiences and achievements. On somewhat of a personal level, these type of maps can also help us get to know more about our teammates. For instance, we can see the above template outlines many aspects of Susanne, including her goals and values, as well as her personal and professional life. A personal map such as this can help other teammates see what motivates each team member. Since many teams are likely to be considerably long lasting, I feel it is important to have a general layout of each teammate’s personal motivations. This is to help us reflect as we work, and Personal Practice Maps can assist in achieving this.

The authors describing the Reflect As You Work pattern remind us Personal Practice Maps can also be used to help identify potential roadblocks we are facing. For instance, we could use this type of diagram to map out projects we are working on. We could then look back at how we approached it. Perhaps there were techniques we used that could be improved. The more detailed a Personal Map is, the better we can use it to identify ways to improve our goals. We can then adjust our maps accordingly.

I’ve set a personal goal for myself to design a Personal Practice Map prior to entering my professional career. I believe it will be beneficial for me to evaluate my strengths, weaknesses, and areas that could use improvement. This ought to be a step in the right direction of personally applying the Reflect As You Work apprenticeship pattern.

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

Apprenticeship Pattern: Dig Deeper

This week, I read the apprenticeship pattern “Dig Deeper”, and as the title suggests, this pattern was about trying to gather a much lower level understanding of some of the tools and the libraries that we use daily. The author acknowledged the fact that you do not always need to be an expert in everything to get the job done, sometimes a superficial level of many technologies is more valuable. This pattern suggested that a superficial level of understanding is needed in times where you need to just get something working, maybe you have a deadline, or you are satisfied with the way the product performs. This pattern also did a fantastic job of highlighting the value of digging deeper.

Like many of the patterns in this book, if applied, they will make you more desirable as an engineer. This pattern will not always lead to you acquiring a new skill, but rather it will sharpen your skills and give you an understanding so deep that you may find new ways to use the tools that you’ve always been using, as well as finding new solutions to that problem that has been glaring at you. One personal experience that I’ve had with this pattern was during an internship. I’ve previously had a very basic understanding of REST, and for the most part, that was enough for me to get by, but I was eventually assigned a task that required knowing more than just the basic GET, POST, PUSH, and DELETE requests. This task forced me to dig deeper into rest to understanding things like authentication, query parameters, and other low level details. Having been forced to dig deeper, I now have a much better understanding of REST and with this understanding comes the freedom to write better APIs as well as being able to diagnose issues much more quickly.

I find this pattern extremely useful, and although it may not always be possible/viable to dig deeper when working on a project, I now believe that it is always worth it to make the effort because the benefits are almost always worth the time investment.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sweep the Floor – Apprenticeship Pattern

Sweeping the Floor is a saying for doing the dirty work that no one else wants to do. This pattern highlights what you can do to stand out as the new guy on the team and make yourself valuable to them. This pattern was an excellent read, you can read it yourself here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch04s05.html

The pattern makes it obvious, almost every team has a job that no one WANTS to do. I have seen this at my own jobs. Things like cleaning, writing well thought-out documentation,  and even answering the phone are some of the small tasks that people would rather not do. Step in and volunteer to do those tasks. This will enable you to gain trust and socialize with the team so you can get your foot in the door. The authors go on to talk about how there are some negatives to sweeping the floor. However, In my opinion they are all avoidable. These negatives would be getting stuck as the teams scrub (someone who they make do all the menial tasks and never ask more of), or you will be too intimidated to try and step out of your comfort zone. Both of these are avoidable by being more assertive once you’ve gained trust and a place on the team.

I really enjoyed this pattern because it will be extremely relevant to me in the upcoming future. I am applying to (what feels like) hundreds of jobs to try and join a team when I graduate. I know I will have to prove myself and this pattern has given me a way to do it. Take pride in the small jobs and do them well, this will help you make a stand in your team. The only thing about this pattern I didn’t like was the fact that they added consequences to it. I feel like that really brought down the overall inspiration of the pattern. The consequences weren’t on my mind when I was reading the pattern until, of course, I read that part. They should have stressed that you need to be confident in your abilities to learn and continue to try and climb the totem pole.

Overall, the pattern is an excellent inspirational read for someone who just joined a team and are looking to prove themselves. I can certainly see myself doing this in my future jobs.

 

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

Expose Your Ignorance

This pattern is one among the many which I have drawn so much knowledge and think will go a long way to help me grow in my future employment activities as far as software development is concerned. Educationists will tell you that learning is a gradual process and I know it’s not going to end in the classroom when the time come and I am out of the classroom to the field to face the world. This pattern has just reaffirmed that learning is still going to take place afterward. It is really hard as David H. Hoover admitted to say you don’t know when they expect you to know what they are asking you to deliver. But for my own good I will not be tempted to give quick answers to questions that will put me in trouble later on. Again, this  pattern has also given me the idea that as an apprentice, my goal is not to become an expert but that will come naturally as I go the journey and explore deep into an interesting areas of  learning.

I strongly agreed with the point that when your answer questions, you become clarified of your own knowledge. This is true because, anytime I help someone do something or explain something to someone, I will never forget that subject again; that is stick in my head forever. I used to be shy to speech in public even if I know the answer but as I grow and become more familiar with difference group of people, things began to change. From then,  anytime a question is asked in the mixed of people, I always try to be first to respond  to it if only I have an idea of what is being asked  because I know how it help me in understanding the scope of my knowledge better.

I have been trying to cherry pick these patterns but I realized going through all of them will help me more because, they are interconnected. So far, with what I have learned, all the patterns has something unique that I think if carefully adopted will go a long way to help me deal with all the problems I will be facing as an inexperience apprentice.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Confront Your Ignorance

The context for this pattern, as described by the authors, is that you have found gaps in you skill set that are effecting your everyday work. The problem here is that your knowledge of essential tools and concepts is lagging behind that of your coworkers but you are expected to already have this knowledge as a prerequisite for being a productive member of the team. The authors explain that this particular pattern goes hand-in-hand with the “Expose Your Ignorance Pattern.” They stress the importance of adopting both of these patterns simultaneously as just adhering to one or the other can present problems of their own. For instance, by only exposing your ignorance and never confronting it you may end up in a constant state of ignorance and being overly dependent on other team members when it comes to completing essential tasks relating to the project at hand.  On the other hand, if you only confront your ignorance without ever exposing it you may be missing out on valuable insights your team members could provide you not to mention the fact that you may spend too much time trying to learn specific concepts that could have been easily explained to you by a team member who already has the knowledge you are seeking. According to the authors, the solution to this problem is to “strike a delicate balance” between these two patterns in order to ensure you are learning the essential skills necessary for your role without wasting to much time and allowing you to be as productive as possible.

I found this pattern to be quite relatable in my current role as a Security Analyst. When I first joined the team I had very little knowledge when it came to essential information security concepts. For example, in security it is crucial to have a fundamental understanding of how the different layers in the OSI network model function. This can be quite overwhelming at first considering that each of the seven layers have different functionality along with a multitude of associated protocols that they must adhere to. Luckily my team has been really supportive in helping me gain the necessary knowledge and skills by giving me practice problems and either providing me the resources necessary to learn essential skills or pointing me in the right direction to where I can find helpful resources. I think up to this point I’ve been able to maintain a healthy balance of exposing and confronting my ignorance but the advice provided in this pattern will definitely be useful going forward.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Recovering from Tragedy

After last week’s post I made a simple click that I’ve made probably hundreds of times before when I updated WordPress on the MassHOSA website. The difference this time, however, was that I wasn’t only updating the WordPress core but also the theme that was currently being used on the website. Depending on the update, you can sometimes get away with updating themes without losing customizations. If, however, the update includes changes to say styles.css, for example, your customizations will be obliterated.

I have nobody to blame but myself for this mistake. I was fully aware that updating a theme could wipe out customizations, and WordPress even has a handy warning on the theme update screen:

But, I was not thinking and clicked update – and lost all of the customizations that I had made to the theme, permanently. Here lies another issue: backups. I should have been making regular backups of both the WordPress filesystem and SQL databases, since at this point I have put a significant amount of effort into both the design (stored mainly on the filesystem in CSS and PHP files) and the content (stored mainly in the SQL database).

While this incident was certainly frustrating, it’s not that tragic. I was able to restore the customizations (this time in a child theme) in a matter of a few hours, and am happier with the outcome this time than I was after my original modifications. Using a child theme forced me to do things a bit differently than the first time around, but at this point I already had a pretty good idea of the changes that needed to be made. I am happy to be doing things the right way now, as my original design would not have been sustainable. Making changes directly to the themes CSS files means that you cannot apply updates as they become available. While this would be fine if updates only ever contained feature additions or style modifications that you were not interested in, this is not advisable when some updates contain security patches. Given the choice between leaving my website vulnerable to attack and losing customizations, I would rather put in a couple of hours of doing customizations the right way than face the repercussions of a breach.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

No one is born with the skills needed to be an expert in their craft and very rarely are skilled immediately after learning how to do something new.  As the new member of the team you may not notice it, but it took your other team members years of practice to get to where they are and you can get there too.  Taking risks and making mistakes are important parts of learning new skills and honing your craft. Most work environments provide very little opportunity for young developers, or apprentices in most fields, to make these mistakes or the time to work through them on their own.  It’s important to put aside time to work on a personal project or two in order to work on new skills or just get more comfortable with the skills that you already have.

 

When I worked for Geek Squad I would often be at the counter talking to customers and would have to try and identify what the issue with the computer was and either perform a quick fix or document the specific issue for intake and extended repair.  While we had the opportunity to make some temporary mistakes or try a fix that does nothing, we did not have that luxury at the front counter when working directly with customers that expected us to know exactly what command to run, or the location of every setting for every system and operating system.  What I chose to do was to buy a cheap laptop, take it home and essentially find various ways to break it. In this low stress environment, I was able to get more knowledgeable with different systems and common problems.

 

This is a tool that I intend to use as often as possible when starting a new career.  While I have had practice and learning while completing assignments for the past four years; real world projects and capacity of assignments will vary greatly from what I have done so far.  My plan is to clone my workspace at home to an extent. This will allow me to create a sandbox to try new solutions without breaking programs or causing more work for my other team members. I believe that this is a double edged sword though and you need to be careful with how much additional work you take on without finding a hobby and personal life to balance it with.  I find the breaks beneficial because they allow me to think about something else and that’s when solutions often become clear; getting too consumed with solving a problem that you are practicing on you no longer see the forest through the trees and risk burning out.

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