Figuring out Continuous Integration

So for this week, I have decided to read “Introduction to Continuous Integration Testing” from the TestLodge blog. The reason I have chosen to read this is because it is crucial to know the concepts of Continuous Integration and how this practice provides flexibility to development teams. It will help in understanding the workflow and why it helps developers to develop software that is cohesive even at the shortest amount of time.

This blog post goes over what is Continuous Integration, the advantages from it, and concepts before embarking Continuous Integration. Continuous Integration is an approach within software development in which the developer pushes code into a respiratory, such as Git, several times daily during the development phase. There are tools available that developers can use to set up Continuous Integration. They can be both licensed and open source and by using them, simultaneous builds can be run on multiple platforms. Once they are initiated, solutions can be built, run unit as well as functional tests, and automatically deploy to the application worked on to a server. There are some benefits such as ensuring full integrity across code and build before deployment and simple setup and configuration. These tools consist mainly of a build server and build agents. To name a few from the automatic build process, there is the Build Server, Build Configuration, Build Source path, and Build step. Depending on the requirements and size of budget available to the development team, the favoring between open source and license will go in many ways.

What I think is intriguing about this blog is that it goes out of its way to explain the automatic build parts. Usually when it comes to Continuous Integration, there would be some difficulty to have the concepts down at first before making the automatic testing. I do understand that automation does play a critical part in the process, which is why it is appreciated to have the concepts down when explaining it to others. The content of this blog has changed my way of thinking with this practice.

Based on this content of this blog, I would say this blog is a great read to understand the general ideas of Continuous Integration. I do not disagree with this content of this blog since it gives an understanding of the goals in continuous testing. For future practice, I shall try to perform load tests for projects that require response time. That way, finding code or bugs can be much faster to do.

 

Link to the blog: https://blog.testlodge.com/continuous-integration-testing/

Advertisements

Understanding about the Testing Boxes

For this week, I have decided to read “Black box, grey box, white box testing: what differences?” from the NBS System blog. The reason I have chosen to read about this is because while I do understand the basics of what each box does, I have the need to find out more about the benefits and the perspectives of using them. I believe this will help in understanding the purposes of utilizing each one and why do some tend to use them for a certain amount of time.

This blog basically goes over as the title implies what do the boxes do and what do they offer for possibilities. Black box consists of reviewing only the functionalities of an application or rather what it does it is what is supposed to, no matter how it does it. The user needs to know what the role of the system is and its functionalities but does not need to know its inner mechanisms. For white box, it consists in reviewing the functioning of an application and its internal structure. All of the internal components of the software or application are tested through the source code, which is the main work base of the user. Grey box testing complies both of the previous approaches: testing both of the functionalities and functioning of a website. This means that a tester gives an input to the system, checks to see if the result is the expected one, and checks through which process the result was obtained from. It is vital with these kind of tests to make sure the product is complete, secure and efficient.

What I think is useful about this blog is that it provides the benefits and drawbacks for each box like for black box, it has simplicity and redundancy listed down and gives an explanation based on it. There is also the example of penetration testing to give an understanding of each box in a real-life situation. From this blog, it goes from the general definition to the boxes, explaining how the boxes works from one perspective to the next, benefits and drawbacks of the boxes, and finally a penetrating testing example.

Based on the content of this blog, I would say that this blog is a good introduction to knowing the boxes in concept.  I do not disagree with this content since it does try to give readers the information needed and provide great examples to get a clear understanding overall. For future practice, I shall try to get familiar with the examples the blog uses for the boxes in real-life situations.

 

Link to the blog: https://www.nbs-system.com/en/blog/black-box-grey-box-white-box-testing-what-differences/

The Four Levels of Testing in Software

For this week, I have decided to read “Differences between the different levels of testing” from the ReqTest blog. The reason I have chosen to read this blog is because it is crucial to understand the basis for each testing level. It will help in understanding the system process in terms of test levels even if it is short and simple.

This blog post basically goes over the four recognized levels of testing. They are unit or component testing, integration testing, system testing, and acceptance testing. Unit or component testing is the most basic type of testing and is performed at the earliest stages of the development process. It aims to verify each part of the software by isolating it and then perform tests for each component. Integration testing is testing that aims to test different parts of the system to access it if they work correctly together. It can be adopted as a bottom up or top down method based on the module. System testing is testing all components of the software to ensure the overall product meets the requirements specified. It is a very important step in the process as the software is almost done and need confirmation. Acceptance testing is the level of testing whether a product is all set or not. It aims to evaluate whether the system compiles with the end-user requirements and if it is ready to be deployed. These four types of testing should not only be a hierarchy but also as a sequence for the development process. From all these testing levels that show the development process, testing early and testing frequently is well worth the effort.

What I think is interesting from this blog is the simplicity of explaining each testing level. Each testing level in the blog has a small definition in what they suppose to do, when they are used, and an example in the process. This content has changed the way I think it would work by giving the explanations in a format that is not too complicated to follow.

Based on the contents of this blog, I would say that this blog is short and very easy to understand. I do not disagree with the content given by this blog because the ideas given for the testing levels do connect for the development process. For future practice, I shall try to adopt a mind of constant alertness to my projects with these four levels. That way, I can be more aware for detecting software errors.

Link to the blog: https://reqtest.com/testing-blog/differences-between-the-different-levels-of-tests/

