So what are Analytics and how can they help you QA. Well Analytics are "information resulting from the systematic analysis of data or statistics." according to Google. I use analytics when I am performance testing. At first I use to use a stop watch and would have to record the data on the slowness and record what my network link conditioner was set to test how slow and fast something should act. We then added anayltics and now all I do is load and save and the times are recorded by the software saving me days of work.
You can use anayltics for all kinds of things. You can record times like i did in order to see the performance of your software. then in slow parts you can run a time profiler if you are using xcode. What a time profiler does is it will tell you all the calls that were made and how long each one took so the developer can pinpoint the slowness. For websites you can use it to see how often was your site down, how many people are visiting, where are they from, how long were they on the site, what OS were they using. There is so many applications for analytics.
So besides performance what other things can QA learn. Well you can learn what OS and browser they were using so you know what to test more then another scenario. You can learn what is happening in the field rather then a controlled environment and you can try to recreate it with all the given information. This can help you get ahead of the game.
Here is a QA Gif for you:
When you have figured out a complicated bug.
We're pleased to announce that ReignDesign is this weeks sponsor. ReignDesign is a mobile app development studio with offices in Shanghai, Barcelona and Santiago, Chile. They work with brands like Porsche, WeightWatchers and Nike to create amazing mobile apps. But more importantly, they're trying to make a great place for developers and designers to work.
They're currently looking to hire a QA Engineer in their new Barcelona office. If you're interested, or have any friends who might be interested in relocating to Barcelona, you can visit their website jobs page.
For more information on Reign Design check out their website or listen to Wednesday's podcast of Test Reactor.
Do to unforeseen circumstances I will be unable to blog this week but should be back up ans running next week. In the mean time enjoy this QA Gif.
What Developers think QA Do
When documenting a bug there are some things you will need:
Bug name/short description - You will want to state the basics of the bug some thing simple but descries the whole bug. Like "Crashes when in 2 windows and deleting an object from window 2" Now that does not describe the whole thing but it gives you a basic idea. This is more so you can easily find this bug later.
Found in version - What version did you find it in. This allows the developer to go back to that version and see what happened and if it is in a newer version.
Type of bug - Is it a crash, is it data loss, is it a spelling error, or is it a consistency bug. What type is it?
Severity - How bad is this bug? If it is a spelling error that depends if the client sees it a lot then big if they rarely see it minor. Crashes are big and so is data loss. you have to judge this so they know which bug to fix first.
Reproducible - Is it reproducible or did it just happen this one time. the more reproducible the easier it will be to track down and the bigger and issue it is. If it is complicated then maybe not hit so often so lower. And if it was a on hit wonder then it may never be fixed until you find a way to hit it consistently.
Hardware setup - What is your hardware setup? there might have been something in your setup that is different then what they test and this will show us the key. If you are on a mac instead of windows, safari instead of chrome... that is important knowledge to figuring out what went wrong.
Screen shots and videos - These are life savers always, always have these. When you type out a bug and can't explain it the screen shots can speak that 1000 words. and videos can show someone just how to reproduce.
Other attachments such as spin dumps, crash reports, and error logs - These are all very important in trouble shooting slowness and crashes and what might have went wrong the programers have these spit out things for a reason. you should learn to read these and I will go over this in the future.
Long Description - This is your brass tax, your meat, this is where you will put everything you can into this ticket so they can figure it out. But remember the Dev might like a lot of info but they don't want a novel. So be to the point and make sure you are documenting 1 bug and not 3. They may read the first paragraph and find a bug in that one and then fix only that when your ticket was a 3 parter. Then make 3 tickets and not just one to rule them all.
Steps to reproduce - What were the steps the reproduce your bug? This is critical in figuring out what went wrong. Even putting this in a one hit crash is good and ending with can't reproduce a second time. Any info can help.
Expected results - What were you expecting to happen can help the engineer figure out where it went wrong so always add that if you can.
Also this week on Test Reactor I go over this same thing. So when Wednesday rolls around feel free to check it out at www.testreactor.com
When asked if a buggy build is ready for release
When a developer fixes one bug only to create several more
When explaining to others what your day was like
When you get a new build and are ready to test
When testing a text box or text field
QA Hipster is a Quality Assurance Technical Lead for an software company, mostly working with Macs. I have been in the field since September 2013, and have a bachelor's degree in Management Information Services. I started my studies at Iowa State in Software Engineering. I have been working on moving my company forward with the latest QA techniques.