AB Testing – Episode 3



-In this weeks testing episode, Brent and Allen brings new light to the careers in software development with a focus on testing. It seemed that most graduates have developing as their first option and when they cannot do that, they want to fall back to software program management and if all fails, they settle for being a tester. The fact of the matter is that people don’t value the career of testing. But if you are able to be a good tester, you build the skills required to make a great developer. Usually testers have to manager programs and create tests around that schedule. Again students who study big data learn great and valuable skills that are applied in the field of testing. Things such as reading maps, graphs, making analysis and analyzing data input and outputs are all skills that helps make one a great tester.

So why aren’t many students becoming software tester?

Brent and Allen took a survey from a selected number of student and they found out that schools are not teaching testing classes. This could be the reason why many students don’t find value in studying software testing. It is often believe that testing is embedded in software development but the sooner we demystify this the better!. It is been proven that writing tests strategies and plans before writing code often help speed up the software building process. This is because knowing what you code is suppose to do makes it easier to create code to do what its suppose to do. Now how can


We use metrics and Data analysis to improve testing?

Data analysis often provides detailed information about page load time, memory usage charts and load balancing metrics. This data allows a tester to identify potential bugs and issues that need to be addressed before the release of a software product. By managing and properly observing the metrics that matter, we are able to produce better data that directly affect the performance of the software. By implementing proper metric techniques, companies and software companies are able to relate marketing to performance and user feedback. By use of metric, Amazon is able to know how much a delay of 1 millisecond affects them in annual revenue. By getting information such as these, companies are able to proper manager their markets and are able to know what their customers expect of them.






Coding Blocks – Source Control- Episode 3



In this episode of coding blocks Allen Underwood, Michael Outlaw, Joe Zack addressed an issue in software construction that often makes or break a project/Team. Source control and management. I personally found this topic very crucial because of a programming project I was able to contribute to with a couple of my friends. Initially, we were just using Google drive to update and track project chances but as many newer version were created, it became a mess to try and track which update did what and how stable is that version. We eventually resulted to utilizing Gitlab. It was here that I found the importance of source control team working. We were able to section of parts of the project and distribute among ourselves also, it was easy to modify and make changes because we always know a Standard version of the project existed should we break the original pull. In this podcast episode, the authors made known of another major reason why implementing source control was effective. By implementing source control, many branches be worked on at the same time. This way, problems and bugs can be resolved and fixed faster. Also construction was made a little easy as people could work independently on building various parts of the software. Again by pushing after every working build, the programmer is able to leave a stable version with an attached commit message which help the next person to touch the code understand what that build accomplishes or does.

Best Practice Tip: Ensure that you only push back working code that passed the compilation test.

Another topic the authors addressed was the issue of missing path that often occurs with source control software development. They made emphasis that having a consistent naming convention is recommended for best practices because some programs and software requires you to switch between operating system and since that means different file systems, having a standard naming convention for packages and file paths makes it easier on who ever works on the program to make edits and changes as needed.

         While addressing source control, another major topic to talk about is pull requests. It serves as another layer of verification and “code review”. Having push requests allows you to submit to a specific branch and get you work evaluated before pushing back to the main repository. This way leaders and managers can verify that code written is correct and fits the required standards and specifications.




2# Software Design and Construction

Coding Blocks – Design Pattern- Episode 2

I think this was one of the podcast episodes I was really excited to see. The topics was design patter so I figured I would hear things and concepts I was familiar with and also serve as a measure for me to test what I knew and how in-depth I could follow the episode. Right off the bat, they begin to talk about the absence of design patterns in their curriculum when they were in school. This made a light bulb go off. Meaning I am technically ahead of that era in terms of the tools I am being provided in school to better succeed in the real software construction and development world. Joe Zack also mentions that he knew the big O notation for the entire basic sorting algorithm, which is something I am also familiar with. I am currently an expert at the shell-sorting algorithm. With all the things they were talking about I was able to face reality that I am not really too far away from being a developer on a software development team. Also it demonstrated how much the field of software engineering has changed. It’s crazy for someone to graduate from computer science and not know what design patterns are in today’s world. All projects and programs   today utilize design patterns to create a hierarchy of classes comprising of parent, children, abstract and class interfaces. This helps organize and makes thing more legible for the next programmer that is hired to “maintain” the program. To become a great programmer, one need to develop great design and organizing skills that can be translated into project design patterns. Again Design pattern can actually be divided into three (3) categories.


  1. Creational Patterns. (Factories, Builders, Prototype and Singletons)
  2. Structural Patterns. (Adapter, Bridges, Flyweight, Proxy, etc.)
  3. Behavioral Patterns (Observers, strategy, Chain of responsibilities, etc.)


This I did not know!


Creational Patterns: They help encapsulate the logic of creating classes in a more separate class where classes are created and represented outside the logic that utilizes the creational pattern.


As the discussion got deeper, I noticed that most of these guys recording the podcast have done tons and tons of projects that utilize some of the concepts they are talking about. Right of the bat, I got the initiative to start a project and try to use and implement as many new concepts as I can. Because after all, the best thing you can do for yourself as an upcoming developing in school is to start many projects on your own and try implementing new things you learn and read in school because in the worst case, you familiarize yourself more with topic and concepts that get taught in class.





2# QA & TESTING – Episode 1

AB Testing – Episode 1 by Brent Jenson and Allen Page.

