Posts

Thoughts on Apprenticeship Patterns at first glance

Apprenticeship Patterns: Guidance for Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover is a really fascinating book that I’ve read throughout the weekend for my software development capstone class. At first, the book seems to be a lot more intimidating as I did not know what to expect from it, but while reading the first chapter and the introduction of five other chapters, there are some interesting contents that I found.
For the first chapter, or the introduction for the entire book, it starts off with the author of the book trying to tell how he started with BASIC and Java afterward and failed to find any interests in them due to the fact that they are not really beginners friendly and I think this applies to a lot of new developers that are constantly trying to get into the field but unable to do it by themselves. He then proceeds to move on to tell about how he found his success years later in Perl and use that leverage to dive deeper into software development such …

Familiarize myself with LibreFoodPantry

For the project LibreFoodPantry, although it is pretty new, its main page already includes a lot of useful information about the project as well as related topic such as licensing, code of conduct, and the change log, which I think is really important for users, and developers, establishing professionalism.
What I found the most useful item in the website is the Principle behind the Agile Manifesto. This item provides a really brief, but essential core principles for developers to correctly used Agile. As Agile documentation can be a lot and frustrated to go through, I think that this would be an better way for the team to understand them and to make good decisions on the project. These principles pretty much emphasize the value of customer satisfaction, encourage the team to work together as much as the project requires, improving the work environment for developer and operation team, and at the same time cut major costs for the project.

Software Development Capstone

CS-448, or Software Development Capstone, is one of the last classes that I have to take before graduating this Spring 2020. I am really excited to be able to work in this community project LibreFoodPantry as it can be a great experience to be exposed to skills that are needed to get the job done in the Computer Science field like leadership, teamwork and Agile. I hope that I, as well as everyone that are taking this class can make a huge contribution in this project so that it can be in used soon.

Static testing and Dynamic testing

Static testing and Dynamic testing is two different approaches to testing available for developers and testers in the software development process. In order to get the most out of these tests, this has to be chosen carefully and it is important to understand the benefits and the limitations of each one.

Static testing is a test method where code are not being executed and it can be done manually or using a set of tools. This type of testing would check the syntax, required documentation and design of the code. Static testing also includes security testing to analyze the software for potential errors, code flaws, or vulnerabilities. This method can be start in the early development stage of the program, and it can be done on work documents like specification documents, design documents, web page contents, etc. Static testing techniques include:
-  Inspection: The main purpose of this is to find defections. This task can be reviewing the check lists, work documents, or code walkthroughs…

Black Box, White Box and Grey Box testing

Black Box, White Box and Grey Box are there most common terms in testing as it is really important. These terms are selections of tests that developers have that is based on their purpose of testing, what is being tested, and they determine which what tools or technologies to be used in order to tackle to problem efficiently.

Firstly, let's talk about Black box testing. This type of test is really common on testing user interface. It treats the program as if it is a "black box", or refer to testing without knowing or be able to change the internal implementation. It is also known among developers as closed or opaque box. The advantage of this type of testing is pretty huge, as developers can focus more on how to test the feature, rather than having to get to know the internal code. It also needs low time to prepare, and designed to simulate the perspective of users. With those potential advantages, the trade off of Black Box testing is also huge, as it might have a chanc…

Path testing

Path testing is widely used to design test cases. Path testing process has 4 steps, which is to draw control flow graph, calculate Cyclomatic Complexity, make set of paths, and then create test cases for the those paths, which would use this formula: E - N + 2P (where E is number of edges, N is number of vertices and P is program factor). Path testing usually use control flow graph, which would help developers find sets of linearly dependent paths of execution. Path testing also use Cyclomatic Complexity to determine the number of linearly independent paths and each path should be a separate test case.

Besides control flow graph, path testing can also use different techniques like decision to decision path, where control flow path can be broken into various decision to decision paths and collapse into individual nodes, and Independent paths. There are various advantages of path testing like making sure that tests are isolated and not redundant to each other, it helps developers focus …

Code coverage

Code coverage is a subject that has recently come up in my Testing class and it did catch my attention for its useful functionality. So what's code coverage? Code coverage is how much of the code that has been executed during the testing process. This process is not only check for every line of code, it also checks if all the branch of conditional and loops is covered. With this process in place, it would surely decrease the number of bugs.
With that being said, how would developers be able to apply this into their code? There are a lot of system and plugins out there that would help doing this job correctly, I will take JaCoCo plugins for Gradle as an example in this post, since I think it is a really good system that gives excellent reports. To enable JaCoCo, add this line to build.gradle:
 apply plugin: 'jacoco' 
What is greater about JaCoCo is that it let user define thresholds or conditions that the code coverage has to pass in order for the build system to return pass…