Ben Weese

Finding the requirements for the software can be hard but a tester has to know when the software breaks and what it takes to run the software. If the tester runs at minimum requirements and it breaks then the requirements are wrong. Some times it is up to the developers what it runs on, some times upper management, and sometimes a tester runs several test. This will also have to be well analyzed and documented. You will also have to take into consideration your market and what kind of computer they have. If it takes to expensive of a computer you loose your market.

Requirements Analysis

• Eliciting requirements:(e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering.
• Analyzing requirements: determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.
• Recording requirements: Requirements may be documented in various forms, usually including a summary list and may include natural-language documents, use cases, user stories, or process specifications.

Remember there is several things besides the software and the customers who effect requirements. Such as Architecture what other programs are you using Java, squeal? Is the structure meeting the requirements? the design? the behavior? Allocated?

Remember to take all this into consideration and many more when setting your software requirements.

This is the first of many blogs that I will be writing on the Software Development Process. There is a lot to it and several options. Each company will apply a different mythology for there process. It could be agile, spiral, prototyping, or the dreaded waterfall. Over the years though each company starts with one and may switch to another but they are searching for the best one for them.

The Methologies did not appear until the 1960’s starting with the life cycle and progressing through out the years with Agile being the latest and from what I hear greatest. Since I will be going through each methodology and aspect I will end here and come back next week to blog about one of the Core Activities which is Requirements.

So what is end to end testing? Just like in the maze you are to get from point A of the program to point be. So in the example in the link I am using this week it is from login to logout. The example from Software Testing Help is below:

These test are done from the view point of the end user. What is their workflow and how will they move from point A to B using your software. These are ran to make sure that the user can run through their workflow with no issue. As seen in the maze picture there are times where you might off road or ‘Exploratory Test but the end result and the beginning result are the main points. In the example you run through logging in then through basic steps that any user would experiance. but follow a vertical work flow of the side bar. Then you logout.

So now that you know go and find something you are use to and create your own maze of test.

So you want to stay up with the latest QA trends how do you do it. Well here is a list of blogs from utest to follow. http://blog.utest.com/2015/08/17/10-blogs-to-follow-about-testing-trends/

I tend to follow a lot more blogs then just those listed for Utest. Using Bloglovin to follow I can keep up with all the latest blogs for testing. Here is a link to all bloglovin and all the blogs I follow: https://www.bloglovin.com/people/qahipster-11201189/following

If you like listening to podcast you can check out any of these 3 for learning more about testing.

• Test Reactor
• Testing in the Pub
• Working as design: the utest podcast.

Also join the http://www.softwaretestingclub.com/

So a while ago I wrote an article on Damn Bugs & Overlook and over the course of this year they have changed alot. For one they are now combined to Lean Testing. This great tool is being brought to you by Crowd Sourced Testing. So when you login you have your projects and you can have several going on at once. You then have a choice to go to view test plans or go to bug tracking. 

The test plans can be created for many test cases. There is a where you start at the URL, the user action and then what is the expected result you can then add other test cases. Each test cases has a user action and expected result. The good thing is now when you fail a test case you can report a bug which goes into the bug tracking.

The second part of the site is on bug tracking. They take all kinds of input from testers all over the world and put together a format for bugs. You can organize in several different ways. This is all editable and great for inputting a bugs with and outline to follow. With integration to slack this makes this your one stop shop for a lot of your qa needs. If you have not checked it out I defiantly would. Also check out Test Reactor where we go over Lean Testing in more detail.

Yes I am again coming to talk to you about unit test. The reason being the QA feild is moving more and more into automation and Quality Engineers. Manual testers are becoming less and less. Companys now want to know QA people can automate and code test. So I have already talked about Unit test before and have given you some links after learning from those links I learned I needed to learn by doing so I cam across http://www.preeminent.org/steve/iOSTutorials/XCTest/ and started following the steps I am not done yet but I have learned far more learning by doing. If you can I would highly recomended coding then writing unit test for your own code before jumping into unit coding on live code.

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.
http://blog.bughuntress.com/testing-tips-tricks/stressed-out-while-testing

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 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.