You need to know what's on the cutting-edge of technology. Find out what's coming and the unique Warptest POV with just one click on the "Blog" tile.

All posts tagged Testing

Embracing the Obstacle

The obstacle. What is it?

GUEST POST: the following is a guest post by close friend Dan Shernicoff AKA @BrasSMan75. He’s written for Warptest in the past about WiFi Security and knows his stuff. Thanks for contributing Dan. Read on folks …

As a relatively freshly minted CSM I clearly remember the instructor saying that what Scrum does best is shine a light on the dysfunctions. It’s true, Scrum shows us where our problems are. Sometimes it shows us the boulders in our path and at other times we see the pebbles. What’s universal with these is they cost us in time, productivity, and job satisfaction.

Why We Test

When we write software, we test it to identify the bugs in our code. We try to find the success cases and the failure ones; we test both positive and negative outcomes. Having run all our test cases we invariably have found bugs – some are boulders that might require a redesign of the functionality while others are pebbles that we need to address to keep our users from failing while others yet are just gravel, annoying but of minimal consequence.

As we integrate Scrum we are constantly testing ourselves and our processes. Just as we found bugs in our code when we tested our software we will also find bugs in our processes, systems, workflows, and teams. Some of these are boulders that require major changes to how we get our work done while others are smaller and cause inefficiencies, distractions, and loss of productivity.

Just as we track our bugs in whatever tool we choose we use we need to track our obstacles. Just as we don’t take bugs personally – they’re mistakes we made while doing the best we could – we can’t take obstacles personally. We need to “embrace our obstacles,” give them a big hug, and show them the door. The only way that we can truly benefit from Scrum is not by marking the bumps in the road but by removing them.

obstacle - agile - tree trunk

The BrasSMan75 POV

I say all this with the self-knowledge that I have kicked myself many times for bugs that I have introduced into the code (and into the process at times.) I know this is hard but if we don’t do it we will never evolve our teams into their best versions. Whether the obstacle is that we run out of coffee the day before we resupply the break room every time (whether it is because we don’t order enough or we wait until we run out is irrelevant,) or that the tool that we have decided to use is unwieldy and not giving us what we need, or that we are having excessive meetings to communicate data that is easily accessible should we use the tools at our disposal, we need to address the problem. In the first case it’s simply a matter of changing the ordering habits, in the second we need to take time and try to find either ways to improve the tool or a tool to replace it with that will meet our need, while in the third we might need to train the people calling the meetings on how to use the tools to get the information.

As we develop and test our code we look for our bugs and fix them. As we go ahead with our stand ups, our retrospectives, and our sprints we need to look out for the obstacles and fix them. When we see the obstacle, we need to run up to it, give it a hug, and show it the door.

The Warptest POV

Dan raises a few interesting points here about our work habits, productivity and how we need to be engaged with the process for sprints to succeed. Agile can lead to rote adoption of the “rituals”. Framing the work in terms of the obstacle and how we behave when we encounter it is a valuable mindset. Thanks again Dan.

Boston Dynamics Can Solve Autonomous Vehicles Biggest Problem

The Boston Dynamics robots are successors to Robby the Robot  and they are not cute and often just a bit worrying to see in action.


Visions of robot uprisings, SkyNet and Terminators aside, these robots are astounding and can fill many roles that will complement humans or protect them. The US Navy announced SAFFIR, their firefighting robot prototype in 2015. The idea being SAFFIR can go into enclosed, smoke filled spaces aboard ships and fight fires instead of risking sailors.

Big Dog or the LS3 was a DARPA robot designed to carry heavy loads into the field, accompanying soldiers or marines.

We have military applications of cutting-edge robotics and yes, these robots make a lot of people feel uncomfortable but, military technology (when not weaponized) often migrates into the civilian market. How can these robots play a meaningful role in civvy street?

What’s the problem?

Yesterday, I posted about the first autonomous vehicle related fatality to occur and how technological disruption without ethical exploration of impact could be our Frankenstein’s Monster. In a related Facebook discussion with friends it occurred to me that calling the phase of releasing these vehicles onto city streets for “testing”, albeit with human monitors is optimistic at best. That said, I have found it very hard to find details online about the end-to-end testing methodology employed. The one source I did find was the California DMV site regulations for testing autonomous vehicles.

