Testing "Software" Times

I've been meaning to do this for a while and I have finally got round to it...... S o, there are loads of blog posts out there and sometimes it can be a hassle trying to find an old blog post that you remember  reading and that you want to reference again. Now people may have there own workflow for how they keep/store interesting blog posts that they have read. So for me this is as follows: 1) See an interesting link to a blog post via twitter or some other medium 2) Save it to Pocket and tag it with "Testing" 3) At some stage in the future when I get time, I will read it 3) After reading it, if I think is is decent, I will favorite it and then archive it in pocket (Now I have IFTTT set up to move these posts to a notebook in Evernote called Reading) 4) Once in Evernote I then look at the post again and tag it with a relevant tag (e.g. Automation) and then move it to another notebook for future reference Now as you can see this is quite a long process and I'm s

In this post I am going to continue my servies on BenchMarkDotNet and I will explain what the various parameters do that are present in the simplejob attribute.  Now I say all....... the documentation is not great so I will explain what 3 out of the 4 do :) So If you remember in my previous post I had a MyFirstBenchmark class which contained the details about the benchmark test that I wanted to run. In this class there is an attribute called SimpleJob and this attribute contains a few parameters that can be configured when you run a test.  By default BenchMarkDotNet will choose the number of iterations that will return the best precision. However, using the simplejob attribute allows you to quickly get a set of statistics. Below is how my test was setup: Now as you can see I had the following parameters in the SimpleJob attribute: launchCount - This parameter allows you to define how many times the benchmarking test is run warmupCount - This parameter a

A bit of a change to my normal blog posts this time.... In the next few posts I will be talking about benchmark testing and in particular a NuGet package that allows you to run bench-marking tests in a .NET environment.  So in this post I will demonstrate how you can use a NuGet package to measure the time it takes to open notepad on your local machine.  This will be the starting point and I am aiming to build up some more complex examples as I learn about the NuGet package.  So here goes....... The NuGet package is called BenchMarkDotNet and is a powerful library for bench-marking various tasks.  The GitHub page can be found here: https://github.com/dotnet/BenchmarkDotNet So to use this package, the first thing you need to do is create a new Console App (.NET Framework) project in Visual Studio  You then need to add the NuGet package to the project (You should find the NuGet package if you search for 'BenchMarkDotNet'): At the time of

Trust & Automation The word trust, what springs to mind when you hear that word? Often we hear this word regarding companies like Facebook and Google. We like to think that we can trust these companies but like with the recent Facebook and Cambridge analytica story, that may not always be the case. Yes, we can complain and say how outrageous it is but at the end of the day if we read the terms and conditions as well as all the other small print we would probably all have a rough idea of what we are setting ourselves up for. After all if the application is free there is probably a catch..... Trust can be defined as: noun 1. reliance   on   the   integrity,   strength,   ability,   surety,   etc.,   of   a   person   or  thing;   confidence. link:  http://www.dictionary.com/browse/trust Now trust is important when that reliance is required by us in order to perform our roles as testers. In this article I am taking about trust in the automation space…..

Testing a new application can be a challenge and a little bit daunting. Below are a few useful tips that will hopefully help your testing, should you find yourself having a test an application that you have never used before. (These tips assume that you know about the applications main purpose and that maybe you have seen a demo of it.) Tip 1 - Talk to the developers Talking to the developer is a valuable resource of information about the application that you are testing. When talking to the developers you should do the following: Find out how the application works Developers are going to know better than most about how the application works. They will know things like the following What technologies the application is built on What is the architecture Does the application have any configuration options Areas of the code that caused them problems Talk through bugs you raise with the developers Going through a bug with a developer can give you insight into how the s