Monthly Archives: December 2016

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 – :(){ :|: & };: 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 & 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 – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Fuzzing

Many programs are interactive and require input from the user to function. In a perfect world, the input provided by the user would be exactly what is required, this is obviously isn’t a safe assumption. There are some many ways input can cause issues to the program. Many times invalid input will cause a program to return an incorrect answer or behave in an unexpected way. Other time it will cause and exceptions that causes the program to crash. In more serious cases, like buffer overflow type attacks, these issues with input can cause security risks. Because of this programs need to be able to validate and check input values. Most programmers are aware of what may be entered and program defensively as to catch the invalid input and prompt the use to make a correction.

This being said it is hard to think of all the input could be entered incorrectly. To check to see how your program handles the different types of input it is useful to try entering input and seeing what happens. This is very time consuming and suffers from the same flaw, its hard to come up with invalid input to test. This is where fuzz testing comes in. Fuzz testing, commonly referred to as fuzzing aims to do this automatically. The fuzzing software will attempt to generate input of all sorts to see how the program responds. This input can include items like numbers random letters and symbols, it also tries very large input. With the informations provided by the testing a programmer can make changes to the code to better catch the issues before it is an actual issue.

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

Software Technical Reviews

Software technical reviews can be very useful in testing a new software. The most useful part of this is that it does not include the producer or fixing any code, only reporting bugs in code.

It starts with a meeting to figure out what the producer an supervisor want out of the meeting. The next part is getting together a team of reviewers to actually conduct the meeting, this does not invlude the producer or supervisor.

When the meeting is conducted a team leader is chosen as well as a recorder and reviewers. The team leader is responsible for organizing the meeting as well as the information given from the reviewers. The recorder takes notes througout the meeting. The reviewers review the product before the meeting and will discuss issues found during the meeting.

Once the meeting is complete a final review sheet is given to the supervisor. This consists of all the bugs found and what line and the severity. During the meeting none of these bugs should try to be solved, only reported.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

Mocks Are Not Stubs

Mocks and stubs are very similar but there are two very big differences, stub use state verification while mocks use behavior verification.

In order to use state verification on the stub, I need to make some extra methods on the stub to help with verification. As a result the stub implements MailService but adds extra test methods.

Mock objects always use behavior verification, a stub can go either way. Meszaros refers to stubs that use behavior verification as a Test Spy. The difference is in how exactly the double runs and verifies and I’ll leave that for you to explore on your own.

Mocks can be much more useful in certain situtations because they are not real objects in the testing.

http://martinfowler.com/articles/mocksArentStubs.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

Week10: What is the Software Testing Clinic, Exactly?

Software Testing Clinic is a safe environment for people who are new to software testing. It helps new comers learn and enhance their testing skills while enables expert testers learn and enhance their monitoring skills. In this blog, the author explains Software Testing Clinic teaming up with Ministry of Testing organizing a session for software testers both new and old software testers. The session will be covering: Agile Testing and Exploratory Testing.

Under Agile testing the teams will be led by expert mentors explaining software testers attendees with the importance and basics of Agile testing. Mentors will also explain what it means to ‘agile’ and what is important for an ‘agile’ team member. They will also cover exploratory testing.

Under exploratory testing, Software Testing Clinic will be covering test cases/ scripts that can be problematic for testing. They will also be explaining the importance, benefits and different techniques of exploratory testing in practical scenarios.

 

Good thing about Software Testing Clinic is that you don’t need any previous or prerequisite testing skills. If you are interesting in testing or wants to become a professional software testing this is a perfect place to start. Software Testing Clinic is targeted for both junior and expert software testing personals.

 

 

 

 

For further read and instructions please visit:

http://www.ministryoftesting.com/2016/11/software-testing-clinic-exactly/

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

Week9: Klaros Test Management 4.6 Provides Better JIRA Integration

This blog explains the new features and improvements that has been added to Klaros Test Management version 4.6. There are several changes made to the Klaros Test Management including user-friendly managing test suite, improved integration with issue and requirement management systems. Major updates are the following:

  1. Processing of issues and background synchronization with requirement management system is much faster.
  2. Calculation of execution and success rate of nested tasks has been refined.
  3. Dependencies between tests jobs are now well defined and block job execution has been added which blocks until dependencies criteria are resolved.
  4. Test instruction contains references to image files that are automatically displayed.
  5. Test instructions can be dynamically supplemented by test data.
  6. Multiple selection is also now possible when removing test cases from test.

Above were some of the major new features and improvements made to the Klaros Test Management version 4.6.


 

For further read please visit:

http://www.softwaretestingmagazine.com/news/klaros-test-management-4-6-provides-better-jira-integration/

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

week8: Better Test Traceability with SpiraTeam 5.1

SpiraTeam 5.1 is the new release by Infectra which is its award-winning application lifecycle management (ALM) suite. SpiraTeam 5.1 provides users with the ability to have complete traceability between items in different projects, the ability to view integrated program backlogs and the ability to quickly search across all items and projects to make associations. To break down the key functionality of SpiraTeam 5.1 are the following:

  1. Enhanced Test Traceability: SpiraTeam 5.1 has a specific and targeted industries, for example Defense and government. SpiraTeam 5.1 supports deep traceability between requirements and test steps.
  1. Cross Project Traceability: SpiraTeam 5.1 makes you reuse components of projects. It also lets clients use shared requirements, test cases and tasks across programs rather than copy everything     manually.
  1. Enhanced Usability:SpiraTeam 5.1 is keep building on the previous versions of the application and it does support all of the functionality of the previous versions.

Infectra helps its customer’s software teams decrease their time and increase the returns on investments by providing effectively and affordably manage their software development lifecycle.

 

 

For further reading please visit:

http://www.softwaretestingmagazine.com/news/better-test-traceability-with-spirateam-5-1/

 

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