Monthly Archives: December 2016

On the semester

Well for my last blog of the semester I figured I would give
some thoughts on the semester and my experience blogging. I don’t anticipate
this to be very long but here goes. At first I was unsure what to make of
blogging as I had never done it before, but as I got into it I thought that it
is a great idea to get your ideas out there and to have others see what you’re
up to and what the latest testing and development tools and techniques you have
been using. It seems to be great as well for others to possibly give feedback
on what you’ve written or input on experiences they may have had and can give
advice on how to improve on what you have been doing.
That being said, as far as having to try and come up with
something to write every week after checking out 5 blogs on testing and picking
one that seems to be interesting to you ended up feeling more like a chore to
me. I am not saying I didn’t learn anything or that I didn’t enjoy seeing what
types of testing styles and techniques folks are using in the industry as I
have never worked in the industry as of yet and it gave me a glimpse into what
I might be working with and getting involved in possible. My main issue was
that I was writing about something that I have had no practical experience in
so it was hard to talk about something I haven’t used. I mean it was fine for a
few blogs, but after writing about testing techniques that other people are
writing about, you begin to realize that there seems to be only so many things
and a lot of the blogs talk about similar things or experiences, just in
different companies or settings. The name changed but the test stayed similar.

Overall it was a great learning experience and I would take
any of it back and I hope that some of you had a good experience as well and it
was a pleasure to spend the semester with all of you.

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

On the semester

Well for my last blog of the semester I figured I would give
some thoughts on the semester and my experience blogging. I don’t anticipate
this to be very long but here goes. At first I was unsure what to make of
blogging as I had never done it before, but as I got into it I thought that it
is a great idea to get your ideas out there and to have others see what you’re
up to and what the latest testing and development tools and techniques you have
been using. It seems to be great as well for others to possibly give feedback
on what you’ve written or input on experiences they may have had and can give
advice on how to improve on what you have been doing.
That being said, as far as having to try and come up with
something to write every week after checking out 5 blogs on testing and picking
one that seems to be interesting to you ended up feeling more like a chore to
me. I am not saying I didn’t learn anything or that I didn’t enjoy seeing what
types of testing styles and techniques folks are using in the industry as I
have never worked in the industry as of yet and it gave me a glimpse into what
I might be working with and getting involved in possible. My main issue was
that I was writing about something that I have had no practical experience in
so it was hard to talk about something I haven’t used. I mean it was fine for a
few blogs, but after writing about testing techniques that other people are
writing about, you begin to realize that there seems to be only so many things
and a lot of the blogs talk about similar things or experiences, just in
different companies or settings. The name changed but the test stayed similar.

Overall it was a great learning experience and I would take
any of it back and I hope that some of you had a good experience as well and it
was a pleasure to spend the semester with all of you.

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

On the semester

Well for my last blog of the semester I figured I would give
some thoughts on the semester and my experience blogging. I don’t anticipate
this to be very long but here goes. At first I was unsure what to make of
blogging as I had never done it before, but as I got into it I thought that it
is a great idea to get your ideas out there and to have others see what you’re
up to and what the latest testing and development tools and techniques you have
been using. It seems to be great as well for others to possibly give feedback
on what you’ve written or input on experiences they may have had and can give
advice on how to improve on what you have been doing.
That being said, as far as having to try and come up with
something to write every week after checking out 5 blogs on testing and picking
one that seems to be interesting to you ended up feeling more like a chore to
me. I am not saying I didn’t learn anything or that I didn’t enjoy seeing what
types of testing styles and techniques folks are using in the industry as I
have never worked in the industry as of yet and it gave me a glimpse into what
I might be working with and getting involved in possible. My main issue was
that I was writing about something that I have had no practical experience in
so it was hard to talk about something I haven’t used. I mean it was fine for a
few blogs, but after writing about testing techniques that other people are
writing about, you begin to realize that there seems to be only so many things
and a lot of the blogs talk about similar things or experiences, just in
different companies or settings. The name changed but the test stayed similar.

Overall it was a great learning experience and I would take
any of it back and I hope that some of you had a good experience as well and it
was a pleasure to spend the semester with all of you.

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

On the semester

Well for my last blog of the semester I figured I would give some thoughts on the semester and my experience blogging. I don’t anticipate this to be very long but here goes. At first I was unsure what to make of blogging as I had never done it before, but as I got into it I thought that it is a great idea to get your ideas out there and to have others see what you’re up to and what the latest testing and development tools and techniques you have been using. It seems to be great as well for others to possibly give feedback on what you’ve written or input on experiences they may have had and can give advice on how to improve on what you have been doing.
That being said, as far as having to try and come up with something to write every week after checking out 5 blogs on testing and picking one that seems to be interesting to you ended up feeling more like a chore to me. I am not saying I didn’t learn anything or that I didn’t enjoy seeing what types of testing styles and techniques folks are using in the industry as I have never worked in the industry as of yet and it gave me a glimpse into what I might be working with and getting involved in possible. My main issue was that I was writing about something that I have had no practical experience in so it was hard to talk about something I haven’t used. I mean it was fine for a few blogs, but after writing about testing techniques that other people are writing about, you begin to realize that there seems to be only so many things and a lot of the blogs talk about similar things or experiences, just in different companies or settings. The name changed but the test stayed similar.

Overall it was a great learning experience and I would take any of it back and I hope that some of you had a good experience as well and it was a pleasure to spend the semester with all of you.

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

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.