… Continued from TestBash 2016 (part 1)
Coffee done and dusted, more people caught up with and back for more TestBash 2016 goodness.
Talk 3 – Katrina Clokie – “A Pairing Experiment”
As someone who has never pair-tested, nor seen any developers pair-developing and never having heard anybody in real life tell me that pairing is particularly valuable I was torn 50/50 when I read about this talk (well maybe closer to 70/30) in favour of pairing.
Part of me knew immediately of the benefit that sharing knowledge could bring to testers with differing skill sets, different mindsets or that are willing to take on board all ideas and give them a real shot in their daily testing – Testers who want to get better and will entertain all information in that pursuit.
The other part of me simply saw the age old argument of “while someone is not actively working on a project there are less resources on it and therefore testing isn’t as efficient in that moment of time”.
A few minutes into the talk and the genius is revealed; Native vs Visitor testing!
Native tester (who is involved heavily with the product) “drives” the testing as normal but has the benefit of a second pair of eyes on the screen asking questions; Why did you do that? Can you repeat that? How do you know it works?
And for a Visitor (little knowledge of the product) “drives” this time with the Native tester’s expertise to navigate and answer questions. “What do I do next?”, “Is this a bug?”, “Can you remind me how to….?”
The benefit here is immense! Having two sets of eyes on the same product with different domain knowledge for the test “session” basically:
- Refocuses the Native tester into questioning *everything*
- Points out potential issues that the Native tester’s domain knowledge may be masking because they instinctively know the answer.
- Potentially provides the Native tester with new approaches to testing their system.
- Provides the Visitor tester with new domain knowledge (useful for future projects)
- Provides the Visitor tester with new approaches which may be useful to their testing and/or project.
- etc etc etc
SO many benefits! Really excited to try and incorporate this type of work if possible!
EDIT: Since this draft was written I’ve spoken to my boss and we’ve agreed to pair test for an hour per week across different projects and skill levels to disseminate experience and knowledge and to generally break the work up a little. Bonus!
Talk 4 – John Stevenson – “Model Fatigue”
(F)requent (I)ntensive (B)usiness Critical (L)egal (O)bvious (T)echnically Risky (S)takeholder Mandated
(S)ecurity (L)anguage Requ(I)rements (M)easurement (E)xisting
(S)couting Obsessively (A)uthentic Problems (C)ognitive Savvy (K)knowledge Attracts Knowledge (E)xperimentation (D)isposable Time
Mnemonics mnemonics everywhere! And lights! And animation! And music! Well that’s certainly woken up the crowd! And now the mnemonics are changing; adapting, combining.
I SLICED UP SACKED COWS
Funny stuff! It flies in the face of those reciting mnemonics like a mantra. I reckon there are a few people with hairs on the back of their neck standing up right about now; it’s borderline blasphemy to some! *chuckle*
The point is well made however. Mnemonics are test models and re-using “cookie cutter” test models without first slicing and dicing them to remove useless inclusions (and add your more useful ones!) wastes time, budget and degrades the effectiveness of the testing effort. It should almost be a pre-requisite that a mnemonic can *only* be used as guidelines.
An example given here is in the photograph; adapting HTSM (http://www.satisfice.com/tools/htsm.pdf) to evaluate valuable areas to automate.
Another fantastic talk!
Talk 5 – Patrick Prill – “Accepting Ignorance”
I am ignorant… To a certain extent and by a certain version of the dictionary definition of it. I think a lot of people are and we all have the ability to correct that issue should we choose to, it’s just that many people don’t have the drive or the need to overcome it (“if it’s not necessary I’m not doing it”).
Ignorance can be boiled down to four letters – DIKW:
- Data – We have an overwhelming amount of objective, raw facts, relatively unordered. The base level of a pyramid.
- Information – Contextual, insightful information. The next level up in the pyramid.
- Knowledge – How to do things the right way. The next level up on the pyramid.
- Wisdom – Do the right things and why we should do them. The smallest part of the pyramid. The pinnacle of info.
Be aware of the borders of your knowledge and use that awareness to improve yourself or speak to others with the knowledge you need in the short term to reach your goals.
Much of the talk seems like common sense to those with a thirst for improvement and knowledge. For those who don’t seek to improve either through apathy or simply not thinking about improving it’s a key talk for the day!
Aaannnddd that’s lunch!
Part 3 coming in the next few days!
So just last week there was another phenomenal Ministry of Testing event; TestBash 2016 and what a great event it was. Unfortunately I wasn’t able to attend the workshops day (next time Gadget; next time!) but the main conference day truly was spectacular.
I absolutely love that feeling of walking into the main bar area before the event starts and seeing wall-to-wall testers and people I’ve not seen for months wandering over to say hi and have a quick catch-up over a coffee. If there’s one thing I regret at this point it’s that our B&B only allow breakfast from 8am which means no Lean Coffee with people and not enough “catch up” time before the event.
So after a nice catch-up with people we’re ushered into the main auditorium for the festivities to begin. The main man TutuBoss Vern is in front of the stage fending off a bazillion hello’s and psyching himself up to be the voice of TestBash 2016; our very own compare. A quick hello, hug and good luck to him and off to find seats we go.
Then we’re off!
With introduction, banter and itinerary for the day delivered more smoothly than a freshly set jelly it’s pretty clear why he’s the voice of the day. Kudos my friend!
So on with the show.
Talk 1 – Emma Armstrong & Lisa Crispin – “Building the right thing”
On the stage are Emma Armstrong and Lisa Crispin to talk about “Building the right thing” and I have a sneaking suspicion that this talk might be the reason everyone has been given a piece of A4 paper. The talk starts with a challenge; “Build something that flies through the air within 2 minutes” and my gut is to scrunch the paper up and throw it – Minimum Viable Product! My brain though has other ideas; my brain remembers a plane design I created in school that won a distance contest and it’s definitely achievable within 2 minutes so I build it with time to spare; accomplishment!
Emma and Lisa then show a slide of the product they wanted… Can you guess what it was? Damn you brain! Scrunched up paper ball would have been perfect. *sigh*
The talk is then about the fact that across multiple facets of a team there’s often a disconnect between what the business *say* they want, what they *really* want and what’s *actually* delivered and as testers we’re ideally suited to help to piece together all of the disparate parts of the projects so that we ALL know what the plan should likely be. We can be information facilitators to create a shared understanding of the end product expected by the client.
The talk perfectly verbalised the reason why one of my recent projects went 100% smoothly from inception to delivery with minimal overspend and only a few days beyond the deadline (solely due to internal It resource limitations). It’s definitely an approach I like to take where possible and something I’ll push for more often, especially now I can verbalise it.
Talk 2 – Dan Billing – “Testing or Hacking? Effective Security Testing Strategies”
This talk I’ve been looking forward to for ages. I’ve met Dan on several occasions, seen some short talks and his knowledge is fantastic on security testing so to listen to a solid talk on the subject is great for me.
Dan’s advice on getting to know your system under test (your “stack”) is logical but sadly not done enough in testing. From my perspective it’s about the length of projects I work on so in reality I’d spend a good few days getting to know the environment and how to best use/abuse it but when the total time on a project is a couple of weeks tops that’s far too much overhead. I think to a certain extent a “cookie cutter” approach would be the only viable option on such short contracts *if* security testing was allowed and within the project scope.
Dan goes on to reference an advert many people probably won’t remember. Armadillos! Crunchy on the outside, smooth on the inside! Armadillos!
Like systems armadillos are armoured on the outside to fend off attacks. Predators though have become more savvy and understand that the only attack possible is the soft underbelly so predators (hackers) have adapted accordingly.
Dan goes on to describe his “Model” for security testing. Great stuff!
- SCAN – Use Zed Attack Proxy (ZAP), Burpsuite etc
- VERIFY or CHALLENGE your scan results. Do they warrant further investigation?
- EXPLORE the verified security holes to see how they can be exploited.
- GO TO 1
Bug advocacy plays a HUGE role in security testing. Product sponsors often don’t pay attention to the impact specific issue could have on a system so it’s best to boil it down to specific, financially-related risks or consequences to get the message across.
Great stuff from Dan and I’m itching to start investigating the capabilities of ZAP, Burpsuite and BugMagnet more now.
Coffee break time!
… Continued in TestBash 2016 (part 2)
EDIT: This blog post was written earlier this year as an introduction to me but in the end I decided to actually talk about it in a 99 second talk at TestBash Brighton 2016 instead.
Because of that I saved it as a draft and never published it but I figured it’s daft sitting on my blog unpublished so here you go. 🙂
I’ve been a professional tester since 2003.
I say I’ve been a professional tester since 2003 but recently realised that I’ve had a “tester” mindset for much, much longer than that; In fact as cliché as it sounds I’ve pretty much been a tester my whole life.
So today I thought I’d like to suggest a little game to everyone – See if you can remember your earliest memory of “testing” something.
For me as far as I can remember it’s when I was 9 years old and was bought a Bandai Lazer Tank for Christmas.
I remember unwrapping it and staring in wonderment; what on earth does this thing do?
Within minutes I had questions:
• Will it work on lino?
• What about carpet?
• What about the pile rug? It’s a tank after all! – Oh nope; stuck on the rug!
• Do the pieces pop off in a different sequence each time?
• What if I shoot it through the patio door? Or the mirror? Or my granddad’s Ray Bans that I’m specifically forbidden from touching?
• How far from the tank can I be and still get the laser to hit it? That’s a great reason to go outside in the cold to the back of the garden in nothing but pyjamas!
• I was obsessed with finding the limitations of the thing!
So for me that’s my earliest memory of “testing” and I think a lot of people with testing careers probably have a similar mindset that started WAY before your “profession” as a tester began.
So have a think about your own earliest testing memories and let’s get sharing.