In this weeks testing episode, I went back to episode 1 just so I can address topics that Allen and Brent found necessary to start their testing podcast episodes with. Both Allen and Brent are high-end software developers and testers who worked for many big companies and performed many big tasks in the world of software developing and testing. Allen page was a software-testing manager who contributed to many books in the world of software testing. (His books are really good if you wanted any information of software testing). Brent Jenson also worked for Microsoft for over 20 years and accumulated many experience holding the position of software testing Director. They continued to talk about a presentation method used at Microsoft which I thought would benefit the software testing industry should we all decide to utilize it. They called it the Lean coffee lives. As comical as this sounds, lean coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. These agendas are often address to things viewed as highly important and then goes all the way down to items on the list, which is viewed, as less important. So this sounded like something we can bring to our Testing Team meetings!! As quickly as the podcast began, Allen began to dive into real Software testing concepts. He began by emphasizing the great difference that lies between testing and quality. With constant changes and improvising’s, system and program bugs quickly lose values. Finding bugs on constantly or sometimes daily changing software does not constitute to the quality level of the software product. This is because today’s bug can be fixed in tomorrows code implementation and that can also create a new bug that could be fixed with the next program/code modification. Now here is the case that is it the Job of software testers to find bugs and errors in the program. Now it’s the job of a test manager to schedule test runs and passes for the specific product in development. How do you think a test manager could work successfully an environment where code changes and modifications are being made on a daily base? The proposed solution goes back to the beginning of the project where planning and thoughts have to be put in place. To put forth a great product, time allocation for testing has to be incurred in the project timeline. You can put out quality without considering all aspects of possible challenges and inputs.




I for Interface

Coding Blocks – I for interface- Episode 1

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. I think I am really going to enjoy these podcast episodes because they began by talking about things that I could relate directly to. The three presenters started this episode by defining what an interface is to them. Although I have an understanding of what an interface is, hearing what is means to professional programmers gave light to some different ways of looking at what an interface is. My favorite was “ An interface can somehow be seen as the guard rail on the highway”. I think I “vibed” the most with this definition because that along the lines of what I see an interface to be. After several definitions, the question was then asked what the difference between an abstract class and an interface was. It was at this point that I realized I might have pushed the definition of an interface too far but luckily, this podcast straighten me out. The presented settled on the definition that an abstract interface contained more information and made allocations for storage unlike the interface, which just provided guides for what is to be implemented. The abstract class provided guides and instructions and also storage allocations for the type of data or information to be implemented. Wow!

Again the discussions progressed rapidly, it was discussed that an abstract class has to be inherited but an interface must be implemented. An abstract class can’t be instantiated but needs to be inherited. I thought this topic was very important because I recall the first couple of classes, we often found our selves lost in discussions to try and understand the differences and functionalities between these programing concepts. For best practices, it was mentioned that foregoing naming conventions in interfaces sometimes makes it easier to read and also utilizing underscores would group the abstract classes in the top of the file directories when looking at the directory tree structure. Also, they did advise to also prefix all interfaces that we create with an “I” so that everyone that looks at the program will know what it is. Didn’t know that was the standard in the real world.

“You can’t define constructor methods in an interface” – This means we can’t create an interface that informs the classes that are to implement the interface how those classes can be implemented. Again this is a confusing statement but by pondering on it for a few hours, it becomes pretty clear. Instead it makes sense to utilize a base class. Overall this podcast has a lot to be learned from it. They really emphasize on explaining technical concepts and terminologies. Will be posting a different episode next week.


Link – Episode 1


Week 5

AB Testing – Episode 68 by Brent Jenson and Allen Page.


-In this episode, Brent and Allen begin by talking about their stressful lives as software QA engineers. Working late hours and trying to stay up to date with the latest trends in the industry. From this brief intro I was able to get look at the potential challenges that exist in the field of Software testing. One needs to have the ability to be able to learn and implement new technologies regardless of how qualified or advanced one is at software QA and testing. As the podcast continues, allan talks about his position and how much work goes in to generating and creating substantial testing procedures that gets the job done and optimizes the testing process. To me, a student majoring in Computer science with a focus in software development, it’s easy for me to understand and know what Alan is talking about. Due to my class studies, I understand the importance of software testing and how a bad-testing process can be of little to no value to a product whiles a good testing procedure can make or break a product. HE emphasized on all the intangibles that only a person in the industry could understand and enumerated on how useless his positions appears to be to the average person. Brent expands on this topic by saying that organizations generally see the QA department of organizations as a cost for the organization without realizing the true benefits of this department. They are often not given the credit when things are going well and consistent but they are often the first department in software industries that deals with layoffs and budget cuts should there be a need for cuts.

With this topic both Allan and Brent went off on a tangent and began comparing and contrasting Traditional testing and modern testing. Prior to this podcast, I didn’t know there were “traditional testing era” and   “modern testing era”. According to them, the old way of testing followed the following sequence. Requirement => Design =>Code & Build => Testing => Maintenance whiles the modern way of testing follows the following sequence.

Requirement => Testing => Design => Testing => Build & Execution => Testing =>Test => Testing => Installation => Testing => Maintenance => Testing.

As we can see, the modern way implements more testing stage with might appear to be more costly that the old way but overtime saves more and enables modulation of components. The software gets built by parts instead of one giant big project.