Autonomous vehicle testing - Boston Dynamics

I came away with several big questions:

Testing questions - Boston Dynamics

Besides questions there are some assumptions:

Stages of testing: one can safely assume that software is unit tested by developers and then the autonomous integrated systems are tested through simulators. What other stages of testing are there prior to testing in the real-world?

What is being tested: One can assume that the comprehensive list of features that allow an autonomous vehicle to function and interact in real-time are under test.

Test-cases: the different scenarios tested will range from functional tests, thru load and stress of the system into emergency scenarios.

Testing success: what is the pass / fail criteria for approving an autonomous vehicle to be released for general, real-world use? One assumes the tolerance for error is almost zero.

The Warptest POV

Autonomous vehicles certainly fit the description of technological disruption and their impact on the real world can be wondrous or catastrophic. A lot of which, depends on the depth at which they are tested.

Whilst I am certain crash-test dummies were used as in any automotive testing, this does not deliver the level of testing that IMHO is needed. Boston Dynamics has the solution. The testing stage before real-world testing where human drivers in other cars, bikes, trucks and pedestrians are all involved would be to build a testing environment that replicates the real world and to mitigate the risk to human testers, use Boston Dynamics robots to be the test-data used to run the different test cases.

The test-cases would have to provide optimal coverage of every conceivable scenario, but that data is waiting to be analyzed and derived by a good data scientist. Every recorded traffic mishap, accident, crime or fatality is a test-case that needs testing and this can be done in a testing environment that can replicate all weather conditions (and other variables). Another layer of testing will have to be the behavioral algorithms that allow autonomous vehicles to make critical decisions. If a vehicle is placed in a no-win scenario where either a passenger or pedestrian is sure of being hurt or killed, does the vehicle respond as expected and what is expected behavior? Is it based on learning or something else?

The good news is Boston Robotics or someone like them can provide a critical facet to this testing so that spontaneous pedestrian actions can be tested without risk.

SkyNet not - Boston Dynamics

Image via YouTube: with thanks to Terminator: Judgement Day.

Instead of being creepy robots that make some think we are one step away from SkyNet, these robots can be our path to safer autonomous vehicles.

Let me know if you think Boston Dynamics can solve this, if these robots creep you out or if you are building your post-SkyNet bunker after seeing the videos above.

I had my first cup of coffee when I was 25 and that was it.

It was a cold rainy day, early morning, in the desert. I was on a training exercise with the Army and we had stopped our jeep for a break. One of the guys fished out a small gas stove, a tin pot and made Turkish Coffee with cardamom. He offered me a small glass full of coffee and a heaped spoon of sugar and I took my first sip. The rest as they say, is history.

As a Manchester boy, I grew up in a house where a nice hot cuppa tea was the staple. Usually PG Tips. Coffee in the 70’s, 80’s and even 90’s in England was Nescafe if you were lucky, and had no attraction at all.

After tasting my first strong, black, rich Turkish coffee I knew I needed to try more real coffee, and nothing with foam, frothed milk, syrups, flavourings; just shots of the good stuff. I tried espresso and I was totally hooked. Suddenly I was in a meaningful relationship with ground, brewed beans.

Luckily I lived in Israel, a country which takes its coffee seriously. This maybe one of the few issues the whole Middle East can agree on.

Over the last few months I’ve graduated from grinding store-bought coffee beans to getting interested in home roasting.

Home roasted coffee - software tester 1

Software Testing and Coffee Roasting?

As a software tester I approach new projects with research; online and word of mouth. I discovered that for the “hobbyist” the best start is to either use a pan on the gas or better a popcorn popper. As I’ve written in the past, testing is improved when it becomes like kata.

Of course, the beans are everything. I planned the following: –

Keep a note of all tests and test results: I used Microsoft Office for this (see the table below)

 

  1. Make a list of available green (unroasted beans)
  2. Test the quantity of beans in the popcorn popper that produce optimum results
  3. Make sure all beans are bought equally fresh (as much as you can) and stored the same way. Fresh = flavor.
  4. Define optimum results: evenly roasted, the coffee bean oil still present on the beans, no burnt taste. All beans ground for 11 seconds in the same Bosch coffee grinder.

