TesterHQ - The Evil Tester Blog Aggregator

Sep 21, 2016 - 4 minute read - Evil Tester Technical Testing

How to write a simple random test data sentence generator

TLDR; I wrote a random test data generator, not a slogan generator On the Importance of Test Data We all know that test data is really really important. If you don’t have the right data, you can’t test the functionality. You can’t check that an email is sent out on the customer’s 65th Birthday unless you have a customer who has a date of birth that will trigger that functionality.

Sep 19, 2016 - 4 minute read - Evil Tester Technical Testing

Difference between hacking, cheating and automating?

TLDR; Hack for information. Cheating breaks the rules and introduces more risk. Automate the interfaces with less risk. Previously on “Evil Tester goes Hacking JavaScript Games” I demonstrated a ‘bot’ that could play ZType My bot cheated and automated shooting, I hacked The bot has been through a few iterations: 0 - every few seconds it uses an electro magnetic pulse and then gives itself a new emp, therefore having infinite emp devices 1- every 100 milliseconds it iterates through the letters available and shoots that letter watch bot 1 beat a human 2- fixes a bug in (1) so that it only shoots letters which are used on the level 3- once it knows what word is currently being shot at, it uses the letters in that word, but when it doesn’t know the word it shoots all the letters on the level 4 - only shoots letters on screen, every 10 milliseconds, either the start of a word then continues on the word 5 - only shoots letters on screen, which are the start of a word, then focusses on that word to shoot it to bits (doesn’t wait 10 milliseconds to finish the word) - 100% efficiency 6 - essentially bot 5, but only waits 2 milliseconds watch bot 6 in action The different versions represent ‘cheating’ or ‘automating’.

Sep 16, 2016 - 4 minute read - Evil Tester Technical Testing

Lessons learned from Automating - Instantiated

TLDR; take small steps when automating, keep your code working at all times, automate at an appropriate interface Working on a ZType bot reinforced a few lessons learned from automating that are important enough to draw attention to (again). Your Code can gradually iterate to improve You are allowed to stop improving the code Start simple to add immediate value Debug in small chunks Readable code is understandable Automate at the appropriate interface Your Code can gradually iterate to improve The bot has been through a few iterations:

Sep 14, 2016 - 6 minute read - Evil Tester Technical Testing

Hacking JavaScript Games to improve your testing

TLDR; Learning to hack JavaScript will develop the skill of automating using the browser dev tools console. For the last 6 months or so, I have, on and off, been learning to code JavaScript. That process has mainly involved: writing some simple games hacking other games to see how they were written I’m going back to the good old days when we could ‘break’ the ZX Spectrum game and view the source, or disassemble the games on the Atari ST and hook/hack them through debuggers and monitors.

Sep 14, 2016 - 5 minute read - Evil Tester Technical Testing

Is there a difference between "Responsive Web Testing" and "Cross Browser Testing"?

TLDR; Testing responsive web does not mean test it on lots of devices and browsers. Look at the risk associated with your technical implementation and test those. You might still have to use lots of devices and browsers. When you test your web application, do you differentiate between “Responsive Web Testing” and “Cross Browser Testing”? What is Responsive Web Design? I think people still argue about “Responsive Web Design”.

Sep 13, 2016 - 3 minute read - Linkedin

Stop finding simple bugs. Use Automated Validation tools early.

I recently realised that I wasn’t taking advantage of as many automated validation tools as I could do. Hopefully after reading this post you will question whether your process uses enough automated validation. The process of “Testing” provides one way of reducing risk on our projects. “There is a risk that we have bugs in the software” Therefore, we test the software to identify problems, which we then fix, to reduce the risk that the user will find the bugs in the software.

Sep 13, 2016 - 6 minute read - Evil Tester Techniques

Introducing Pious Sanctimonious Standard Compliance Boy

TLDR; Browsers Lie To Us What is worse - a sanctimonious ex-somethingorotherer or a zealous recent convert? I guess it doesn’t really matter, I didn’t choose one role above t’other. After my HTML Validation experience I adopted the persona of “Pious Sanctimonious Boy” and went to work. I ignored my WordPress and Blogger blogs for the moment because I have plausible deniability ready in the form of: “blame WordPress” “blame Blogger” But on my main consultancy site: CompendiumDev.

Sep 9, 2016 - 2 minute read - Evil Tester Tools

Batch validation of HTML as part of your web testing with Total Validator

TLDR; Total Validator Pro will spider a site and check its HTML as well as links. Free version works 1 page at a time. 30 GBP for the pro version. I started using Total Validator Pro as well as the w3 validator (the API which powers the ‘validate’ function in Charles). I wanted to add a ‘batch’ checking into my HTML validation process. And Total Validator Pro seemed pretty simple, cheap and cross platform, so I tried it out.

Sep 8, 2016 - 3 minute read - Evil Tester Tools

How to add HTML validation into your test process without even trying

TLDR; Charles proxy can use validator.w3.org and report results in the proxy GUI After looking at my default test process for web and realising it didn’t include HTML validation by default, I decided to find the easiest way I could to add it in to my process. I generally find that the easier I can slot something into my process, the more likely I am to use it. We all use Dev Tools by default now Dev tools are bundled with every browser now, so we all use them.

Sep 8, 2016 - 11 minute read - Evil Tester Technical Testing

What could possibly go wrong? And what to do about it?

TLDR; We test based on risk. If we don’t identify risk we don’t test for it. Automated tools can reveal risk that our technical knowledge can not. True story: A timeline of a true story of software development: 15:00 I get an idea for an ‘app’ so start making notes 15:30 decide it will be faster if I just start coding it 17:30 basic version of “The Evil Tester Sloganizer” done it is unstyled, but generates slogans 21:30 add some styling and a ‘tweet this’ slogan button, and a hacked up navigation bar 10:30 what the heck, I’ll just release it 10:45 what the heck, I’ll just announce it as beta, because then it doesn’t really matter if it works, right?