I had an interesting opportunity to play around with something useful today ...
We're currently doing a couple of sprints to change some look and feel to enhance our web page for mobile. It's been a weird mix of interesting, and boring so far, and I want to share an approach I've taken.
Because our goal for our sprint is to tidy up the mobile experience, which involves a huge amount of changes, I'm being for once somewhat overwhelmed by builds being dropped into my test environment.
I came up with a checklist of things to cover which includes,
confirm all key fields are present
confirm error text when mandatory fields missing
confirm error text when junk input given for fields
confirm error text when duplicate entries (re-enter your password etc) don't match
do all this on multiple browsers
do all this for mobile and desktop settings
At the end of day one, we'd had 3 builds delivered. I'd been really dutiful and methodical for the first build. But by human nature my concentration was going on the huge checklist.
My concern was by end of sprint I might be getting a bit blase about it all. Ironically it's the end of sprint the find details of the checklist matter the most.
The problem is our automation checks we can perform business flows, it doesn't check the fine details of what's on the page. But that was kind of what I needed.
So I wrote my own using WebDriver, but here's the thing, it'd replicate all the above checks, but I acknowledged this was only to help us through the next few sprints whilst we put it through some UI changes. Afterwards it would be just deleted and never used again, because it didn't make sense as ongoing regression.
It'd do all the checklist "ticks" for me, but leave the browser in a state for me to run my eye over for anything out of place, and allow me to do a little bit of playing.
Cool features it had would be,
Using multiple drivers for different browsers, so it'd check across browsers for me (mobile-proper would still be manual, but hey, it's freeing my time)
I would use the Selenium setSize command to mimic either mobile or desktop settings in my tests
I time-boxed myself to no more than 2 hours on this - I delivered what I wanted in 1.5 hours. As usual I had a lot of ideas for enhancements, but reminded myself that would take me away from testing (which I was trying to save time on in the first place), and ultimately these pages being checked for content in this depth were not the kind of critical tests we'd need within our suite.
As expected, we had another 4 releases today, and it allowed me to keep better pace with them, whilst focusing my time on key changes for each task as delivered.
It was a good example of how you can knowingly break a lot of key rules of automation (I for instance use methods, but not the kind I break down to use on more detailed functional testing). And yet keep to the fundamental one - let automation deal with anything which looks like an item to check, and leave more freedom to explore to the manual tester.
I've been thinking a lot in this vein the last week, and really wanted to commit these thoughts down electronically.
I've spoken in the past about quite a traumatic event in my early 20s where I saw someone killed. As you can imagine, it wasn't very nice, and there was a whole personal journey dealing with the post-traumatic stress of that.
The last few years however, I was very aware of something that lingered from that experience. What is so troubling about an incident like that where you have flashbacks, is the sense of only witnessing, and being powerless. It's had a knock on effect on my whole life where I always try and do something over nothing, because then I felt a sign of ownership in whatever outcome occured.
This is me on waterfall
In waterfall, that means I was a really proactive, guard-dog of testing and all aspects of quality (this really isn't the blog to have the argument about quality though guys). Playing the superhero role whenever I could, I was always trying to be that guy who makes things happen, that guy who fixes it all.
In our agile transition at work, I've had some really great mentors. First of all, don't get ideas that out of waterfall I don't care. But I've learned to focus much more on those items which are expected of me, and doing the best I can about them, and learning to escalate up any problem which falls outside of that. And to do that in such a way that it doesn't feel like I'm "telling tales" on other people - to escalate in a supportive way, but acknowledging I'm not always the right person to solve all the project's problems.
Sometimes to fix something properly, good intentions aren't enough, and you need the appropriate expertise, and I've learned to set aside my male pride and accept it's not always me. [You should see my attempts at plumbing before I realised this]
But most of all, I've learned with fortnightly sprints, I don't have to be the attack terrier trying to keep everything on track. We can and should be daring and try new things, even challenge "sacred" taboos every so often - the worst that could happen is we mess up a sprint, all of 2 weeks lost. But just maybe we might also find a better way to do something which will help sprint-after-sprint. Or learn a good reason for why we always should do X that no training course could have got across.
Far from not caring, it's allowed me to focus my energy so much more on areas I'm relied on much more, and actually enjoy what I'm doing. But it's allowed me to accept that letting things play out isn't always a fraught case of life-and-death. And to me, that's something more important than you can imagine.
You're still with me? Great. Buckle up, because time is only going to get wierder.
Thank your uncle Albert for that...
Albert Einstein is of course famous for a couple of theories of Relativity which describe interactions between energy and matter, and particularly discuss how time changes with speed. It also imposed a speed limit on the Universe.
And I mean an absolute speed limit. Not like where we have a 55mph road, and you do 56mph and feel all ...
You can't go faster than the speed of light. You don't get to play Spinal Tap, and do the speed of light ... plus 1.
And as my reader Ben pointed out, there's certainly no going .5 past the speed of light. Also a parsec is a unit of measurement not time. Your dad's been lying this whole time kid.
Let's try a thought experiment
Okay - we have the scenario below,
Star Destroyer - slow enough to be considered stationary
Millennium Falcon - moving away from the Star Destroyer at half the speed of light. It is also firing it's forward laser cannons, the energy for which moves at the speed of light.
Let's look at it from the point of view of a couple of observers.
Darth Vader is on the Star Destroyer, and he can see the Millennium Falcon moving away at half the speed of light. He can also see the laser beams which also are moving away from him at the speed of light.
The lasers go no faster for leaving an object which is already at half the speed of light. You would think this would be a good case for .5 past the speed of light. But no, the speed limit still applies for any observer.
Chewbacca is flying the Millennium Falcon. I guess you can say he's flying it Hans-free. Surely he sees the laser beams travelling slower?
No - he sees the laser also travelling away from him at the speed of light. How can it be that two people at vastly different speeds are seeing those lasers travel at the same speed relative to their speed of motion?
The answer is they're observing time very much more differently. For Chewbacca, time is going much slower than for Darth Vader. That different is enough for the light to look like it's moving at the speed of light from his slowed-time framework. This is called time dilation.
It's just a fancy theory isn't it?
All this of course sounds like a fanciful theory, with a bit of mathematical jiggery-pokery to make it work on paper. Except science doesn't work like that (you're thinking of religion).
All my critical thinking senses are dubious. As I've said to my office quite regularly, I'm a tester, I don't tend to overthink things when I can come up with an experiment to prove or disprove something.
Once Einstein had written his theory, it was up to physicists to look for proof ... and they found it!
Muon
We obviously don't have spacecraft capable of travelling quite so fast as the Millennium Falcon - but we have the next best thing ... the mighty muon.
Muons are an exotic subatomic particle. It is pretty much a heavy electron - it has the same charge, half the spin, but 300 times the weight.
They're also highly unstable, with a mean life of 2.2 microseconds - that's 0.0000022 seconds - observed in the lab. It decomposes into an electron and a couple of neutrinos.
They're found in nature - when cosmic rays (essentially high energy protons or helium nuclei) from outer space collide with the atmosphere they can create muons. These muons are moving incredibly fast - 95 to 99% the speed of light. But even at those speeds, the best they could travel in our atmosphere is about 600m.
So how are these particles, produced miles above us, able to be detected on the ground? When we do the analysis, and apply relativity, this isn't surprising. Moving at that speed, the particle has experienced much less time - and as we talked in part 1. That means less change has occurred - so these particles reach the ground having yet to decay.
This brings us right back to part one. We can't measure time, but we can measure change, which can give us an indication of time.
You can read more about other observations of time dilation here or can see the maths being explained a bit here. It's not just a theory, we've managed (by thinking about it, and applying a little cunning) to do some neat experiments to observe it.
So what was the point of the "Time"series?
When I saw Jasper Fforde earlier this year, he talked about writing as a mental challenge. To take an idea and work out how far you can explore and push things. Start with something, an idea or definition, and keep pushing.
After seeing definitions like this ...
I wondered if I could take something that I knew, try to define it, explore the definition, try new things as I learned.
This thirst to think and play with ideas - I'm not sure if it's exclusively a critical thinking thing. It's definitely a science thing. But it's something that drives me a lot - why so much of this blog is about playing with ideas to understand them better.
This blog series was actually originally written several months ago - and part of the reason I've thought very hard about trying covering more science in my spin-off I've talked about here.
Now Playing - "To Love Somebody", the amazing Nina Simone
Okay - so previously we took a little look at time and defining it. I put forward that this was the best I could come up with ...
Mike Talks' Definition Of Time
Time - a phenomenon which allows change to occur.
That is to say, without time, a system will remain in stasis.
Today I want to explore some meaning to that definition.
Measuring time?
Well as I mentioned previously, we can't measure time, but we can measure change. It seems fair to say that the more change you're observing, the more time has elapsed.
If I went to the bottom of my road and counted cars passing me as my "change" to monitor - is seems fair to say I'd expect it to take longer to count 1000 cars passing me than to count 10. But to know for sure I'd need to be able to check it against something I could be certain changes consistently and regularly.
Some of you might say "well just check with a stopwatch" - to which I'd remind you from last time, all the stopwatch is doing is counting oscillations in a quartz crystal. So how can you be sure that's correct?
Synchronizing watches
These days with smartphones which autocorrect the time regularly, we're losing touch with synchronizing our clocks. Even the best watch in the world can be inaccurate and drift a little - typically the more accurate, the more expensive.
But even this requires us to synchronise our device with a reference clock which we believe to be accurate,
When I was young we used to have a series of radio pips on the radio to tell us when the hour was on.
Towns in England would use the chimes of a town/church clock or a time ball to make aware the turning of the hour
The faulty clocks conundrum
Consider this as a challenge - you're given two clocks and told that whilst one is accurate, the other isn't correctly keeping time. How do you work out which of the clocks is faulty?
There isn't actually any way I can see to solve this puzzle - if you leave both clocks running, one will be fast, the other slow. There's no way to tell which is the accurate and which is the faulty one without somehow having a third reference time which you know to be accurate.
It's possible that one is running so incredibly fast/slow that you can tell by watching that "that's not ticking correctly", but you're not really using the second clock. By the way - I typically hate these kinds of puzzles. If someone knew one clock was accurate, why ever the hell didn't they label it as such?
How do you actually test a clock?
Actually this has made me want to look a lot into "'how did people test the accuracy of clocks"?
This took me to the story of 18th Century inventor John Harrison, who tried to create an accurate naval clock or chronometer for measuring longitude. Typically a large clock of his period is designed to be accurate, but completely stationary. Smaller pocket watches existed, but it wasn't unusual for them to lose as much as fifteen minutes in a single day.
The challenge in a chronometer was to create a device which could move on the rolling, salt heavy, humid conditions of the sea, but retain accuracy of a large stationary clock.
If on a long sea voyage you knew London time, and you measured the time of midday, when the sun's shadow is smallest and points due north (in the Northern Hemisphere anyway), then for every hours difference from midday London, you were 15 degrees of longitude from London. Read here for more detail.
Through experimentation, he turned a lot of ideas on clocks on their heads. Many believed clock accuracy was down to using slow moving, heavy pendulums, where John Harrison found smaller, faster moving parts worked better - indeed a longitude watch could keep better time than a clock, as was proved by his experiments. [His chronometer was noticeably different from normal clocks/watches from it's rapid tick-tick-tick]
John Harrison typically spent over 31 years building and testing a series of devices. One such test involved sending the H4 watch overseas to Jamaica with his son, where it was found to only lose a few seconds over the 6 week voyage.
What's somewhat frustrating looking through all the information there is on John Harrison - there's a lot documented on every revolutionary feature he incorporated into his device, and how they were made. But only a few clues as to how they were tested - this was annoying because (a) I'm a tester and (b) the devices can only be as good as the tests used to measure them.
I had a go at trying to reverse engineer how this might have been tested, and came up with the following possibilities,
Checking noontime
Checking vs accurate land clock
Checking vs night sky
Checking noontime
One obvious method for checking a chronometer would be to synchronise the device to twelve noon using a sundial to measure when a shadow is smallest / Due North.
You wait for noon the next day, and see if it's showing 12 o'clock. The problem with this is it's quite a shallow test - and noon isn't something you can measure "to the second".
You can probably increase the confidence in this by running it daily over months, to see how much it shifts. This is probably why Harrison spent 31 years testing! Fundamentally with this, you're using one source of change (the hands on your watch under test), and testing it against another source (the time it takes the Earth to rotate), looking for correlation.
Checking vs accurate clock
This helps to give you a gauge, but as said above, how can you tell which of the clocks were "most accurate". That said, such clocks run night and day, and someone would notice if the clock was striking noon when the sun was just rising in the morning. Like the method above, this is another form of correlation testing. Finding longitude of a known location
There are some records that show John Harrison's son used the H4 watch in Jamaica to predict the longitudinal position, and found after the sea voyage it was correct within a few seconds. However of course - if the 18th Century lacked any means to accurately get the position of Jamaica (the whole point of the chronometer), how do you know the H4 wasn't measuring it more accurately than had previously been possible?
I suspected that Jamaica's latitude and longitude might have been calculate using the night sky - but again, there's a frustrating lack of information just on the internet about this.
But which was it?
Don't you hate not knowing? Thankfully James Bach recommended a book Longitude by Dava Sobel which solved this in.
It seems they'd found an accurate way on land to test time by observing the motion of the moons of Jupiter. This was originally put forward by Galileo, but the astronomer Cassini perfected this with a series of tables (little did they know, there was an error in the system that Cassini corrected for, which turned out to be due to the speed of light difference due to different relative ranges between the Earth and Jupiter).
But this method of taking time could only be done by a trained mathematician/astronomer on solid land. Hence knowing Jamaica's position relatively accurately. Obviously only a few people had the skills to do this calculation, and it was completely unsuitable for use on the rolling sea.
I noticed that in 2015, a replica of the H4 was "tested"and found to keep time accurately. You can read about it here.
Please notice my use of quotation marks there. The replica was "tested" at the Greenwich observatory in a stationary location. Part of the requirements of the chronometer for Harrison was that it to keep accurate time, whilst at sea. So this isn't really an adequate test in my opinion. [I'd have wanted to add in some rocking motion to the test]
Do you disagree? Then comment below ...
Now playing: "Make Me Smile", Steve Harley & Cockney Rebel
Welcome! This post is going to be a little philosophical, and challenge you a bit in reading. The whole intent is to get you to just think a little bigger, and about something you know all about, but maybe it's too under your nose that you've never really thought about. Half of critical thinking is thinking about something for which we ordinarily have an automatic response for ...
On Twitter I've been having discussions with a lot of other testers about how do you define things. In many ways how we define things essentially shapes how we think about them. An example of a bad kind of definition is one where you use the word you're trying to define within the defintion, an example came from an ISTQB slide "security testing: testing the security of a system".
GOOD NEWS - I'm not going to ask you to define testing. Phew.
Instead - take some time to think about how you would explain time to me. Surely much simpler huh? You constantly use it. So describe it to me ... you can use the comment below if you'd like.
Okay? How did we go? It's actually pretty hard isn't it.
If your answer was something like "time is - hours, minutes, days, months, years?" or "as seen on a clock" - it's the start of a good answer, but a bit shallow. Time is something we use a lot, we have a vague idea of it's rules, but describing it is really difficult.
Time is the indefinite continued progression of existence and events that occur in apparently irreversible succession from the past through the present to the future. Time is a component quantity of various measurements used to sequence events, to compare the duration of events or the intervals between them, and to quantify rates of change of quantities in material reality or in the conscious experience. Time is often referred to as the fourth dimension, along with the three spatial dimensions.
the indefinite continued progress of existence and events in the past, present, and future regarded as a whole.
Webbsters dictionary has (simple) the thing that is measured as seconds, minutes, hours, days, years, etc.
(complex) the measured or measurable period during which an action, process, or condition exists or continues
Some of those definitions help, some are probably right if you think about them. As a physicist, I of course have a fascination with time, and so I've spent a few years thinking about it and how we use it.
My definition is fairly simple, elegant but it has consequences ...
Mike Talks' Definition Of Time
Time - a phenomenon which allows change to occur.
That is to say, without time, a system will remain in stasis.
It's pretty neat, and in many ways close to Webster's complex answer. But as I said, there's consequences.
One of which for certain is that time is not directly measurable. The other is that time may not actually exist ... certainly not as we think of it.
Okay - that's a big ask - so do check the date on this post, and confirm it's not April 1st. I do have past form in trickery ... it isn't, and I'm serious.
By now, I'm hoping you're thinking about scrolling down to the bottom of the page, and typing something angrily into the comments. Maybe something like "but I can measure time on my watch ...".
Thanks for bringing that up ... if you have a digital watch, then it's powered by a quartz crystal. When this crystal is put under an electric charge - many would say that it vibrates 32,768 times a second.
And I'd have a problem with that. Because we're not measuring and counting time - we're measuring and counting change. In actual fact, when you measure 32,768 oscillations in a quartz crystal, you're at that point making a mark to say "I think one second has passed". Let's revisit that shallow answer again ...
Remember we said a shallow answer to the question would be that "time is - hours, minutes, days, months, years?".
What is a day? It's the length of time between consecutive midday (when the Sun casts the smallest shadow). Or how long it takes for the Earth to rotate once.
What is a month? Well, a lunar month is the time it takes between the Moon's relative phases. Or how long it takes to orbit the Earth once.
What is a year? The time it takes the Earth to orbit the Sun once.
Are you noticing that each of these is measuring a change, and giving the period a value which for you is a measure of the time that's? Or in other words "this unit of time is when this much change has occurred". Notice a pattern here?
Let's look at another consequence ...
If nothing is changing - time cannot be said to be occurring
If a system is in complete stasis, then you're not able to say that time is occurring. This of course probably seems absurd to you. You probably would say "I know it's passing", and apply logic by looking at something outside of the system to prove it - that "thing" outside of our system under observation is of course undergoing change (hands on the clock mayhap?).
Let's consider a hypothetical universe ... it's approximately the year one googolplex, and the Universe has ground to a halt. It stopped expanding an untold time ago - the last star burned out billions of years before that. The Universe is in a constant temperature of absolute zero, no planets orbit stars anymore, no galaxy moves. There is no chemical reaction remaining, and even electrons inside atoms are stationary. The Universe is exhausted of all energy, and remains unmoving. How would you be able to tell that any time at all way passing?
You couldn't. You'd have to introduce something to this universe/system like a watch, where change occurs. But by itself, there seems to be no time passing, as there seems to be no change happening.
It's impossible to tell here if time exists or not. Certainly without something to change, time becomes completely irrelevant.
[You might notice a certain familiarity here with the idea of the heat death of the Universe ... also it was used in the Doctor Who story Utopia]
That's quite enough today - next time we're going to play a bit more with this definition, and think about how we can test even more. Now playing: "The Logical Song", Supertramp
Okay - so last time I wrote about an obsession with numbers in testing.
Pretty tough talk Mike ... but in reality? Normally due to confidentiality I can't share the reports that I normally produce. However recently we did at Datacom the Oceania Software Testing World Cup.
It was a really great experience, as it allowed several of us testers who don't normally work together to be in a team and learn how different parts of the company test.
We had 3 hours to put an application through it's paces, record defects, and produce an end report on it.
Below is a copy of the report we produced (I've checked the rules, and it doesn't say we can't share this). You'll notice we link to the results in our defect management system, but I don't produce a list of them all, or even count them.
Instead I try and weave a story of what the main drivers of the project are, the testing that we've covered, and the major issues we found. You'll notice as well that I use those issues to give the advice that I feel that,
It could be used as is to demonstrate the look and feel
It really needs some more connected features to actually be useful and usable. A major driver from the customer.
Our team name was Quest Aotearoa [QA]. Aotearoa is the Maori word for New Zealand.
Team Quest Aotearoa - Roadmap Test Report
Quest Aotearoa has undertaken to do initial testing of the roadmap application on Android and iPhone.
Business travel is a fraught affair of being lost, trying to manage your appointments, flights, hotels. Roadmap is designed to be a connected application which allows you to manage and monitor all of this from a single location. This is the competitive advantage of this application.
Testing has been undertaken on September 8th in Wellington from 7pm to 10pm local time. Our test machines are,
LG G3 Android 5.0
Samsung Galaxy Note 3 Android 4.4
Samsung A4 Android 4.4
iPhone iOS 9.1
During this time, Wellington has undergone some severe weather warnings, which has caused disruptions to local flights – something we have used to test.
Testing Scope
As a team we have explored the functionality of the application. This has included,
Registration on a number of emails
Transfering the same registration to different devices
Logging out of the system, then returning to the application
Contacting service desk
Using tutorials
Using meeting calendar
Adding flights – both short term and in distant future, together with in the past
Add hotels – including obscure locations, in the past, leaving before arriving etc
Mixed items on the timeline, to confirm ordering is as expected
Removing items from the timeline
Exploring our location using maps
Giving feedback
Using the application after shutdown
Retrieve your details whilst the phone is in airplane mode
Overview of the application
Issues we have found can be seen under our Lean Testing account. [This was our bug tracker]
The application as a demonstrator of the aesthetics works really well, and gives users a good idea of how the final product will work.
The display to the user is generally uncluttered, with colour coded systems making it clear the difference between hotels, flights etc. The application looks consistent across iPhone and numerous Android devices.
However, even as a beta version of software, this application is not yet ready for release. Mainly because it fails in a number of key ways to deliver reliably on the competitive advantage promised.
Key examples of this include,
Registrations on Hotmail accounts took 40 minutes to get to the user. For many new apps, you have about a 5 minute window to impress users before they typically uninstall and move on
The application lacks key connectivity – for instance you cannot import items from a pre-existing calendar, send a location to Uber, find a local taxi firm etc. As mentioned we had a severe weather warning, and received warnings from other apps, but not from roadmap
Local flight NZ463 was looked up on Wellington Airport, and was clearly seen to be late (on the airport site), but the app didn’t tell us this. This was a very clear failure to deliver one of the key claims of the application
Roadmap collects together a lot of very sensitive information into one location. However even when we signed out, we didn’t require a login to get back into that information.
We had occasional crashes – which are detailed best in Lean Testing
It is our recommendation that this application could be used for basic demonstrations to show the look and feel, but right now need the features discussed addressed before we have a functional MVP which reliably delivers on it’s promises.
Now playing: Robin Schulz, Sugar
By the way, I thoroughly recommend the Software World Cup. It's such a great opportunity to reconnect with why you love being a tester.
If someone follows me on Twitter, I always try and check their profile out. If their profile says Test or even QA, I think it's worth a gamble following them.
That''s because sometimes they say something, strike up a conversation, and it leads to somewhere interesting. This happened yesterday with a conversation that began with this, and you can follow it more on this thread.
Outside of our field, I've also been talking a lot to a couple of teacher friends who are likewise seeing an obsession with pass rates.
The logic goes something like this - X is an acceptable pass rate. If,
Your pass rate < X. Then this is bad. Very bad. Reject
Your pass rate > X. This is all good. Accept.
I've talked previously about not having had an easy ride through education, often failing a lot. And also a bit about my tutor David Hughes, who I had an at times difficult relationship with.
I'd grown up reading every book on astronomy I could get my hands on, and really focusing on physics from the age of 12. All with the aim of studying at University.
But my experiences in my first year were tough. I went from being the brightest in my school, to being in a group of peers where I was below average.
At the end of the first term, we had a mock exam, and to be blunt, I bombed. Physics and astronomy papers are notoriously tough, with a pass rate of only 40% needed. I was one of the worst of my class in astronomy only getting 19% (the mark was far worse in physics).
To say I was heartbroken and felt stupid is an understatement. I was seriously thinking of dropping out, because I felt that I just wasn't getting it. I felt worse was to come when I was summoned to my tutor David Hughes office to talk about it.
I expected nothing less than humiliation, what happened next surprised me. He had my paper with him ...
"Look, this isn't a great mark. But I can see where you're having problems. The important thing is we can work with this. And you will find it easier."
Knowing what I did understand, and what I didn't, we did work through in tutorials, correcting some mistakes. That failed test formed a map for him to guide me and make improvements. Students who'd done better didn't get that, and didn't need it.
Through David Hughes, testing wasn't about rejecting or accepting a student. It was about finding weaknesses and working on them.
Isn't that the case in software? A test isn't something you simply pass or fail - a test is an activity you take to find out information about your application. But a test is meaningless unless you have a feedback loop to apply what you've learned.
This is to me forms two of the most important questions in testing,
What scenarios would we still like to exercise? If they're important, why haven't we done them yet?
Are there anything we've learned about the system that we really should address?
These aren't questions which revolve around numbers. They revolve around specific answers which we can engage and converse about.
If we're not talking and thinking about the feedback from what we've learned about the product, then we're not moving the product forward. It is not our job to choose what should be fixed though. But we are possibly best placed to give an opinion.
Thanks Thomas Ponnet for his early review of this article.
As I explained last time, the blog is moving towards it's last post later this year. I really want to enjoy these last posts together on what's been an amazing experience. So I'd like to end each post now with a song, as we ride together into the sunset ...
These 100-post milestones are always interesting to me, they allow me to think out where I'd like to go moving forward, and recap from where I've been.
Writing TestSheepNZ has been an absolute blast. I've quickly found that I like to play around a lot with ideas whilst I write. That means occasionally blurring the lines, moving outside of what you'd expect a software testing blog to be.
We've covered aspects of science, psychology, critical thinking, history. I've occasionally had some grief that in doing so I've diluted the "software testing" theme. But here's the thing, we're always approaching this material from a deeply analytical path, and always there are parallels which come right back to our 9-5 in the office.
But more than anything, the blog has put me back in touch with writing, and how much writing can take us anywhere. And that's why I want to occasionally try something new - such as focus on critical thinking, or write a piece about Jutland or the Somme, because I want to see where it will take me. Where it will take us. And it always seems a journey worth taking.
Because when you're doing it right - learning and exploring are their own reward. That's a very Feynman world view.
One problem being so prolific a writer of testing blogs though, it's almost like a weed - it somewhat strangles all the other writing I'm trying. And so a couple of months ago, I made a tricky decision to put a line under my writing on this blog by the end of the year.
Blame Feynman. Seriously - he took a year's sabbatical to go study something that wasn't physics, to go bring what he learned back to physics.
I'm planning to start writing an astronomy blog towards the end of the year - using a similar mix of fun. But to make that happen, I need to stop writing about testing - for a while at least. I've tried to get the other blog off the ground for a while, before realising the basics of agile - you can't multitask. So I need to seriously wind down my test writing to have the bandwidth for this new project.
If you're a fan, you'll always have the new blog (hey, subscribe when it's ready, and learn something new). We also have a few posts to go together yet, including finishing up the automation series.
Plus I've also applied to be a content creator at Ministry Of Test, so there might be occasional material there.
I hope you're as exciting about this as I am, because I'm really looking forward to trying something new. It's an adventure! This is the end. Beautiful friend. The end.
I've been recently returning to do some responsive design testing. I wrote previously about it here.
I get a decent variety of challenges at my work, so I'm almost amazed to be revisiting this after an absence (I've been looking at NFRs) to see there are some really useful tools out there.
Developer tools ... mobile mode
This one just blew me away! What happened next ... okay I'll tone down the clickbait.
But newer versions of browser, if you go into dev tools (F12 on Chrome) have a responsive design option, which allows you to simulate screen sizes, even flipping your screen from landscape to portairt and back.
Mind ... blown ....
You're looking for the following button,
Here,
I can rotate with this ...
You can select from a list of settings for different popular devices ...
This is a really great tool for helping initial testing. But as with my previous article, be aware that you're not using the proper device browser, and items like drop downs and pop-ups are handled radically different on mobile devices.
Vysor
This is a Google Chrome app.
Because I'm doing more with mobiles, I need to be able to demo more on mobiles. Our work has a lot of projects with VGA, and when I asked if it was possible to get a new state-of-the-art projector to run our demos on from the phone, I'm afraid I kind of got this look from my managers ...
This only works for Android phones, for which you need to also download the Vysor app from the Play Store. You'll also have to put your phone into developer mode - you'll have to Google how to do that for your device - usually you hit an option 7 times in the settings, which unlocks developer settings like an Easter egg bonus.
More than just showing the contents of your mobile device, you can also manipulate it using the mouse and keyboard. I like this because when I'm doing a lot of repetitive tasks, it's all a bit easier, plus I can screenshot to my heart's delight. Good times!
Well - I thought we were done! The funny thing about learning, you never really are done.
Today before leaving, I have a conversation with one of our new developers who's learning Java about passing values to methods.
We covered this back a way ago here, where we passed primitive data types, and could see if we changed the value in the method, it didn't affect the value passed, because primitives are passed by value. You can find the exact code on Github here.
My developer, David, was looking at this item on StackOverflow (it's a great source of information and worked-through problems, which always comes up in any Google search).
That example given seemed to be saying that if you pass an object, rather than just a primitive data type (integer, String etc), then you are passing the object by reference. This means that any changes you make the to item you've been passed get made to the original object itself - you are NOT creating a copy as with primitive variables.
Even our more experienced developer was sure this was wrong. I managed to talk them into looking at it from my perspective, in the only way that really matters - let's build it and find out!
We have the following simple dogClass to keep methods,
And the following variations of methods,
For these methods,
changeNameByString changes the value of a String that is passed to it
changeNameUsingMethod calls a method within the class to change the name
changeNameUsingAttribute changes the attribute itself, which I've naughtily left public (hey, it's an educational test, it's allowed for curiosity)
getNewDog assigns a newly declared dogClass to the object passed
returnNewDog returns a newly declared dogClass
Here's my test ...
And here's the result ...
So basically, if you pass an object to a method, and manipulate it, the changes will happen to the original [changeNameUsingMethod & changeNameUsingAttribute ]
If you use the method to create a new object [getNewDog], that object will be lost, unless you return it, and assign the new object to the old one [returnNewDog].
If you pass an attribute for the method, then change it, those changes are lost when you leave the method - basically a copy is made [changeNameByString].
This was a really fun piece of learning for all of us. It also highlights my testing approach to development - which is "find a way to test and check what happens - come up with variations, and see what happens". Don't be so sure that something can't possibly happen - find evidence to prove or disprove.
If you're shocked with the result, then you've found an area to learn more about. Target some study there.
So that's it! We've gone through a lot of theory and examples together.
Next steps? Well maybe Alan Richardson's book on Java For Testers is a good start if you've not picked it up already. But above all else, get coding, get practicing, get learning.
The following are a set of ideas for you to try out as revision for what we've covered so far. Try not to go back to my code, but do use the internet to look up functions - most programmers do!
Revision exercises
Create a HelloWorld program
Create a HelloWorld program, where "Hello World"is declared as a string printMe, and passed to be printed.
Create a HelloWorld program. Declare "Hello"as string Str1, and "World" as string Str2. How do you put them together into string printMe to be published?
Create a method printHelloWorld, which does just that.
Use a loop to call printHelloWorld 10 times.
Create a functon called printGutenTag, which prints "Guten Tag". Create a loop which prints "Hello World" on odd numbers, and "Guten Tag" on even numbers, using if statements.
Create a class called Card which has two attributes "suite" and "value". Create a method for setting these values, and for getting the value of the card.
Create a class called CardDeck, which contains 52 cards. Create a method to draw a card at random.
Look up Conways Game Of Life. Create a class for a cell, and a series of JUnit tests for it.
Look at our recent examples of Game Of Life, Character Creation or Account User. Add some more JUnit tests which include assertions.
[REQ_1] Add a combat system onto our Character Creation. Characters must first hit with their weapon, then wound.
[REQ_2] To hit - characters must roll equal or under their fighting attribute if doing hand-to-hand or shooting if done with a ranged attack. This roll is done on a D20 (20 sided dice, with 20 always high).
[REQ_3] If the character has the skill martial arts for hand-to-hand or archery for ranged attacks, they get to reroll a failed miss if it occurs (but the next result stands as is).
[REQ_4] If they roll a 1 to hit, it's an automatic wound (skip the to wound roll)
[REQ_5] To wound - if the character rolls equal or under their strength, they cause the loss of 1 health from their opponent.
[REQ_6] If they roll a 1, then they cause the loss of D6 health in a critical hit.
Add code to support the above, including any JUnit tests needed.
[REQ_7] It's been decided, users will now user have their username created for them. Use the method from unique username to create their username automatically on creation.
[REQ_8] Sometimes there's just too many audits to read through. Create a method to print out only audits which contain a certain action/phrase and test it.
Add code to support the above, including any JUnit tests needed.
Just a disclaimer, the code I've produced here forms a working model of a customer account class to work with. This is not intended to be a demonstrator of good design for a customer account management system, just a working model we can play around with.
In this last worked out example, we're going to create code for a customer account management system.
Our requirements
[REQ_1] Users can register their account by providing us their username, an initial password, and their date of birth.
[REQ_2] Throughout their lifetime with us, customers or people with admin privileges can add or change the following details to a customer account,
Full name
Mailing address
Email
Phone number
[REQ_3] Only the account owner is able to change their password.
[REQ_4] The username and date of birth are fixed at account creation, and cannot be amended. In the rare case where someone has forgotten their own birthday, we'll get the value changed in the database.
[REQ_5] Both the account owner and admins are able to view account details.
[REQ_6] The account will be fully audited, including every time change of data, every time it's viewed, every time access is denied.
[REQ_7] Details of passwords will not be displayed, either within account details or in account view.
[REQ_8] The account view will also list all audit events.
The solution
I'm not going to go into the same level of detail I have with previous projects. The code can be found here on Github.
Probably the key thing to look at here is the AuditEvent class.
We have a whole List of these audit objects within our customer CustomerAccountClass.
We add a new AuditEvent for everything we do.
I have a pretty obvious method to check permissions when needed - it's assumed that the method receives the username of the person trying to perform the change.
I mentioned this in the comment in the constructor, but I added a List of admin staff usernames, who have permission to make changes. The way I did that was a bit of a hack, but hey, I don't want to build a whole system for my demo here.
So when you run, this is a taste of what you get - quite neat!
Extension material
Create admin class
The adminStaff List included within the customer account class is ugly. Create a class which contains a list of admin staff, and returns whether someone is authorised to make changes or not.
This will separate out between customer data & methods and admin data & methods, and so be considerably tidier.
Don't forget to declare this admin staff within your @Test methods.
Date of birth
I currently handle date of birth as a String, which was just for quick convenience. Replace it with a date format, you will have to Google to find what types you can find in Java.
The following example is a class which allows you to create a role playing (RPG) character. Below are the rules ...
Character attributes and skills
Character are given a name on creation, they are also set the following attributes,
Fighting - how good they are at close combat
Shooting - how good they are at ranged combat
Strength - how hard they can hit/pull back a bow
Health - their maximum health
In addition, they can have a list of skills or advantages that they've gained.
Character Level And Experience
All characters start at level 1, and as they go through they gain experience (XP).
Characters can spend 1000 XP to "level up" where they can either,
Increase an attribute by 1, to a maximum of 18.
Add a skill/advantage
This will increase their level by 1. Taking damage/recovery
Characters have a status called current health. This can only ever be the maximum of their health attribute. However if they take damage, it will decrease.
If it falls to 0, they die. However characters with the "cheat death" skill can fake their death, they have a 50% chance of being only mostly dead, and merely pining for the ffordes. In which case they retain their last health point.
Characters can regenerate, gaining 2 x D6 current health back. But this costs 100XP. So don't spent it all, keep some in reserve.
Not surprisingly, this is our most complex piece of code yet ... Attributes
Constructor
Not surprisingly, the constructor sets much of the attributes. After creation, fighting/shooting/strength/health can only be changed through experience.
Print character sheet
It's useful to be able to see all the attributes ...
Add experience
Pretty simple - this adds experience to the character's pool.
Level up
Probably our most complex method to date - first of all it makes sure you have the 1000 experience to do this.
Then, if you've selected "Fighting", "Shooting", "Strength" or "Health", and these values are below 18, then they're increased. In the case of health, your current health is also increased.
If you provide something other than these keywords, it assumes you are adding a skill, so adds to the list of skills.
You then have 1000 experience deducted, and your level increased by 1.
Add skill method is defined here ...
Wounds/healing/regeneration
Finally we have taking a wound, healing and regeneration, which are all here. By now you should be getting good at reading this ...
The Disney Avenger Initiative
The world of the Disney comics is under threat from a whole lot of extraterrestrial threat - yeah, worse than this guy ...
So, agent Cobra Bubbles is calling in his own Avengers Initiative, and recruiting people with extra-ordinary abilities to be Planet Earth's first line of defense!
I'm going to use @Test methods to simulate some familiar Disney heroes for this RPG.
Mulan
Thanks to her extensive training, she is a highly skilled warrior,
Her fighting skill increases twice
She is proficient at cross-dressing
She has the martial arts skill
She is resilient, not taking defeat easily
She is a natural leader
Merida
A deadly shot with a bow, to put Robin Hood to shame ...
Tinkerbell
One of the lowest characters in terms of health, however her high strength reflects the increased damage from her magic.
She also has access to a magic wand and can fly. Don't make her think unhappy thoughts.
Pocahontas
Give the girl a break, she was involved with Mel Gibson at one point.
Pocahontas excels at tracking, running and understanding foreign languages. She's a pretty mean fighter when she wants to be as well.
Snow White
Because, y'know, kissing a supposedly "dead girl" isn't at all creepy is it? Seriously, didn't your parents bring you up better than this?
No possum on earth can fake death quite like Snow White, she's also able to make animals do her bidding. What kind of superpower is that? I guess you've never seen The Birds then ...
Princess Jasmine
Her strength and health might seem abnormal, but this reflects how her pet tiger Rajah is always by her side protecting her. She's also borrowed Aladdin's flying carpet.
Princess Ariel
Not only can she breath under water, she's really good at swimming. She can also talk to the animals ... well the marine ones anyway. Don't be surprised if her dad's got his very own Kraken - best be on her good side.
Queen Elsa
She has superb powers to control the realm of the ice and snow. From the midnight sun, where the hot springs flow.
As you're probably aware, the cold doesn't bother her anyway.
Well, you might have noticed, I've got so swept up in character creation, that there are a lot more @Test methods especially using assertTrue and assertFalse needed to check some of that behaviour.
You're right - it needs them. And guess who's going to do it?
