When I first started testing people would ask me how I could do it. It was so boring and doing the same test over and over would drive them nuts. In order to keep them some what sane they would listen to music while testing. I however loved the nuts and bolts of it all so I was able to just get into it and there were even days where I never once picked up my headphones. So yes there are certain type of people who can test and others can't but I have rarely ever seen a qa person minus myself in the early days without headphones.
I moved to audio books as they told epic tales while i tested and was able to test. The thing about audio books is you need to do books you have read so if you get into a really good bug you don't fill lost. Others and more recently myself included listen to podcast. Podcast are good ways to keep you somewhat entertained without having to pay to much attention cause they are short. Just coworkers my look at you like you are nuts when you burst out laughing. Another thing that helps is light chats with other coworkers. But remember you are working so keep your self entertained but also make sure you get your work done. I have never known a QA department to not have a lot of work needed to be done and tested 3 times over.
You have to keep yourself occupied. To do that you can create or use a through test plan. Giving your self a road map helps you let your mind wonder to those exploratory edges to find out of the box bugs. Have a smoke test that you need to run on every build in order to make sure a major bug has not crept in. Occasionally pair test with Developers on new features. Issues that might not even be out yet can be fixed before anyone can ever see them benefiting everyone. Another thing you can do is just go nuts and adhoc test the whole thing. Go where no tester has gone before and find that once in a lifetime bug.
Below you will find a link on Bug Huntress on how to alleviate stress while testing. More helpful tips.
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.
By Joe of Test Reactor and GC Gamers Connect
This weeks episode of Test Reactor we talked about giant robotic combat. Since I took the reigns on this weeks QA Hipster, Ben asked me to write an article on testing Giant Robots. While we usually test software side, testing hardware can be a fun means of testing and trying your hands at something different and new.
I don't have a lot of experience personally testing giant robots. While I do have a lot of knowledge in the area from tons of nerdy research, hands on experience is something I lack. But I do have a good helping of experience in auto mechanics. Which can be paralleled to robotics in a manner of speaking. A lot of the concepts are the same. Performance requirements, performance testing, usability, Security, Interface, Controls. All these are points of testing in which we can take a look at.
Why are we testing giant robot combat? First of all giant robots are freaking awesome. Hollywood, Japanese Anime, and television have brought us many different robotic combat inspired shows. Machines attacking machines. From transformers, to zoids, to battlebots these combat robot shows have inspired great engineering feats.
Recently the USA based company called Megabot raised 1.8 million on kickstarter to build a robot designed for combat. This 15-foot-tall behemoth is an impressive site. The goal was to create a combat robot to inspire other companies to build similar robots to fight in a new robot sport competition.
In japan a company called Suidobashi Heavy Industries had a similar concept with a giant human piloted robot. Their current robot Kuratas is an impressive marvel of technology. This was the first human piloted robot.
The Megabot team challenged Suidobashi Heavy Industries to a robot duel challenge.
Above is The Challenge
Suidobashi Heavy Industries has responded
Above is The Response.
While this is an exciting time for giant robots how would you go about testing one of these behemoths. Our friends over at BugHuntress have a really good article on “How Does One Actually Test A Giant Battle-Robot?”
I will be taking a look at different areas of testing. Similar to test driven development where you develop test plans from the design stand point prior to development.
Before we have a robot to test we have to develop said robot. We begin by first looking at the performance requirements of the robot we are going to test. Most of the time for combat based robots we look at the competition requirements. In the case of BattleBots the rules were lined up pretty well. (You can look at the rules here) However these rules cover remote controlled combat robots. Not the massive piloted combat robots that we are looking to test.
The basic performance requirements of a giant combat robot would be something that is mobile, versatile. Depending on the type of robot we want to use if we want a fast mobile robot, or do we want a slow strong robot. The two concepts would work well together, a fast robot that is also strong robot we must look at weight possibilities. Usually a lot of armor means a lot of weight. Which can be difficult to move quickly.
Speaking of mobility will the robot be a walker or a wheeled robot. perhaps a combination of both. Currently legged robots aren’t as fast as wheeled robots. Perhaps with a bit of experience and technology increases the speed of legged robots will increase and create faster means of mobility.
Next we want to determine the type of robot we want as far as a ranged based robot with lots of guns, or do we want a melee monster designed for close combat. With a ranged based robot, quick moving to get into a good shooting position is critical. A melee robot would break down a few other options as well. Do you want a grabber pincher robot that grabs its opponents, or do you want a sword and shield type robot that has a strong hitter.
Once we determine the type of robot we can begin to see pilot requirements. Do we need one pilot with a good user UI or will we need two pilots. Now that we are looking at the human factor we also need to look at the safety requirements of this. After All pilots are probably expensive and hard to come by. So we want to protect them as much as possible.
Now that we have the basis for the performance requirements we start the production of said combat robot. Throughout the production of said robot we will look for faults and points of failure throughout. Making sure to test it under pressure and in different circumstances.
So, looking at performance requirements, Looking at the needs or desires of the type of robot you want we can see a lot of different areas that need to be tested. Many areas will pop up as the development continues.
This week we will be having a guest blog by Joe from GC Gamers Connect and Test Reactor. Joe has been working in the Game Development since 2002 and has been a coworker of mine as a QA Analyst for over a year. He is also my co-host on Test Reactor a podcast about testing, gaming, and geekery. As soon as he gets me the blog I will get it posted.
So What are some Upcoming Events?
CAST 2015 August 3-5 - Grand Rapids, Michigan
Software Testing Training Week Dates and place may vary
STARWEST 2015 September 27th - October 2nd - Anaheim, CA USA
EuroSTAR Conferences November 2nd - 5th Maastricht, Netherlands
Eclipse Con Europe / Project Quality Day November 3rd - 5th Ludwigsburg, Germany
TestBash New York November 5th - 6th New York, NY USA
Better Software Conference East November 8th-13th Orlando, FL USA
GTAC (Google Test Automation Conference) 2015 November 10th -11th - Google Cambridge office (near Boston, Massachusetts, USA)
And a whole bunch I missed because I am posting this late in the con season or I have not heard of them. I will try and start making a list of cons for testers in the near future
But seriously It is Interesting and Important or why would I blog about it?
When you get a new build filled with bugs
When you get to test a new feature
The bug we both live for and yet never want to see
When unable to reproduce a crash so you try everything
Finally are able to reproduce a bug you have been working on for a while
DevOps is a software development method that emphasizes communication, collaboration (information sharing and web service usage), integration, automation, and measurement of cooperation between software developers and other IT professionals. The method acknowledges the interdependence of software development, quality assurance, and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance.
DevOps Visual Model - While development methodologies, such as agile software development, encourage cross-functional collaboration between the analysis, design, development, and QA functions, in traditional, functionally separated organizations there is rarely cross-departmental integration of these functions with IT operations. As illustrated in this visual model, DevOps promotes a set of processes and methods for thinking about communication and collaboration between development, QA, and IT operations
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.