Monthly Archives: December 2016

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 – :(){ :|: & };: 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 & 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 – :(){ :|: & };: 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.