In this month’s episode we talk about Behaviour Driven Development (BDD), a testing practice where system behaviours are captured in a human readable Domain Specific Language (DSL), which are automated and executed.
For businesses that are transforming their development practices, testing, as ever is either overlooked, or the last thing to get a makeover. So how do you go about providing real value with changes to your testing practices.
"Lets hand it over to QA”. This phrase is seen and heard a lot, more so when chucking stuff over the development waterfall edge but even now, this is an oft used term as a synonym for testing.
Terminology, naming, what we call something or someone can have a powerful impact on how something is viewed.
Even worse when terminology becomes interchangeable, even though what each represents is actually something very different.
Automation of user interactions in browsers can be difficult. Even more so when you have to hunt for elements in a single page application. How can we ensure reliable location of these and reduce flaky checking?
Testers by themselves can't find all the bugs. Nor identify all the problems. So how do you get non-testers to look critically at the software and organise them to be effective at it. At least for day. This post explores the bug hunt. Asking the questions, giving some tips.
How we develop software has changed dramatically, more so in the last 8 years since smartphones came to prominence. How software is tested, arguably hasn’t. Or has changed so much, that some don’t see the need for testers at all.
When Malcolm Gladwell wrote a book called Blink about the power of the subconscious in 2005, a heuristic was named for it. Read on for how blink testing works, and some further thoughts on how other ideas the book contained can influence your testing.