Testing "Software" Times

Now in my last blog post I talked about developer and tester walkthroughs. We have now been doing this for a while now and as with all new things you learn some lessons. Below is some advice that I can give to help you get the most of of these sessions: 1) Have decent kit If you are talking to someone in the office this is not a problem but If you are talking to remote workers, make sure that both parties have a decent microphone and headphones. Nothing is more frustrating than not be able to hear the person you are talking too, you may also miss an important point. 2) Don't be afraid to ask any questions If looking at code is a new experience for you then don't be afraid to ask any questions. Any code can seem complex and if you don't have much exposure to code it may seem daunting. However,  over time the answers to the simple questions will eventually grow into a good base understanding of the application and your questions will become a little more focused. 3) ...

In this blog post I am going to talk through a new technique that I have started where me, the tester, and the developer, have a walkthrough of a change that the developer has made for a particular feature. So what are these walkthroughs?  So these walkthroughs are a time for the developer and tester to get together and for the developer to talk through and explain the code changes that they have made. By talking through the code, I mean the actual code that the developer has written and not a demo of the new behaviour. During this session, the tester is free to ask any questions, this could range from questions about the code to questions about the effect that the code changes have on existing behaviour.  These sessions are time boxed to 30 minutes and typically take place before the developer has raised a pull request to merge the changes into the master branch. Why do we do them? In short - to find issues before I get a release.... but the 2 main reasons are based ...

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 ...

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...

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....

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...