The popcorn popper has a functional constraint, after 3 minutes or if overloaded it would overheat and shut down until it cooled off.

Bean

2:00 min

75 grams

2:30 min

75 grams

3:00 min

75 grams

2:00 min

150 grams

2:30 min

150 grams

3:00 min

150 grams

Kenya AA

Sumatra

Costa Rica

Colombia

Brazil

Ethiopia

Why do I mention these constraints? The last time I roasted I was in a hurry and overloaded the popcorn popper. It subsequently shut off to cool down at 1:45 min. The beans were under roasted so I siphoned off half into my cast iron skillet, turned on the gas and roasted half in the skillet for another minute and the rest in the popcorn popper when it cooled down and would restart.

The Warptest POV

If the popper is science, using the skillet is an art. You are roasting the curve of the bean against the flat skillet. It heats up to a higher heat and roasts quicker. You need to keep the beans moving and flip them over to get an even roast.

This slideshow requires JavaScript.

By comparison, using the skillet gave better results. You can see exactly what’s happening in the skillet whereas the popcorn popper has a translucent, orange cover.

As for the beans, I got a better espresso from the Kenya AA but, that’s always been my favorite. Family and friends have been treated to espressos, cappuccinos, iced coffees and the ubiquitous Israeli Hafuch when visiting.

My plan is to finish the Sumatra and order Puerto Rican or Colombian green beans next and keep on testing. One thing, home roasting is seductive in its own way. I’ve found myself on Amazon and specialty coffee sites absentmindedly pondering 5kg bean roasters and bulk coffee grinders.

When I find my perfect roast I’ll be sure to let you know.

Deadpool Has A Lot To Teach Us About Startup Management

Yes, Deadpool. The hit NSFW superhero movie from Marvel. Actually, much of the incredible success of the movie is due to these 10 secret tips.

Pay attention because these habits need to be learned, internalized and applied. Superhero startup management here we go…

With thanks to Marvel & 20th Century Fox for the Trailer

SPOILERS AHOY!

If you haven’t seen the movie and don’t want certain parts spoilt for you then turn back now.

 The 10 Successful Startup Habits of Deadpool:

  1. To quote the merc with a mouth, “Maximum Effort”. A successful product will not invent, build and launch itself. Get ready to work hard.
  2. Compromise can be the most R-Rated phrase you’ll hear. There was major pressure to tone down the movie but the cast and crew stuck to their guns. When people tell you to compromise, ask yourself if this matches your vision or product values.
  3. Break the 4th wall. Deadpool is notorious for his often hilarious conversations thru the 4th wall. In your case this is all about knowing what your customer expectations are.
  4. Testing, testing, testing. Our hero starts off in a white hooded romper, moves to spandex and chooses “Deadpool” over “Captain Deadpool”. Whether A/B, beta or product testing, it’s crucial to apply the results to building your best product. TESTING = SUCCESS.
  5. Give your fans what they want. The movie delivered everything the fans wanted and they loved the movie for it.
  6. Superhero team-ups rock! Deadpool encounters Colossus & Negasonic Teenage Warhead of the X-Men and later asks for their help. You can’t do everything yourself. Get help when you need it.
  7. Have a plan. Eat, breath and live it. Our hero wants payback from Ajax for his disfigurement and various other evil acts. He hunts his way up the bad guy food-chain with an enviable clarity and purity of purpose. Build your roadmap for delivering your product. It may change on the way but can you implement as decisively as Deadpool?
  8. Count your bullets. One of the two big fight scenes in the movie sees Deadpool with only twelve bullets and counting down as he goes. In your case, resources. Plan how you are going to use your resources and expect the unexpected.
  9. Branding. Is your product branded in a distinct manner? Deadpool chooses a red costume,” … so the bad guys can’t see him bleed”. Also the product marketing for the movie was almost too much with special clips for Australia Day (for Wolverine star, Hugh Jackman), Valentine’s Day, post-production clips and an ingenious billboard emoji ad. How will your product stand out?

    Deadpool - emoji billboard

  10. Own your mistakes. Wolverine (X-Men Origins) gave us a different Deadpool and it was awful. The new movie had several jokes mocking the earlier interpretation.

 

