Testing "Software" Times

Company wide test strategies can often be very procedural and rigid, which, in turn can lead to them not being followed as well as not utilising the full range of testing skills on a team. So, is there an alternative…? This article will look at why company test strategies may not work, what a testing and quality vision is and how they can utilise the skills of the team. Finally, it will go through metrics and how these can be used to measure the vision. Teams At some point in our lives, we have all worked as part of a team. That might have been at school sports day, a team building event or as part of a cross functional team delivering software solutions. Regardless of where that team originates from, I think it’s fair to say that everyone in a team has a different set of skills than the ones they need for their job.  For example, you could have a ‘manual’ tester who performs exploratory testing as part of their job but they may also have skills in requirements analysis. If we take...

This blog post is in response to Challenge 7 of the #GivenWhenThenWithStyle blog post series with Gojko Adzic  You can see what the challenge is here: https://specflow.org/blog/how-to-deal-with-external-data-formats-givenwhenthenwithstyle/ Having the message format in the test would  (as mentioned in the challenge) look terrible and would be difficult to understand.  If I was to rewrite this scenario I would do something like the following: 1) Write a test that tests the validity of the payment message. So something like Scenario : payment message validity Given an account EE382200221020145685 has a balance When the system receives a payment message Then the payment message is valid.  I would store the actual payment message in another file as not to clutter the scenario file and this message would be passed into the test in the When line. The Then part of the test could cover various areas, such as: - All the correct tags are present  - The xml is valid 2) I wo...

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide...

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

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

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