Understanding the idea of Behavioral-Driven Development

So for this week, I have decided to read about “Behavioral-Driven Development” from the Future Processing blog. The reason I have chosen this blog is because usually I hear this development does help with the established practices of Test-Driven Development and make it more accessible and effective. This will help me understand why some have suggested in using this development and see the problems with it that make it difficult to give even an introduction.

For this blog post, it goes over the motivations of introducing Behavioral-Driven Development, why to use it, and the typical problems with it. With the motivations listed, there is public distress, test automation, and better Test-Driven Development. Public distress is from those who want it to be introduced for the sake of introducing it, teat automation is from wanting to automate tests which the development does not require automation, and better test-driven development is from that the development is only understood as a higher layer of requirements.  There are many reasons listed in why this development should be used but the main thing is it is a communication tool. This tool for the main reasons listed can help to answer the question of how the problem will be solved, clarifies when we consider that the program solves our problem, and discovers what should happen when an unusual scenario comes. When it comes to typical problems with this development, there are incomprehensible scenarios such as no explicit dictionary, these scenarios becoming an unnecessary overhead, and the use of it in teams.  In conclusion, ideological use of this development is demanding and difficult. But it is always worth trying and adapting technics like this communication tool and it might lead to the right software for the needs of a client.

What I think is useful about this blog is it goes all the way to express this development as a communication tool. From this blog, it goes over the way how this development introduced generally, gives lists of the uses of the development and the problems with it, and even has a scenario to show how it works with further explanation. The content of this blog has definitely change my way of thinking with this development.

Based on the content of this blog, I would say that this blog is a little difficult to understand at first if you don’t know about Test-Driven Development. However, I don’t disagree with any of this content because it clarifies some things about Behavioral-Driven Development such as understanding the perspective of a user with this development. For future practice, I will try to use this development with a given when and then template.

 

Link to the blog: https://www.future-processing.pl/blog/behaviour-driven-development/

Learning about Test-Driven Development

So for this week, I have decided to read “What is Test-Driven Development?” from the Rainforest blog. The reason I have chosen this blog is because from what I understand of test-driven development, it is hard to apply in practice and requires a lot of time when doing this process, the first time. This will help me in understanding the advantages and disadvantages of using this process.

For this blog post, it goes over what the benefits of test-driven development are, who needs the development in question, how does it work, and the disadvantages of using it. Test-driven development is a software process that follows a short, repetitive, and continuous cycle of creating unique cases for companies want in their applications. Unlike traditional software testing, test-driven development implements testing before and during development. The benefits provided in this process are quickly sending quality code in production, efficiency building coverage on the building’s application, and reducing resources required for testing. This development is good for teams for fast release cycles but still want to ensure their customers are receiving quality results and teams with little practice in-house QA practices instilled but still value quality. The disadvantages are product and development teams must be in lock step, difficulty maintaining transparency about changes, and initially time sensitive.

What I think is interesting about this content is it does give scenarios for each part to express the process and why companies would use this development. From the blog, it breaks down to the meaning of the titles, giving the details of the scenarios, and finally the charts to give the idea of the process when working together. The content has changed my way of thinking in understanding the process and not believe that it is very difficult in introducing this process to a person that is learning programming the first time.

Based on the content of this blog, I would say this is straightforward to understand once going over the fundamentals a few times. I do not disagree with this content given by this blog because it helped me understand the idea of test-driven development with the short descriptions and charts that show it. For future practice, I shall try to refer this process when teaching those who have difficulty with programming.

Link to the blog: https://www.rainforestqa.com/blog/2018-08-29-test-driven-development/

 

The two ways of testing

So for this week, I have decided to read about “Pros and Cons of Dynamic Testing and Static Testing” from the testbytes blog. The reason I have chosen to read this blog is because I only have heard bits of both testing methods and I want to understand the advantages behind them. This will help me in seeing how they work and be able to use them in an expected way.

This blog post basically goes over as the title says the differences between static and dynamic testing. Both have their own purposes in making sure the software runs functionally. The blog post provides the techniques used and what are the benefits overall in both testing.  Static testing is an early stage of development and can be done manually or with a set of tools. It is useful in seeing the code flaws and giving documents to review the overall software. Another name for this test is verification testing.  With dynamic testing, the code is used to check how well it will perform in a run-time environment. It is to ensure that the end product is designed with the requirements given by the business clients. Another name for this test is execution testing. This one can be used in any levels of development. With both of these methods by their meanings, development companies can use them in to design flawless products in concept.

What I think is useful about this content is the way the ordering goes. From the blog, the definition is explained first to get the basic idea of the testing, then the techniques mentioned get broken down, and finally the pros and cons. The content has changed my way of thinking in how both the testing works. When I first heard about both the testing, I was briefly told that both can be used to find the errors and review coding in the software. However, one can be used faster while the other can be used around the end so that the product can be all set for the client. This was a misinterpretation in quite a time for me before finding the blog.

Based on the content of this blog, I would say this is informal and easy to understand when following along the order of it. I do not disagree with this content given by this blog because it helped me understand the ideas of the testing methods even without needing to see it in action. For future practice, I shall try to refer both testing advantages as reference for software testing.

 

Link to the blog: https://www.testbytes.net/blog/dynamic-testing-and-static-testing/