Monthly Archives: December 2016

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.

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.

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.

Hadoop

Installing Hadoop ran into issues initially with the fact that the document for installing is outdated. The mirror link for getting Hadoop is 404ed. The Java version moved onto 8 instead of using 7.  I chose the latest stable version (2.7.3) on the Hadoop website to install.

Instead of using my account, I created a Hadoop account and sshed using that. Ubuntu does not Sudo by default so I had Sudo my Hadoop account or else anything accessing root will be blocked. I also ran into issues where NameNode and DataNode would not start up at all no matter what I did. After experimenting I realized that forcing a creation of hdfs folder with namenode and datanode was conflicting with what Hadoop wanted to do. Hadoop now automatically create both directories which allows my Hadoop to run smoothly.

The experiment I did with Hadoop is the word count example which WordCount.java will compute the word frequency of all text files in the HDFS input directory.  Using the program, I began to understood the advantage of using Hadoop. The MapReduce job splits the data and processes them in multiple parallel processing.  This seems especially advantageous working with multiple larger files.

 

http://hadoop.apache.org/

http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-node-cluster/

http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-node-cluster/

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

5 Excuses Every Software Tester Must Stop Giving

Week 12 blog post for Software Testing

This week i have decided to read 5 Excuses Every Software Tester Must Stop Giving by Mahesh C..

As i am still relatively new to the world of software testing i am very interested in what exactly software testers do on a daily basis. What better way to do that then by looking at excuses software testers make very frequently, it was my hope to gain insight into the software testing world through this article.

The first excuse was “we don’t control our Test Environment, we have limited access”. The article then goes over the benefits of being able to fully control the environment. an example of this being ” You know all involved components, all software used along with their versions for your product to function. With time, trust me you will have many insights about their working, limitations and possible failure points.”. More importantly it discusses how you can actually do this within a team/ organization. They suggest starting to work very closely with a developer team and start to learn how they do everything and once you have shown competence ask them for control and logically they should give it to you.

The next excuse was “We don’t deploy a build, some other team does it for us”. They then discuss why this is a bad attitude to have, and their explanation is something that resonates with me personally. They suggest that deployment teaches you a lot due to it not always working and failing often means you are forced to learn and debug. This is something that i have personally learned, through my own experience.

Then it goes to “We don’t debug an issue, we find steps and log it”. In order for personal growth it is better to ask yourself a few personal questions and make sure the reason for the bug isn’t easily determined.

4. “I don’t know why it happened. Developer resolved it and i simply verified it”. This is somthing i completely understand. Learn from the developer and thenmaybe next time you won’t need them to fix it and you can do it yourself. A lot of these excuses are just plain lazy from ever perspective.

5. “I didn’t get the opportunity to work on anything else than Manual Testing”. There are time actors involved however there is always that extra bit of time where you could do these things. Again this comes down to the testers being just plain lazy.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

The Complete Beginner’s Guide to Responsive Web Design Testing

Week 11 Blog Post for Software Testing

This week i decided to read The Complete Beginner’s Guide to Responsive Web Design Testing by Laxmi

This article was of interest to me because in my Software Construction class i am developing a web application as my final project. Therefore i have become slightly more interested in web design and the testing that is involved with it.

One of the largest issues of this generation is that you do not know if the user will be on a cell phone a tablet a laptop or even a TV and the screen sizes for all of these devices range from 4 inches to 60 inches. Therefore you need to develop your web application in a way that it is able to look good and work properly on all of these devices. they define responsive design as “one website for every screen”. Although it encompasses much more than that. They later go on further to define it as a website designed to have a superior user experience, easy navigation, clear and simple interface, able to adapt easily and work in all resolutions, browsers, screen sizes, hardware, and operating systems.

This is done through flexible layouts, media queries, and flexible media. The issue is how do you test if a website is responsive without pulling it up on all of the possible screen sizes which is impossible to do. This is where software testing tools come in that change the screen size and resolution allowing you to test for a large variety of devices.

As i am developing a web application myself i found this article to be interesting and helpful at the same time. I look forward to optimizing my website using the information that i have learned in order to create a better experience for the user.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week4: Difference Between Unit, Integration and Functional Testing

There are key differences between unit, integration and functional testing. Each testing process has its own importance and role in the testing process of software. Let us explore these difference by explaining each one at a time:

Unit Testing:

The name of this test is self-explanatory. We are testing for the smallest units of individual functions, methods, etc. Unit testing is done before integration testing by the software developers. It checks for correct or failure output for valid or invalid inputs. Unit test tests small pieces of code. Unit test cases simplify and make testing of coding easier because it becomes easier to resolve issues at later stage. Unit testing saves time and money because it is reusable and easy to maintain.

Integration Testing:

Integration testing is testing the integration of the different part of the system together. The goal of integration testing is to check for functionality, reliability, and performance of the system. It is done on modules that are unit tested first and then integration testing defines the combination of modules gives desired output or not. There are three approaches of integration testing: big bang, top-down and bottom-up.

Functional Testing:

