Hello dear readers.  It is time to talk now about the phases of testing that a software has to go through in order to make it to production.

Unit Testing – I have another separate blog about unit testing as I though it was important for new software developers to understand well what it is and how it works.

Next in the levels of Software testing comes Integration Testing. Integration Testing comes always after Unit Testing and before System Testing. Integration testing gives the tester the opportunity to combine all of the unit within a program and test them as a group. Integration testing is designed to find interface issues between the functions/modules. Test drivers and test subs are used to assist in Integration Testing. For Integration testing any of White Box Testing, Black Box testing or Gray Box Testing methods can be used. This way of testing determines how efficient the units are running together. Even though each unit might be very efficient, if they aren’t properly integrated it will affect the functionality of the software program. Integration testing has four approaches: Big Bang – where all or most of the units are combined together and tested at one go; Top Down – where top-level units are tested first and lover lever units are tested step by step after that; Bottom-Up – where level units are tested first and upper-lever units step by step after that; Sandwich – is a combination of Top Down and Bottom Up approaches.

After we are done with Integration Testing it is time to go to the next level: System Testing. System Testing is the process of testing an integrated system to verify that it meets specified requirements. It tests the overall interaction of components. It also involves load, reliability, security testing and performance. System Testing is usually performed by independent testers who haven’t played a role in developing the program. This testing is usually tested in an environment that mirrors closely production. It is important for a software program to meet the technical, functional and business requirements that are set by the customer and System Testing is the best way to tell.

Last but not least is the Acceptance Testing. This is the last test performed in the application before it goes to the customer. Acceptance Testing is performed by the user to make sure the requirements of a specification are met as per its delivery. Sometimes some requirements are misinterpreted, and Acceptance Testing is the best way to find out.

After the whole testing process is complete and the software has passed, the program will be delivered/deployed to production.

Either you are a software developer or a Test developer you need to know these four important steps as each of your program will go through that. I thought it was very important to tell you this process as it will present in every program/software/method you will design.

Hello dear readers. Today I am going to talk about Unit Testing. I believe most of the people are pretty familiar with it, but for those of you who are not : Welcome to What is Unit testing and why to use it!
Unit testing is a testing process where the smallest part of a program or an application are tested individually. A unit can be almost anything you want it to be — a line of code, a method, or a class. Generally, smaller is better. Smaller tests give you a much more granular view of how your code is performing. There is also the practical aspect that when you test very small units, your tests can be run fast; like a thousand tests in a second fast. Unit testing involves only those characteristics that are important to the performance of the unit under test. This encourages developers to modify the source code without worrying about how such changes might affect the functioning of other units or the whole program. Once all of the units in a program have been found to be working in the most efficient and error-free manner possible, larger components of the program can be evaluated by means of integration testing.

Unit testing is performed by using the White Box Testing method. When creating Unit test we should keep in mind not to create test cases for everything. Focusing on the tests that impact the behavior of the system is the most important. Another issue that is usually very common in software testing is debugging and unit testing makes it easier. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/weeks/months need to be scanned.

Unit testing also increases the confidence in maintaining/changing the code. When these unit test run after the code is changed, will be able to promptly catch any defects coming from the changes made.

To be honest Unit testing is probably my favorite way of testing. Of course, as a tester Unit testing is not efficient for lots of code and other ways need to be consider. However, the reason why I like Unit testing is because it helps you figure out where the defect is in the code. The changes of a defect persisting are higher when not using a unit test and if you try to fix it you can break something else.  Also, it is good to write tests before trying to fix it because if you fix it right away you will be lazy to write tests anyways. And keep in mind test coverage has to be as high as possible! ALWAYS!

Hello everyone! This blog post is about my CS-443 class. Today I will be talking about a very important topic: white vs black! Me personally I love white. It is my favorite and it is clean. Hmm but why are we talking about colors in a software class?! Hmmm….wait a second! We are not talking about colors here, we are talking about testing methods, white and black box. The first time I came across with these two terms was about 6-7 months ago at my work. One of our software testing engineers was giving a presentation about different methods of testing we could use, and white and black testing was part of them. I remember I was researching about these terms after the presentation.