The Warptest POV

The merc with a mouth has a lot to teach us, if we are willing to listen and learn. Remember though, this is R-Rated so choose carefully who to see this with.

Make sure you have a pen and paper to take notes for your startup because it’s not every day you encounter a guru / sensei / ninja of startup wisdom like Deadpool:

Deadpool - the tem tips summarized

If you catch anymore Startup tips from Deadpool, I’d love to read about it in the comments.

(Disclaimer: no mercs, super-villains or henchmen were harmed in any way while writing this post.)

The World of Testers Has Something to Learn from James Bond…

CAUTION: SPOILERS ahoy. If you haven’t seen SPECTRE yet, you may not want to read this post.

It’s that time of year when we roll out the same tired, old arguments:

  • The Agile purists try to drive a stake thru the role of QA Manager.
  • Outsource companies say having in-house QA is redundant.
  • The Crowdsourcers agree but say crowdsource beats outsource hands down.
  • The Automated Testing purists take potshots at the Manual Testing crowd for the huge investment to provide test coverage that their scripts grant faster.
  • The Manual Testing purists snipe back at Automated Testing for ramp-up time and a several other alleged flaws.

Testers Arguing - James Bond

Don’t get me wrong, there is validity to multiple points of view and the testing industry like any requires challenging to grow and evolve but regurgitation is just that, the absence of new points of view on the same, weary subjects.

So, Where Does James Bond and SPECTRE come into it?

Here come those SPOILERS… turn back while you still can.

In the new James Bond film, SPECTRE we find Bond and MI6 assailed by the threat of obsolescence. HUMINT (Human acquired intelligence) has been declared redundant and a senior Whitehall official “C” is pushing for a unified ELINT (Electronic Intelligence) effort between 9 major nations, all under the umbrella of a shiny, hi-tech National Intelligence Center. Obviously, “C” will be the one running this multinational NSA like organization and the 00 Section is to be shut down because “C” sees no need for men like 00 agents in the field when tech can do all the work.

Testers James Bond SPECTRE

Meanwhile, Bond seems to have gone rogue, hunting a shadowy, criminal enterprise connected to his past. Faster than you can say “Goodbye Mister Bond” we discover this is SPECTRE and they and their leader, Franz Oberhauser (Bond’s pseudo foster brother) are the ones poised to take control of this unified ELINT center once it goes live.

Oberhauser or (redacted, I’m not going to spoil everything) Blofeld, is a staunch believer that pure ELINT will grant him control over the world.

Nutshell: SPECTRE, Oberhauser and “C” are the purists of automation that advocate replacement, obsolescence of eyes / hands-on testing. Real testers are not needed in their world. ELINT akin to automated testing can do it all (which is ironic considering the sheer number of armed henchmen SPECTRE employs, not even considering their assassin du jour, Mr. Hix).

Bond, M et al rely on Q to provide their automated solutions but acknowledge the world for what it is. Neither approach alone can get the job done. Only a holistic mix of an agent licensed to kill with tech backup will work just as only a holistic mix of both testing types will work. However, this is not the crucial lesson testers need to learn from James Bond.

The Warptest POV

Several years ago, I heard a kickass Marketing Professional talk about blogging to early stage Start Ups. The point he made was to blog about your niche, NOT you or your product.

Reading a post on a QA Outsourcing company’s site deriding in-house QA with the conclusion that you are better off taking their services is ridiculous and counter-productive. (You know who you are..)

Sometimes testers are our own worst enemy. These regurgitated arguments don’t benefit us. If there is nothing new to add to these issues, then let them lie.

Instead of the ability to evangelize a holistic approach, best practices and provide tailored testing solutions to suit each product, this reflects an immaturity in parts of our industry.

We need to do better because at the end of the day it’s all about ROI and demonstrating that testing is a mission critical investment. My hat is off to those testers who share, engage, encourage others and build a sense of community. This is clearly the way forward.

ARC Welder Is Google’s New Emulator…

