Hello dear reader. As I was staring at my computer and was trying to find a good subject for today’s blogs a bell ringed in my mind: APIs.
I never came across the name API until I started my job. I remember when everyone used to say ‘The API is not working’, ‘We need to call the API to make this process happened’ etc. and I was super confused so I entered google and wrote what is API. Google told me ‘Application Programming Interface’ more fancy words. I started to watch videos about it and also, we started to use them at school. Now I am the one using the term API.

Application – think of an application like credit card. You expect the credit card to help you purchase items and goods.

Programming – API allow the credit card needs to contact your bank and make sure you haven’t extended the limit in your card and is okay to go on.

Interface – is the way we interact with an application.

Simple for you: API define rules that developers must follow to interact with a programming language, software library, web interface or any other software tool. Everyone uses an API every day in some way. A simple comparable example would be you accessing a webpage in your browser. You make a request by entering the webpage URL and the view you see after you press Enter is the response. The API has the same process of request/response but the difference is that API requests provide data in their response.

But why do we even use API? Many of the APIs are made with the intention to allow 3^rd party developers to build applications using company data, Since the APIs simply provide data, there are limits on how a company can then go on to use that data. APIs act just like a door and keys. Only the people having the key can open the door and enter the room.

https://www.youtube.com/watch?v=InoAIgBZIEA This video is a great example on how to use the API ( how to call and get the information you need).

Hello dear reader. Another concept that I came across this semester in my Software Design and Construction class was UML diagrams and I wanted to write about UML diagrams in one of my posts.

For all of you that are new to UML, UML is not a programing language. UML stands for Unified Modeling Language. UML is a standard model language of an integrated set of diagrams. UML was developed to help system and software developers for specifying, constructing, visualizing, and documenting the code of software systems. It is a very important part of developing object-oriented software and the software development process. UML uses mostly graphical notations to express the design a software. Using UML helps teams communicate and validate the architectural design of the software. We use it to portray the behavior and the structure of a system/project.

A question that I asked myself when I started to learn about UML was: Do we really need UML? The more I learned about it the more I understood how important UML is. This for different reasons like: – there are a lot complex applications and systems that need planning from a lot of different teams, and clear explanation need to go to each and every team working on the same project; most of our users might not ever know what code is, but there are a very important part of our project and that’s where UML kicks in by translating this ‘foreign language’ called code.

UML can be classified in two types: Structural and Behavior Diagrams. Structural Diagrams get the static aspect or structure of a system. It includes Object Diagrams, Deployment Diagrams, Class Diagrams and Component Diagrams. Behavior Diagrams on the other hand get the dynamic aspect or behavior of the system and it includes Interaction Diagrams, State Diagrams, Use Case Diagrams and Activity Diagrams.

Except school I have come across UML Diagrams at my job too. The diagram I have seen and that we use a lot if the Deployment Diagram as each of us should be aware of the architecture of the system as deployment.

I like the way Noel explains UML diagrams and where/how to use them. He provides great graphic examples of the diagrams.
https://tallyfy.com/uml-diagram/

Hello dear readers. In this blog post I would like to write about Refactoring, documentation and software framework. While explaining what they are I will try define why are they needed.

Refactoring is very used term in software development and has played a major role in the maintenance of software. Refactoring is one of the most self-evident processes, but it is surprisingly difficult to perform properly. In most cases, we deviate from strict refactoring and execute an approximation of the process; sometimes, things work out and we are left with cleaner code, but other times, we get snared, wondering where we went wrong. In either case, it is important to fully understand the importance and simplicity of barebones refactoring. Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations. The cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring — which allows you to gradually refactor a system over an extended period of time.

I also want to talk about documentation in this blog post. For a programmer reliable documentation is always needed. The presence of documentation helps keep track of all aspects of an application and it improves on the quality of a software product. Its main focuses are maintenance, development, and knowledge transfer to other programmers. Successful documentation will make information easily accessible, simplify the product, help new users learn quickly, provide a limited number of user entry points and help cut support costs. Documentation is usually focused on the following components that make up an application: business rules, troubleshooting, server environments, application installation, database/files and code deployment.

