Testing "Software" Times

So testing Web Services and REST APIs is not something that I have regularly spent a great deal of time doing (although I have done some). However, a change to a customers requirements meant that I had the opportunity to test a SOAP Web Service in a little more depth. Now I have used Postman to test Rest APIs but I had not used it to test SOAP Web Services. I wasn't sure If I could do it but I thought I would give it a go...  So in this post I will show how you can use Postman to test a SOAP Web Services via the postman UI and the sendRequest method. So what did I do? The service I will use for this blog post is one provided by W3schools which converted Celsius to Fahrenheit and Visa Versa. Here it is :)  https://www.w3schools.com/xml/tempconvert.asmx So first of all I had to work out how to call a SOAP Web Service using postman. So a quick look on the Postman web site and I found that I needed to:  Set the URL to be the Soap Endpoint  Set the request method to POST

Log files are funny things. They can contain lots of useful information but they can also be a frustrating experience to understand and read.  Typically when an error occurs in an application there will usually be an entry in a log file. So in the current application I am testing, I know that when I see an unhandled exception in the UI there will be an entry in the log file which will tell me why and where the error occurred. So imagine my surprise when during a testing session in which I was  looking for a particular entry in a log file, I noticed that there was an error and I realised that at that time I had not noticed any strange or peculiar behaviour in the UI. This got me thinking about how I can find bugs that do not manifest themselves in the UI......   Now at the time we didn't have any log file analysis tools like Splunk and after seeing the error in the logs I thought it would be a good idea to some how monitor the log files. Now complex enterprise analysis tools l

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 upon a co