… and it runs from Chrome on the Mac, Linux, Chromebook or PC. After Installing the Chrome App Launcher you are then going to need to install the ARC Welder (Android Runtime for Chrome; the only prerequisite is you have Chrome browser v41 or higher.

ARC Welder - Chrome App Launcher

ARC Welder - install app from play store

After that all you need to do is click on the App Launcher > click on the ARC Welder icon > select the APK of the app you wish to use and away you go.

ARC Welder - setup

The user can configure ARC Welder based on orientation, form factor and several other variables:

ARC Welder - configure

The Warptest POV

ARC Welder is a great testing tool for a first look at an app. It is limited to one APK (App) and is no substitute for either a true emulator or installing on a phone or tablet.

It was able to use the laptop webcam for some apps (e.g. Instagram) but not for some others. So let the buyer beware, you may experience bugs with your app.

For testers who have limited access to devices, are interested in UI testing or who write test cases without spec this is a great tool for getting a look at what may be an incomplete app.

One more use case is for when you want to demo your app easily to a big screen or projector, you can do it from ARC Welder.

I’m currently looking at ways to use this in concert with Automated Testing tools that run in Chrome.

Google managed to release this for just about every major OS that Chrome is available on. I’m sure other Devs and Testers out there would love a similar tool from Apple that runs in Safari on Mac or PC but I’m not holding my breath.

If you can think of other good use cases for ARC Welder I would love to know them.

Bug Reporting Is As Much An Art As A Science

… As a result sometimes running a refresher / brainstorming session on best practices in bug reporting for your team is a must.

As I’ve mentioned in the past, the testers and the person presenting can benefit hugely from the interaction.

The Primer

Embedded here is a primer presentation I use for this refresher on aspects of bug reporting I want my team to focus on:

The Warptest POV

Whether you are working with onsite developers or offshore, the need for sound observation and good bug reporting is critical.

A bug not reported or not reported properly will never get fixed. If your bug reports don’t give objective analysis or stress the severity / cost to the end-users then the bug may never get fixed.

So maximize your testing ROI and make sure every bug discovered and reported gets a fair chance a being fixed.

Do you refresh your bug reporting skills at least once a year?

Google Project Zero Is a Project…

…where Google discovers security bugs (not exclusive to their own software or technology) and once they notify the owner of said software the countdown clock begins.

Once 90 days ends Google will as threatened reveal the bug publically.

google project zero - site

Screencapture: from the Google Project Zero homepage

The idea behind this is to encourage a safer internet for all but there are inherent questions when it comes to Google and Microsoft.

Vendetta

The long running feud between Google and Microsoft has displayed a variety of outright hostile behaviors: –

  • Microsoft’s Scroogled campaign.
  • Google’s repeated blocking of apps like Google Maps or YouTube from making it onto Windows Phone (after working in collaboration with Microsoft to develop the app).
  • Google’s attempts to shut down ActiveSync in favor of their own CalDav and CardDAV.
  • Microsoft’s GMailman Ad.

These and many more reflect the harsh competition between the two companies in many areas:

Search, Location, Online Productivity Apps, Cloud Storage, Mobile, Mobile Apps, Operating Systems, Browsers and more.

Forget about “Hello I’m a Mac and I’m a PC”. This isn’t just negative marketing but has reached a point where users are being affected.

Get a Mac Ad courtesy of YouTuber LukePuuk

The Warptest POV

The main concern is that this situation seems to be only escalating and the consumer may benefit long term but could be harmed in the short term… DO NO HARM .. remember that?

The whole issue is exacerbated by the resounding absence of any Google security bugs in the same database. One would assume that the only thing better than outing your competitors bugs is showing how well you fixed your own. Unless you subscribe to the ludicrous notion that somewhere software exists with zero bugs.

Testing is not about “outing” bugs as an act designed to extort fixes or embarrass your competition because let’s face it Google, you are giving the finger not to Microsoft but to Windows users when you publicize a bug that the fix is not entirely ready for.

Will this encourage speedier solutions or compromises in testing and deploying the bug fix? Won’t the compromises just lead to regression issues? The goal shifts from fix the bugs to fix the bugs in time and not in a good way.

So come on Google, it’s time to remember that with great power comes great responsibility. Don’t be that guy.

It’s time to reexamine the paradigm for Project Zero and realize that every time Google publicizes one of these bugs they become part of the problem, not the solution.

Google Project Zero - With Great Power

Comic cover art and quote with thanks to the incredible Marvel Comics

As a tester and a consumer, I may not be pleased to learn that Microsoft hasn’t patched these issues yet but I’m seriously <redacted> at Google over this. There are lessons here for Google and Microsoft that clearly need learning.

Google should continue to test for security issues but if you are going to threaten others with a ticking clock shouldn’t the time frame match a real estimate of how long it would take to develop, test and deploy the fix? I doubt that all bug fixes at Google receive the same arbitrary timeframe.

How about you? Do you think Google needs to dial it back for the sake of the consumer?

 

Zombie testing applies…

To a state of mindlessness in the tester where certain scenarios or observations are missed.

Sadly, it can be incredibly infectious in the workplace.

When does this happen?

This can happen for a variety of reasons but let’s examine a special case where names have been changed to protect the innocent and guilty:

Elizabeth Bennet was a testing manager and was discussing web application testing with Darcy and Catherine, established members of her team.

She asked about cross browser compatibility testing and was greeted with a variety of the usual trollish comments about Internet Explorer.

Internet Explorer - zombie testing

One of the many examples of this kind of IE trolling

Elizabeth felt Darcy was especially annoying on the subject but suppressed her irritation and scheduled a test session for the team to test the web app cross browser.

Her suspicions were confirmed when they discovered a variety of hereto undiscovered defects in IE.

Elizabeth sat with her testing team and asked each tester what web apps they work with and on which browsers. No one on the team actually used IE and once again Darcy piped up confidently stating that the “lame” browser had such little market share it wasn’t relevant to test.

George the Product Manager was passing by and heard Darcy. He was quick to jump in and correct this misconception and stated that he was glad Elizabeth had decided to correct this oversight as many of the company’s end-users were IE users.

Bingley the web app Developer was building a new version based on all the new defects found.

Darcy came over to Elizabeth privately to apologize for his mistake and asked for responsibility for testing this in future.

Elizabeth was pleased and agreed but only if they pairwise tested the next version.

The Warptest POV

Testing requires a variety of skills, some of which I’ve addressed in the past but a tester cannot afford to compromise their objectivity by bringing their prejudices into the workplace.

Doing so may leave them open to being infected with the kind of zombie testing mindlessness mentioned in the story above.

pride prejudice and zombie testing

Image with thanks to Amazon.com

In a nutshell, good testing is not zombie testing and it’s worth asking yourself if there is a product or technology you have a blindspot or bias against.

The question you need to ask yourself is if you don’t use it for your own work, will you even think of including it in your testing efforts?

So check the pride, check the prejudice and stow the zombie testing.

 

Regression Testing…

I recently discovered that some team members needed a basic run through of the ideas behind this. With this in mind I used the incredible new Office web application, Sway to create a presentation that I could use to get across the basics.

Sidebar: Sway

Sway is available to anyone with a Microsoft account (which also means you have free Outlook.com OneDrive and Office.com) it comes with a strong Warptest recommendation.

This is not Powerpoint online (again you can find that in Office.com) it is clearly still in beta but allows the creation of simple, elegant presentations that can be shared or embedded.

Sway - regression testing 101

If you don’t know about the free, yes FREE version of Office.com then check it out ASAP.

Regression Testing 101

The Sway presentation works better with the accompanying talk but the core ideas behind the Regression Testing 101 talk are:

CIR- regression testing 101

 

The Warptest POV

After running through two sessions on regression testing the issue is refreshed in my mind and clear to the testers who needed the extra information.

Sway makes for an easy to use tool for creating elegant visual presentations online.

Clearly the benefits of creating presentations and training talks are two-fold: for the person giving and receiving the information.

 

 

Testing Isn’t Always Easy…

Once upon a time, in a testing lab far, far away was a young tester who sat each and every day testing his company’s apps.

(For the sake of argument) let’s call our tester Bill.

Bill was young and relatively new and had been assigned what he thought was the most repetitive and boring of all test plans.

However, Bill was not deterred and each day he would start anew and add every single problem, flaw, defect or bug in function, UI, UX, Load, Stress or against spec he could find to the company bug tracking system.

Bill’s greatest joy was adding these bugs to the bug tracking system and assigning severity. As Bill was still learning his job he was concerned not every bug would be fixed and so he marked each and every one as “critical”.

Bill Learns A Tough Testing Lesson…

After several days Bill was drinking his coffee and thinking how many times the Developers had come running over to talk to him about his bugs and strangely how many times they left with a grumpy look on their faces after claiming the bug was a feature, or worked according to spec, wasn’t critical at all or simply only happened under the rarest of conditions.

Bill was a little confused and didn’t really understand the negativity about his bugs or their severity.

Just then, Bill’s boss, the QA Manager walked in, gave him a big smile and sat down with his double espresso opposite Bill.

“So Bill, I hear you’ve been keeping our Developers busy with lots of bugs, right?” Bill’s boss gave him a huge grin.

“I guess so…” Bill replied.

“Well, I wanted to talk to you about the fact that I’m pleased that you are so dedicated and I know the bugs are all important but are they really all critical?”

Bill thought about this for a moment.

“How do I know?”

Bill’s boss sipped his espresso, “Well Bill, ask yourself what does the bug do to the App, to the user or to the system it’s running on. Once you look at the impact you can get a better idea of severity. Do you know why I’m telling you this?”

“Umm” Bill scratched his head, puzzled.

Bill’s boss put his finished espresso down, “If we mark every bug as critical then the Developers won’t take the really critical bugs seriously because we overused the definition and made them drop new work to fix some bugs that could wait. Luckily the Product Owner and I discuss the bugs and he sets priority with the R&D Manager but we need to check the spec to be sure if something is a bug or not as well… You know the story of the boy who cried Wolf right Bill?”

Bill nodded.

“As you get more experience you’ll learn not to be the boy who cries bug and be more confident about what severity each bug is. Today we are going to test together and see whether we agree on each bug or its severity. Let’s see how the Developers respond to that.”

From that day Bill worked harder than ever to learn what was and wasn’t a bug and to report each bug with the right severity. The QA Manager continued to be happy with Bill’s work, even had Bill train new testers and the Developers would treat each bug reported by Bill with seriousness.

… and they all worked happily ever after.

The Warptest POV

Learning how to write bug reports other than the uncompromising brevity derived from using Twitter also involves knowing if your observation is truly a bug and how to define its severity.

So the next time you are about to hit save on that bug, think of Bill and just review what you are reporting.

(This Grim tale is based on past, real life events. Names have been changed to protect the innocent).

 

What Can Twitter Possibly Teach Testers?

When working with testers who are still learning (all of us, right?), one of the challenges is finding a common language between testers and with Developers. This came up today and sparked this post:

This is especially important when it comes to writing test cases and reporting bugs.

In an age of “You had me at …” it’s crucial to get the point across rapidly and efficiently without compromising the information.

So.. Twitter Huh?

Twitter with its 140 character restriction on tweets is a natural teaching tool for anyone who needs to learn the discipline of brevity.

Twitter logo - testers

The thing is when reporting a bug it’s important to remember that you are imparting a story; a story that allows the Developer to know what should be fixed and under what scenario(s).

Imagine an ALM that was built on Twitter functionality: –

  • User stories, spec, test cases and bug reports all limited to 140 characters
  • Hashtags to make all of the above searchable by keywords.
  • Groups and Lists based on teams (e.g. QA, Dev, Product, Sales) and team members with usernames prefixed by the Twitter @.
  • Retweet, favorite or Direct Message (DM) other users.
  • Attachable images and URL shortening.
  • Trending subjects based on traffic within the ALM.
  • Analytics (of course).

The Warptest POV

As you read this keep one eye on the Agile Manifesto and see how Twitter Teaches Testers in an Agile manner. If you don’t see it, then it’s time to reread the manifesto:

agile manifesto - testers

The beauty of this method is not just the brevity but the rapid manner that it allows your testing to progress as everyone gets onboard with this manner of communication.

Obviously, there are exceptions, intricate or complex issues that require greater detail but the rule of thumb is,

“If you can’t sum up your bug or test case in 140 characters then it might be more than one issue.”

Does this speak to you? Feel free to offer your own experiences and ideas on the subject.