White and black box are two testing methods used in software testing. Both very different methods, but very important.

White box testing is a detailed testing method of the code, logic and structure. In order to perform white box testing the code should be visible to the tester. The tester needs to look inside the source code and figure out what is not working right or what can be improved for more efficiency. Like every other thing in the world these two methods have advantages and disadvantages. Some of the advantages of white box testing method are: It makes it easier for the tester to determine the easiest way of testing and where the code might break; The tester can determine easily which lines are not needed to improve the code efficiency; The tester can provide maximum code coverage. A disadvantage of the white box testing I would mention is that it requires debugging and analyzers tools.

On the other hand, black box testing is the complete opposite of white box testing. In this method the tester doesn’t have any information or knowledge of the source code and the internal structure. The only way of testing using this method is to put random inputs and examine and compare the outputs with what is excepted. In addition, the tester doesn’t have any knowledge how the input is worked upon. Even though this type of testing sound pretty hard to work with, it has its own advantages. The advantages of this testing method are: It is very efficient for large/extremely large amount of code, it would be a waste of time to keep looking at the code; It separates the user’s perspective from developer’s perspective. Some of the disadvantages of this testing method are: Blind coverage; difficulty in designing the tests; limited coverage.

I liked to explain the difference between these two types of testing methods as a lot of people seem confused. To be honest I have heard a lot of people who say that the black box testing is not good to use. I just wanted to say that is depends a lot in the type of testing you are asked to perform. If you are asked to match the outputs with the excepted output, there is really no need to have the code. Of course, it is always great to have access to the source code as a reference, but if we talk about big companies you might want to think it twice about using white box testing.

Hello everyone! This is my first CS blog post so let’s cross the bridge and get to know more about Software. In this first blog post I will be writing about design patterns and in particular about the Bridge, the bridge design pattern of course!! What were you thinking?!

To start with, I want to talk a bit about design patterns, what are and how important are they. A design pattern is simply a solution of an occurring problem in software design. Think of a design pattern as a template that will help you to solve your problem. How important are they? VERY!

If you have a problem, what are you going to do about it if you don’t have a solution!? Once you get to know the most important design patterns, you will be able to understand which one to use just by understanding the problem well. But what is the damage of choosing the wrong design pattern? Actually, it is a pretty big problem to have the wrong design pattern to fit for your problem. Having the wrong design pattern will bring you to a very complex solution and if you are working with other people it will be very hard for them to understand your solution or even might give them a wrong understanding of it. BIG PROBLEM!

In class of CS 343 we have talked about some of the most important design patterns used and here I will talked about another one. The Bridge Design Pattern is introduced by the Gang Of Four and is used in software to encapsulate an implementation class inside an interface class.  The Bridge design patters helps solving problems: when abstraction and implementation should be defined and extended independently; when the implementation needs to be selected at run time by avoiding a compile time binding between an abstraction and implementation. Some other advantages of The Bridge are that it can be used to map orthogonal class hierarchies and is designed up front to let the abstraction and implementation be independently of each other. The Bridge Design Pattern is a composite of the Template and Strategy design patterns.

It is considered that the Bridge Design Pattern is very similar with the Adapter design pattern. The biggest difference is that the Adapter Design Pattern is used to convert the interface between classes with less inheritance, but the Bridge Design Pattern decouple an abstraction class from its implementation.

The reason why I choose to talk about this design pattern is that I found it interesting to know about a similar design of Adapter Design.  Software engineers face different problems all the time and it is good to know about different type of design patterns in order to have the perfect solution for a problem.

Resources and example of Bridge Design Pattern:
1. https://www.geeksforgeeks.org/bridge-design-pattern/