Monthly Archives: December 2016

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.

Week7: Sauce Labs Acquires TestObject

TestObject is a real device mobile app testing platform. This will provide Sauce Labs to market automated testing for desktops, emulators, simulators, and real devices for web applications, mobile, web, hybrid and apps.

According to Charles Ramsey, CEO of Sauce Labs, the reason behind that made TestObject a beneficial product for Sauce Labs to acquire was TestObject’s high speed and reliable real device testing for mobile applications. This step will give Sauce Labs customers a single platform where both web and mobile testing solution can be accessible.

Sauce Labs is currently the largest cloud based automated testing platform on the market with 1 million tests per day and more than 800 million test run to date. By acquiring TestObject will bring additional 200+ devices, private cloud solution for enterprises, and high-speed manual testing on real devices. This will give Sauce Labs huge edge over its competitors.

 

 

Further read please visit:

http://www.softwaretestingmagazine.com/news/sauce-labs-acquires-testobject/

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.

Week6: Shift Left: Testing in the Agile World

In this blog, the author Kishan Sundar explains Agile testing with approach of software testing activities known as “Shift Left”. Agile testing is very important in today’s highly competitive market. With Agile testing product/software are guaranteed for quick release, it also prevents defects and makes room for reassessment and upcoming plans/future of the software. With Agile testing software development occurs in steps known as sprints. Once one sprint is complete another sprint begins. In another words, one sprint leads to another subsequent sprint. The shift left approach in agile testing introduces development and testing happening simultaneously.

 week6

Above picture shows Shift Left approach

 

Sundar emphasize on the importance of the role of assurance specialists in the agile model. The reason of this emphasize is because of the comprehensive testing and quick release of the product/software. Here are some of the places where assurance specialists have to be involved:

  1. Since early stages of testing, testers are called in for field testing to interact with customer or product owner.
  2. With Shift Left approach of agile testing initial interaction will also involve epic owners and enterprise architect on how the product/software will be rolled out.
  3. There is also interaction with program management to determine timelines and decide, how should the release of software should be managed.
  4. Assurance team and agile team will be both part of the development team. There would be two teams: test developers and code developers.

With shift left approach of the agile testing performance and development is intensify with less defects and better performance.

 

 

For further reading please visit:

http://www.softwaretestingmagazine.com/knowledge/shift-left-testing-in-the-agile-world/

 

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.

In memory testing

I really enjoyed this blog because I had never heard of in
memory databases before this. They do however make sense to me. I had always
thought of databases as their own unit, but never really gave much thought to
an in memory one. The fast access for certain programs makes a huge amount of
sense and I can see the uses for them as he gave examples of routing tables and
event poster.
What was interesting is that I can see the use for things
such as router tables, but didn’t give much thought to the testing uses part of
it. Databases can be overwhelmingly large and when it comes to testing, I
imagine that that size comes with a cost, speed. In comes in memory databases
to the rescue. It drastically reduces the time to test because of the speed
that memory works at which in my mind can increase the output of the product
possibly.
I think that if I ever do a lot of testing this is something
that I may indeed try out. You can read more about it here:

http://www.martinfowler.com/bliki/InMemoryTestDatabase.html

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.