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.

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.