A software framework is a concrete platform where common code with general functionality can be specialized or overridden by developers or users. Frameworks take the form of libraries, where a well-defined API is reusable anywhere within the software under development. There exist some features that make a framework different form other library form. These features are: default behavior, inversion of control, extensibility, non-modifiable framework code.

I am attaching the following links that will help you have a better understanding of these concepts as these blog posts also provide examples.
https://refactoring.com/
https://medium.freecodecamp.org/why-documentation-matters-and-why-you-should-include-it-in-your-code-41ef62dd5c2f
https://www.quora.com/What-is-a-framework-in-programming

Hello dear readers. Welcome back to my blog. As we know by now most programming language support and encourage object-oriented programming and in this blog post we are going to talk about the principles of the Object-Oriented Programming. The key design principles of Object-Oriented Programming are:

Abstraction – is the idea of simplifying a concept to its bare essentials in some context. It allows you to better understand the concept by stripping it down to a simplified version. Your abstraction should be intuitive.

Encapsulation – can be thought of as putting something inside a capsule. In software, restricting access to inner objects and properties helps with data integrity. Encapsulation makes your classes easier to manage, because you know what part is used by other systems and what isn’t. This means that you can easily rework the inner logic while retaining the public parts and be sure that you have not broken anything. A disadvantage of it is that working with the encapsulated functionality from the outside becomes simpler as you have less things to think about.

Decomposition – is the action of splitting an object into multiple separate smaller parts. Spitted parts are easier to understand, maintain and program. There exist three types of decomposition relationships: 1. Association, which defines a loose relationship between two components. They don’t depend on each other but work together. 2. Aggregation, which defines a weak ‘has-a’ relationship between a whole and its parts. The parts though can exist without the whole. 3. Composition, which defines a strong ‘has-a’ relationship where the whole and the part can’t exist without each other.

Polymorphism – is the ability for data to be processed in more than one form. It allows the performance of the same task in various ways. It also consists of method overloading and method overriding.

Inheritance – is the ability of one class to inherit properties of another class, called the parent class. We can inherit properties from other classes s well.  So, when we create a class, we do not need to write all the properties and functions again and again, as these can be inherited from another class which possesses it. Inheritance allows the user to reuse the code whenever needed.

Design principles are rules in software design that have proven themselves valuable over the years. Just like any other ‘game’ even when we code we need to know and follow the rules. This is the main reason why I choose to write about the principles of Object-Oriented Programming.

Hello dear readers. Today we are going to talk about SOLID, the first five principles of the object oriented design.

S.O.L.I.D is an acronym for the first five object-oriented design principle. When these principles are combined together, it makes it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid easily refactor code and are also a part of the agile or adaptive software development. SOLID stands for:
S – Single responsibility principle
O – Open/Closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion principle

Single Responsibility Principle states that a class should only have one job, only one reason to change. The reason why we should use SRP is because it makes your software easier to implement and prevents unexpected side-effects of future changes. Another benefit of this principle is that classes and software components that have only one responsibility are much easier to understand, explain and implement than the ones that provide solution for everything.

Open/Closed Principle states that objects or entities should be open for extension but closed for modifications. Using this principle prevents situations in which a change to one of your classes also requires you to adapt all depending classes.

Liskov substitution principle states that every subclass/derived class should be substitute for their base/parent class. To achieve that, your subclasses need to follow the following rules: 1. Don’t implement any stricter validation rules on input parameters than implemented by the parent class. 2. Apply at the least the same rules to all output parameters as applied by the parent class.

Interface segregation principle states that a client should not be forces to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. By following this principle, you will be able to prevent bloated interfaces that define methods for multiple responsibilities. You should avoid classes and interfaces with multiple responsibilities because they change often and make your software hard to maintain.

