Software Testing and Development Blog Posts
Subscribe to the full blog feed using RSS
Subscribe to the full blog feed using RSS
TLDR; We can use JUnit to execute code to support any type of testing.
TLDR: fixes are important. when we have work to do, sometimes a workaround is more important
Here’s the situation. You’ve written some code to automatically execute your application. You’re using Selenium WebDriver. Bam. Something goes wrong. You don’t know what to do. Here are some tips.
I have deliberately created a failing test. Obviously deliberately since I would never ever create such simple issues in code.
TLDR; Condemn? No. Support? I do like parts of the paper. Censor? No.
And now I’m doing something I don’t like: writing a blog post in response to ‘something on the internet’. I’m writing a blog post which I don’t think has any practical value. I warn you now. I don’t think you will find much humour herein either. I have added a comedy punchline at the bottom though, if you want to skip ahead.
A webinar in partnership with QA Symphony on 28th June 2016. What is Risk? How do we use it to help us test? What are the risk of testing in certain ways? What are the risks of not testing with a technical focus and exploratory mindset?
TLDR; I try to write tests at an appropriate semantic level so I never need to create dependencies between @Test methods, I re-use abstraction calls instead of dependencies between @Test methods.
May 2016 in London, at the National Software Testing Conference 2016, I presented a talk entitled “The Art of Questioning to improve Testing, Agile, and Automating”
With only 25 minutes to present, I had to make very sure I was conscious of the main points I was trying to drive home. This was always going to be a topic overview, but I wanted some very obvious and actionable insights for attendees. And hopefully spur them on to future research.
We don’t have to build full applications to create test tools. Sometimes we write throwaway tests.