Like unit testing name, functional testing is self-explanatory from its name. It is testing the functionality of the application. It tests whether the application is providing the desired output for a certain input. Testing is done by per requirement and scenario. Here are the major parts of functional testing: test summary, prerequisites (if any), test case input steps, test data (if any), expected output, and notes (if any)

Detailed differences are provided in a nice table format on the website, but the three testings’ techniques are correlated. Unit testing is needed for paths/lines of code, functional and integration testing is needed for assurance.

 

 

For more detail reading please visit:

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

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.

What Test Engineers do at Google: Building Test Infrastructure

Week 10 Blog Post for Software Testing

This week i decided to read what Test Engineers do at Google: Building Test Infrastructure by Jochen Wuttke

As google is a popular company and i am new to the world of testing, this article was of immediate interest to me. I was excited to learn what careers in testing were like and what better way to do that then by a test engineer at one of the most popular companies on the planet.  Although this article does not talk about all the different things that the test engineers do, it only discusses one aspect of their work which in this case is :building and improving test infrastructure to make engineers more productive.”

One part of this is replacing legacy systems. A legacy system at google was costing engineers countless hours that they could be spending elsewhere. A replacement takes a long time to build so they had to continue using and updating the legacy system as they went. However this allowed them to learn from the legacy system and not make the same mistakes in the new system. The engineers found two major concerns to fix in the new system. Those were “Tight coupling and insufficient abstraction made unit testing very hard, and as a consequence, a lot of end-to-end tests served as functional tests of that code. ” and ” The infrastructure used for the end-to-end tests had no good way to create and inject fakes or mocks for these services. As a result, the tests had to run the large number of servers for all these external dependencies. This led to very large and brittle tests that our existing test execution infrastructure was not able to handle reliably.”

Once they had found the problem they had to figure out the solution which is the hard part. After quite a few prototypes and a year of time a few testing engineers where able to build a new tool that solved the problems they were looking to solve. The next step was teh adoption of the new system, which is never an easy process. This process took them a couple of months in order to fully implement. The results were that the new tests were more effective at finding bugs. The new tests ran in 3 minutes compared the older suite running in thirty minutes and the client side tests are 0% percent flaky.

Although i didn’t completely the implementation it was quite interesting to see the process a tester took in their day to day lives.

Here are some other articles that i found interesting:

http://qahiccupps.blogspot.com/2016/11/something-of-note.html

https://blog.tentamen.eu/value-of-ui-automation-tests/

http://qahiccupps.blogspot.com/2016/11/the-dots.html

http://angryweasel.com/blog/teams/

 

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Understanding The Difference Between Unit, Integration and Functional Testing

Week 9 Software Testing Blog

This week i have decided to read Understanding The Difference Between Unit, Integration and Functional Testing by Sushma S.
The article uses a login page as an example to help explain the difference between unit, integration, and functional testing. The reason for this is that a login page is extremely common and usually used in most web applications. It then goes over the cases for each type of testing and they are as follows:

Unit Testing –

Field  length for username and password

input field values should be valid

login button is enabled only after valid values are entered in both fields

Integration Testing –

user sees the welcome message after entering valid values and pushing the login button

users should be navigated to the welcome page or home page after valid entry and clicking login button

Functional Testing –

the expected behavior is checked

welcome message after succesfull login

can an inactivated user login

is there a forgot password link

Unit testing is generally done by the software developer who knows the code well. It is important for finding bugs early on in the development process, and is done before any integration or integration testing occurs. “Unit tests save time and cost, and it is reusable and easy to maintain”. After unit testing comes integration testing. After everything has been tested as a unit then integration testing occurs.
This when the units are put together and tested as a whole. This tests how the system works together and verifies that the behavior is correct. Then there is functional testing. This is a black box technique where the functionality of the system is tested. This basically means that we are testing that the behavior of the application and not the code itself. In order to successfully test an application you need to use all three testing methods. This provides the best test suite where any possible bugs should be found.

Here are some other links that i found usefulL:

https://blog.tentamen.eu/cleanup-order-in-selenium-headless-test/

http://www.softwaretestinghelp.com/how-perform-software-product-testing/

http://blog.smartbear.com/api-testing/top-5-api-testing-blog-posts-of-2016/

http://rhythmoftesting.blogspot.com/2016/12/thoughts-on-agile-testing-days-2016-pt-2.html

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week3: Organizing Tests with xUnit Traits

It is very important that the code you write or look at is well organized because it gives the code reader to break it down and understand it better. It also shows your image as a good coder. The author of the blog explains that for large numbers of tests, needs to be broken down into categories or groups which will provide clarity and insight to testing code. He suggests one way to do it is with xUnit which might also be refer to as TraitAttribute.

The blog explains couple of benefits using traits attributes as organizing tests: first, that traits attributes uses a name and value pair. Second, when using a GUI based test runner like test runner in Visual Studio tests can be sorted according. For tests by traits to run, both key and value of the trait has to be specified on the command line.

 

 

 

For further reading please visit:

http://www.brendanconnolly.net/organizing-tests-with-xunit-traits/

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.