Dependency Inversion principle states that entities must depend on abstractions not on concretions. High-lever and low-lever modules also depend on the abstraction. This design principle does not just change the direction of the dependency, it also splits the dependency between the two levels by introducing an abstraction between them.

 

And the biggest question if the software testing is manual testing vs automatic testing? Why do we need automated testing?

@All Welcome to my last blog post for my Software Test class. As a last blog post for this class I wanted to talk about the Automated Testing.

From the name we can tell that Automated Testing is automated. Automated testing is done through an automated tool, which is needed in exploratory tests and in maintaining test scripts while increasing overall test coverage. Automated Testing is usually used for large projects that require testing the same area lots of times.
Automated Testing has its own implementing strategy which consist in the shape of a pyramid. This strategy calls for automating testing at three different levels. The biggest percentage of this test automation pyramid goes to unit testing. The is followed from API testing and UI testing.

Software tests have to repeated often during development cycles to ensure quality. Every time the source code is modified, software test should be repeated. From my experience at my work, we recently automated the testing and deployment process for one of our systems. For every deployment, we had to test every connected system. One of the benefits of Automated Testing is that is much faster than the manual testing and it also can reduce the time to run repetitive tests all the time. In my opinion time savings equals cost savings. Another benefit of Automated Testing is it increases the test coverage.  It can easily execute thousands of different complex test cases during every test run, providing coverage that is almost impossible with manual testing.

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

Kyle makes a good point in explaining the differences between the test automation and automated testing as its important to know the difference.

Hello dear reader. Welcome back to my blog. We talked in the previous blog about Test Driven Deployment. Now it is time to talk about Behavior Driven Deployment. Behavior Driven Deployment is a software development methodology that combines practices from test-driven development and domain-driven design. As we mentioned in the last blog test-driven deployment focuses development on short, cyclical iterations in which (failing) tests are initially created that define the wanted functionality, and only then is actual code written that ensures those previously-failing tests can now pass. Domain-driven design in the other hand, centers on the concept of domain and domain logic. Thus, DDD practices attempt to simplify the terminology in the project scope by focusing and defining everything in the application as real-world objects or concepts that most people are familiar with.
By the combination of TDD and DDD, Behavior Driven Development aims to simplify development trough the use of a common domain-specific language.
As behavior driven development is derived from influenced by TDD, many of the same benefits apply to BDD as well. BDD it reduces regression. When you have a full suite of tests being continually executed, and with new tests always being added, BDD reduces extremely the likelihood of regression bugs popping up as the code is in constant monitoring and testing.
BDD also improves team communication. Since there is a common real-life basis for phrases and terminology when discussing a project, BDD can often improve communication across the entirety of the team.

BDD has also disadvantages like it requires specifications before development and relies on constant outside feedback.

Personally, I like TDD testing better as the code does what you are testing and believe me when I say that the documentation and specifications are bad for a project. There are usually lots of misunderstanding in the specification of a project. It also depends on the project and the company. Thanks for being my reader again.

https://docs.cucumber.io/bdd/overview/

Hello dear readers. Now it is time to talk about Test Driven Deployment testing.Test driven development is a software development process that consist on the repetition of a very short development cycle. At first the developer writes an automated test case that defines an improvement or new function. After that, it produces the minimum amount of code to pass that test, and at the end refactors the new code to acceptable standards.

For test driven development the following steps are followed: 1. Add a test; 2. Run all tests and see if the new one fails; 3. Write some code; 4. Run tests; 5. Refactor code; 6. Repeat.

Test driven development is like a way to turn the code into an instruction manual. The goal of software tests is usually to catch any errors before making that software available. The first tests you write, are just like a roadmap for what the perfect version of the code is supposed to do. As this type of testing consist on the test written before the code for the program is written, you expect the tests to fail at first. It takes something that can be discouraging and turns it into a clear instruction for what to add next to the program.

