Monthly Archives: December 2016

Mutation Testing (Week 12)

Mutation Testing is a fault based testing technique that variants of a program are changed to determine the effectiveness of the test to identify problems. Some ways this can be done are by changing operators, for instance if you have a function that says “gpa<4.0” a mutation test would be if you changed it to “gpa>4.0” to see if the test case caught the fault. You could do statement removal, where you completely remove a statement to see if the test cases catch the defect, or you can insert the wrong syntax. All of these examples are valid forms of mutation testing.

 

Article i used: http://www.softwaretestinghelp.com/what-is-mutation-testing/

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Unit Testing, Integration Testing, and Functional Testing (Week 11)

 

To conduct a thorough test of software, unit testing, integration testing, and functional testing are all important because they employ unique processes to test the software the at the others don’t use.  To understand these types of testing lets look at a real world example of a battery and a phone sim card. 

Unit testing would be when the battery is checked to see if it has life, and capacity, and the sim card would be checked for activation. 

Integration Testing would be when the battery and sim card are assembles in order to start the phone

Functional Testing would be when the functionality of the phone is checked in terms of features and battery usage as well as the sim card. 

If only one of these procedures were conducted in testing, the test would not be complete. All of these need to be done to ensure that the product is working up to standards. 

Article i used : http://www.softwaretestinghelp.com/the-difference-between-unit-integration-and-functional-testing/

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Unit testing (Week 10)

 

Unit testing is a testing method in which individual pieces of code, sets of one or more computer programs work together with control data, usage procedures and operating procedures, which are all tested to make sure they are fit for use. 

So why would unit testing be good? Firstly, unit testing increases the confidence in changing code, if good unit tests are written and work every time the code is run, it will be easy to find any defects introduced by the new code. Finding a defect would be easy, when a test fails, only the latest changes need to be debugged. When you are testing at higher levels, you may have to test for weeks of work, rather than the next working version, which could have been done in a day. 

 

Article i Used : http://softwaretestingfundamentals.com/unit-testing/

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Manual Testing(Week 9)

Manual testing is the process of manually testing software for defects. It requires the tester to assume the role of the user and use the features that the software provides to ensure there are no errors.

The goal for this kind of testing is to make sure that the application or software at test is defect free and working tol the standards it needs to be working to. This kind of testing should be essential before the release of an application or software. If it is not thoroughly tested, from front to end, and defects pop up, time will have to be allocated to that defect. It is better to handle them before release, this way the developers have the code fresh in their minds, and may be able to detect where the problem is coming from.

 

Article i Used: http://www.softwaretestingclass.com/what-is-manual-testing/

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Importance of Acceptance Testing

Most software development companies don’t start with a fresh idea of there own and see it through to the end. In many cases a client will contact a development software company with and idea for a project the would like built to fill a certain need of theirs. In this type of situation there must be communications between the client and the development team. Most of the time the developers themselves wont have specific knowledge in the area of the new software.

This process starts with getting the client to form a set of requirement and expectations. This process can be aided by the developer by asking questions to clarify what the client is looking for. Even with a great plan and list of what the client is looking for it the final program doesn’t always do what is really wanted.

I have seen this first hand working a a small Internet company. There has been several times the owner of the company has gone to the development team with and idea. As a team they listen to what the owner is looking for and repeat their interpretation of it. They continue this back and forth until both side are satisfied. The development team then works to produce the discussed program. After the program is complete the final product is presented to the owner. Usually everything is all set but in some cases the response is “this doesn’t do what I want it to”.

There are several reasons that can lead to situations like this. First is an unreal expectation. Some projects are to complex or just not feasible. Some times it is because the client didn’t, themselves, really know what they wanted. Other times it is because the developer didn’t understand the requirements completely.

In any case, the situation could benefit for acceptance testing along the way. As the development team starts to develop starts to produce a product they can go back to the client and show them the current status to ensure it is what they are looking for. On method that would help is the use of Wireframes. I have written about this is a previous article.  https://rmurphy12blog.wordpress.com/2016/10/29/wireframe-testing/

From the blog CS@WSU – :(){ :|: &amp; };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Week12: How to Perform Poor Testing-A Primer for Self-Improvement

The goal of this article is to point out mistakes of poor testers and helps them improve on skills and warn them from making certain mistakes that might lead to some serious faults in their software/product. Poor testing leads to poor client experience which can serious hurt company’s profitability and sales. Poor testing can be more expensive for a company because it will lead to more time and money investment to fix those errors that were left.

week12.PNG

Above image shows consequences of poor testing

            The article goes into greater detail of the Do’s and Don’ts of poor testing. Here is a list of the Don’ts of poor testing:

  1. Don’t add stress
  2. Don’t test beyond the specified limits
  3. Don’t test with unusual combinations of events
  4. Don’t check all inputs and outputs
  5. Don’t follow up

 

Here is a list of the Do’s of poor testing:

  1. Let the designer create the test plan
  2. Test only against the normal input values
  3. Prepare test plans that are not consistent with historical evidence
  4. Provide a comfortable air-conditioned environment
  5. Forget about extreme situations
  6. Ignore the FMEA or fault tree

 

Here is a list of some tips to avoid poor testing:

  1. Evaluate your metrics
  2. Maintain an effective tester’s toolbox
  3. Avoid chaos by over adherence to processes
  4. Maintain self-maintaining test
  5. Culture of concurrent development teams

 

The article goes into greater detail inside each of the above category.

 

Please visit for detail reading:

http://www.softwaretestinggenius.com/how-to-perform-poor-testing-a-primer-for-self-improvement

From the blog CS443 Software Quality Assurance &amp; Testing – Computer Science World by Haider Hussain and used with permission of the author. All other rights reserved by the author.

Integration Testing

Integration testing is one of the three major categories of testing. It falls between unit testing and functional testing. Integration testing is the step when you begin to test the individual parts of a program with each other. This can be a tricky task as there are often times when not all the required parts are developed.

There are three ways of preforming integration testing:

~ Top Down

~ Bottom Up

~ Big Bang

In top down integration testing you start with the top level and work your way to the bottom. As you start with the top many lower levels have not been coded yet. For these you write stubs that hold the palace and provide canned answers. These stubs do just enough so that you can ensure you upper levels work. A disadvantage of this method is the amount of throw away code required for the stubs.

The next approach is bottom up. This is, as it sounds, the opposite of top down. In this method you start by testing the lowest level parts and work your way up. Like in the top down approach there is a certain amount of throw away code required. The difference is instead of stubs you must write drivers. These drivers are used to call the necessary actions to ensure the low levels are working. This method leaves on main issue, design flaws in the project are usually not discovered until a lot of effort has been put in.

The Final method of integration testing known as the big bang approach. This involves waiting for most of the code to be developed and integrating all at once. This is good because there is no throw away code but it becomes very hard to identify issues.

From the blog CS@WSU – :(){ :|: &amp; };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Week11: Software is Everywhere

I really liked reading this blog because this blog covered the core issue of what software testing is all about? In today’s technological world computers are everywhere. According to this blog, by the year 2020 there will be more than 50 billion devices connected to the internet. All of this connectivity needs systems and software that are safe, robust and secure. Security is main goal here. In the real world, software with bugs that are not properly tested or carefully designed so that all bugs were resolved results in greater cost to both the builder and buyer of the software.

Two major teams worked together in order to discuss and build software that is secure and up to the expectation of the market. Codenomicon and Coverity teamed up as Synosys Software team. Codenomicon is the leader of industry suite of black box security testing technologies. Coverity is an award winning source code analysist. The combination of both team resulted in the best product in the market. Their product suite is better described by the following picture:

week11

Above picture explains total vulnerability management

The goal of the team was to reduce the cost and risks related software by eliminating the root cause of the software. This blog explains in greater detail every aspect of the software vulnerability, but the emphasize was on developing tools and processes that are needed to produce safe, robust and secure software with perfect functionality and speed.

 

 

 

For detail read please visit:

http://blog.coverity.com/2015/08/04/software-everywhere/#.WFhijFxlc3A

From the blog CS443 Software Quality Assurance &amp; Testing – Computer Science World by Haider Hussain and used with permission of the author. All other rights reserved by the author.

Buffer Overflow

A Buffer Overflow is when information is written into a buffer that is to small to held and memory next to the buffer is overwritten.  Buffer overflows are usually associated with the C programming language because there is no array bounds checking. Buffer Overflows can be used by an attacker to run malicious code by overwriting it after overflowing the buffer. To combat such an attack a programmer needs to always be aware where “buffers” are initialized and if there are checks in the code that make sure that the buffer is not exceeded.

From the blog CS@Worcester – Site Title by volk676 and used with permission of the author. All other rights reserved by the author.

Unit, Integration, and Functional Testing

When talking about software testing there are different levels to consider. These different stages of testing go along with the different stages of development. It is obvious you can’t test the final program while only several small parts have been coded. And it would not make sense to wait until you have a completed project to start testing. The two processes need to work together. These different levels of testing can be summarized by three categories; Unit Testing, Integrations Testing, and Functional Testing.
I like the cell phone example Sushma S. uses in her blog.

~ Unit testing: the battery is checked for its life, capacity and other parameters. Sim card is checked for its activation.

~ Integration Testing: battery and sim card are integrated i.e. assembled in order to start the mobile phone.

~ Functional Testing: the functionality of the mobile phone is checked in terms of its features and also battery usage as well as sim card facilities.

Unit testing is the lowest level of testing. As a developer begins to code the parts of a system it is important to test that the it preform as expected. These individual parts are tested in units. Once there are several units developed one must ensure they work together. This could include having access to the necessary information as well as making sure the output of one part lines up with the input of the next. The final level of testing is functional testing. This is where the overall product can be tested to see if it operates in the way it was intended and to see that if satisfies all the needs of the end user.

http://www.softwaretestinghelp.com/the-difference-between-unit-integration-and-functional-testing/

From the blog CS@WSU – :(){ :|: &amp; };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.