Some of the benefits of TDD are efficiency, readability, etc. TDD just makes you a better programmer. It is said that most of the programmers don’t read the written documentation for a system, instead they prefer to work with the code. When trying to understand a class or operation most programmers will first look for sample code that already works with it.  Well-written unit tests do exactly the same and as a result unit tests effectively become a good portion of your technical documentation.
Let’s assume you add some new functional code, compile, and test it.  Chances are high that your tests will be broken by defects that are in the new code you just created. It is much easier to find, and then fix, those defects if you’ve written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps. I generally prefer to add a few new lines of functional code, typically less than ten, before I recompile and rerun my tests.

Please check out the following website for more info: https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2. I found this website very useful in understanding TDD.

Hello dear readers. Thanks for coming back to my blog to learn about the Static Testing Technique.

The first technique of the Static Testing is Informal Review. This type of technique consist on  the presentation given by the creator of documents such as software requirements, business requirement document, technical design document,  test cases document, function requirement documents etc to the audience. The audience could be senior management, development team, business clients, internal audit team, etc. During these reviews and after, the audience can give their opinion and can share their experience in order to outline the review defects. This static testing type is very useful because it helps in the identification of the defect very early.

The second technique is called Walkthrough. This type of technique is done with the expert or a senior member. For example, Software Requirements Specification Document will be reviewed with the Business lead who have provided the requirements, test cases document will be reviewed by the testing team who is going to execute those test, Functional Requirements Document will be reviewed with the technical team who is going to write the solution etc. This walkthrough is useful because: the lead is aware of the quality of the documents and the target team comes to know about what exactly is going on.

Peer review it’s the review when the peer ensures maker and checker. To outline the common mistake such as workflow mistake, spelling mistake etc, a team of two or more is needed to review the work. The colleague is included as the peer who tests the work at the document level.

Last technique is Inspection. This technique validated the documentation work by the dedicated governance team. For example: the Business Requirement Document, change ticket, technical Design Document, etc are reviewed by compliance, tollgate team and change the governance respectively. If it found inappropriate, inspection can reject the execution of the document.

Having to know the techniques is important as are part of the testing process.

https://www.invensis.net/blog/it/software-test-design-techniques-static-and-dynamic-testing/

Hello dear reader! It’s me again with some more types of testing that I think it will be very useful for you to know.

Both Static and Dynamic Testing are two other types of testing very important for testers and developers as they are part of the Software Development Life cycle. The decision for which of these two tests to use would come from the company you will be working for. However, it is very important for you to know what they are and where to use them as you might be asked to give your opinion and you don’t want to give a wrong answer!!!

Dynamic Testing is performed when the code is in the operation mode, in run time environment. When a value is inputted to the code, the output of the code is checked and compared with the different expected output. Dynamic testing is also known as a validation testing, evaluating and finished product. With this we can observe the functional behavior of the software, CPU response time, performance of the system and monitor the system memory.
Dynamic Testing has a few techniques like: Unit Testing – Integration Testing – System Testing – Acceptance Testing (please see the previous blog for a better explanation of these techniques).

Static Testing is the type of testing where the code is not executed. This type of testing can be performed by tools or manually. This type of testing checks the code, requirement documents and design document and puts under review comments on the work of the document. Static Testing it is usually called verification testing as it is started earlier in the development life cycle. This type of testing can be done on work documents, design documents, source code, test scripts, web page, test cases and test plans.
Just like the Dynamic Testing, Static Testing has also its technique: Inspection – Walkthrough – Technical Reviews – Informal reviews (there will be another separate blog to discuss about these techniques).

But what are some of the differences between these two types of testing?

As mentioned above Static Testing is a performed in an early stage of development, before deployment while the Dynamic testing is performed at the later stage of development life cycle, after deployment. While the Static Testing doesn’t use the execution of the code, executing the code in the Dynamic Testing is a must. Also another difference would be that Static Testing has more statement coverage  than dynamic testing in shorter time.

In general I choose to write about all types of testing as I think it is very important to be aware of them. Different situations, different projects, different code, different stage requires different type of testing. Knowing which way to test is just as important as knowing how to write code for a software.