Ben Weese

This is blog is happening because I have went to Nebraska Code Conference the last couple days and will go again tomorrow. There is just so much to cover that it had to be posted as I was there and while it is all fresh rather then waiting a and posting everything on Monday. Don’t worry I hope to get a blog up Monday as well. 

Thursday
So day one they had all kinds of workshops you could go to. I choose to go to “Mobile Dev Boot Camp” as it all that was needed was knowing object oriented programing(Java, C, C++) and have a mac. Plus he was going to cover unit test, X-Code Instruments, and automation testing as well as how to use Mac OS sever to help with automation. We went over making a simple Jeopardy app and it went really well until I fell behind on coding. Now since I am not a developer, I was ok with this and still learned a lot. Then we had a good lunch and resumed. The second part of the day I downloaded the code from github and was good to go. However people got lost in the complexity of part of the app. Everything I wanted was covered briefly so people could get the app built and the server automation was left out. Again this is a developer conference not a QA one so I was ok with this happening.

Friday
Today started off with Richard Campbell from .Net Rocks giving an amazing speech about how technology has changed over the years, moved to the tablet, and how the tablet is changing things with a war against the mouse. This got me thinking now that kids are raised on tablets they will never no the joy of how much technology has changed over the years. They will just expect it to happen and it will. Richard told a great story about a 400 pound hard drive Goliath and a lamp named David. If you have not heard the story you should. Soon that whole story had us reliving the advancement of technology, and how things we grew up with will no longer be relevant to this new generation. What does this have to do with testing? Technology is always changing, change with it.

Next I went to a breakout on podcasting since Joe from GC Gamers Connect, and I want to kick of Test Reactor to be a testing/geek podcast. It was hosted by Kevin Harvell, a host of The Tech Informist. This was very informative and a good place for us to learn how to kick off our podcast. The first thing they stated was that you need to focus on sound quality and content. We have our content ready so we need to focus on sound quality and performance. Next we will need to figure on how often will we record and release? Will we have guest? These are things Joe and I will need to decide. They then went over various equipment and prices which I will not go over here. They talked about when having guest using google + hangouts as you can do a live and recorded show with your guest. They also told the importance of a good album art. They also gave several sites to help out such as DVDVideoSoft, Audacity, Cast Feed Validator, and Podcast 411. They also mentioned podcast hosting sights such as libsyn, blubrry, and soundcloud. They also went over various ways to make money such as plugging sponsors and paypal. It was an amazing breakout. I then stayed for the episode of .net rocks which I am sure you can find on their site.

Then I went to one about HTML5 which was over web components which seem amazing to me. It was changing the way we could site to use templates which would make it very easy to debug and figure out what went wrong which is good for QA. I would also check out plunker. The thought to name custom elements for easier read blew my mind and the Shadow DOM to hide could was pretty neat.

The next 2 we went to were about ReST API. Both teachers were very good but it did not have to do with testing and I am not sure I fully grasped it all. 

Finally I came to the one I had been waiting for “Getting Started with Test Driven Development”. This was amazing and highly recommended. Instead of get the specification > code > test you switch coding and testing. This means you make the test made before the code, as a manual tester who has never seen this my mind was blown. So you have 3 steps red- you write your failing test, green- you code to pass your test, then you refactor and optimize your code. You create test for bugs so they don’t come back. Instead of using a database with your unit test you will use a mock database so that you can’t blame the database for the fault in the code. Later if you want to test both database and code you use integration test. With the unit test you want to write them in 3 steps as well, you arrange your test, then you act, then you assert. You write your test to drive your code, and you use the drive principle of not repeating yourself.  As I thought about all these, and took these mind blowing things in I wondered where QA would fit in this TDD world. Then James said that QA will always be needed to find the bugs only they can find. This was just to get rid of simple preventable bugs. This also saves time on dev. What I would like to see is a TDD that is driven by Pair testing. The developer uses his QA to help him develop test, and they work together to make amazing code. This sounds like a world I want to live in! This breakout was presented by James Bender

So in my quest to be the best QA Team Lead I could be I have been relearning coding. I started out studying Software Engineering in College and took 2 years of java, 3 semesters of C, one semester of C++, and one semester of web based programing. That is somewhere around 27 credit hours. I was actually a really good programer but a bad internship sent me away from it. Now that I am a QA Team lead, I work with programmers on a daily basis, so the fact I read and understand code helps. Also there are many test I could run if I programmed them myself or learned how, but it has been 7 years and I am rusty. So if you’re a QA manual tester looking for the next step to Quality Engineer or Automated testing; What do you do?

Here are some pointers:

Sorry, had to be done. So what can you do to learn code? You could always sign up for workshops, or go back to school, but not everyone has the time or money for that. Then what you can do is go to online schools to teach you about coding in your own time. These are sights that help teach you how to code. Will you be able to add it to your CV or resume? Probably not, but you can start adding these to skills you know and even build up a github account. So what are some of these sites?

Code School

So as I work for a company that programs for mac computers I wanted to learn Objective C syntax as I already knew C and C++. A fellow coworker showed me to Code School where he took Try Objective C. I tried it out and started to like it. I then tried a few more classes and I really loved Rails for Zombies. They have some good courses, some are free and the rest cost a membership of 29$ a month. 

Code.org 

Now this one I have not tried but it is for all ages so maybe you can try it with your kids. They have all kinds of ways to bring in all ages and run with the saying that everyone needs to learn to program a little, and to try their Hour of Code. It is backed by Celebrities and is really out there to make an impact on the world of programing.

Codecademy

This is one I have recently started I have gone through the make a website class and learned a lot. This one is completely free and will teach you about website programming to ruby to python to how to use certain API’s. I would suggest trying this site out and take from it what you can. 

Udemy

Udemy is entirely different from the other sites. What Udemy does is sells courses that other people sell. For instance the course I bought was on how to make IOS 8 apps with swift in the course as well. They have all kinds of courses and run deals all the time. You can by a 500$ course for as little as $10 and learn so much. You have access to videos, contacting the professor, quizzes, and other materials. This is really good for when you want to learn something at your own pace that has a lot of information. This one has been recommended to me time after time.

W3 Schools

This one was shown to me as a really useful reference tool but it has it’s own tutorials as well. It has all different kinds of web stuff, server stuff, and XML stuff. So I would check it out if you don’t like the tutorials the reference material is still good to use.

So when I started at my current company I started in support calling and talking to clients and fixing various issues. I worked my way up to taking tougher clients then eventually moved over to become a Quality Assurance Analyst. When I first started we were 5 testers who tested the whole software as a whole. No one was a specialist in one area and no one had any say in any part of the software. We were even left out of important meetings and basically were the bottom of the barrel but we put in our bugs where ever we found them. Shortly after I started there was a plan to move more towards what Spotify does and have a bunch of groups that were made of programers, testers, and something called a Product Owner. Since at the time we were short on QA a lot of us were in multiple squads. As we kept with this new set up more QA was needed and we now number a dozen.

Now with the change QA has a voice in their part of the software. We specialize in testing only certain parts of the software and work closely with the developers and product owner to put out a better product. This has changed for the better as now QA has a voice in each squad and everyone is a equal in the squad. We get a say in fixes and designs. This has been a definite improvement to how things were before. However some old habits are still creeping up when admins take over our squad for random new projects and sometimes QA is left out again. This is happening less but over the years I hope it will fade. We are now getting more control with the product owners getting more responsibilities. So far agile is working really well for us but like most companies we have yet to embrace the full agileness.

Currently I am working on a podcast site with a fellow tester of mine called Test Reactor. This is going to be a podcast by geeks for geeks. There will be a segment every podcast about Software testing as well. This is to show the world that Geeks work too. I hope it can be under way soon and will update you when we get our first podcast going. 

Test Reactor

So a big debate that is heard a lot is whether to use Exploratory testing or Scripted. Exploratory testing is where you go in and you search the app specifically looking for bugs. You are going to search anywhere and everywhere based on the design. You will also try things out side the design. Basically think of it as you are on a safari hunting for bugs. You are exploring new territory looking for things that are out of the ordinary. This is a very widely used way of testing and also very popular.

What is Scripted testing? Well script testing you have a set script based on the design and how QA will be testing the software. With this you can get through and make sure certain points are hit. If something needs to be tested then you add it to the script. This is what you use a test plan for and you can read more about that in my first couple blogs. Think of it as a play and if it does not go a written put in a bug.

What are the benefits of using both? There is more benefits to using both then there are to not using one or the other. Scripted is really good and getting a through test but may miss something. Exploratory will help you find what you are missing but is no where near as through. This in hopes makes our below pie chart have less not found.

Conclusion: Use both in everyday testing.

A while ago I read an article on the future of agile testing. When reading through I saw this thing called Pair Testing so I looked it up and found a good article at this link. This is when the Developer and QA work together testing. This way they will hit things normally they would not hit separately plus things can be fixed right there on the spot or you can at least you can get the information the developer needs to fix the issue. This will also help with QA, Dev relationship as they will work closely and see how each other operates. This we be a good idea for doing 60-90 minutes a week. 

Not only is this a good idea with a dev and a QA working together we have found within our own QA that 2 QA testing together you will hit issues neither of you have hit together. This is because you are both different testers and will test differently and so together you will try things neither have thought of. Also you will be able to track down more detail since you both have different ways to figure out the issue. You can also write a very thorough Test Plan if 2 of you work together to hit all the test cases. So do I feel Paired Testing is the wave of the future? I believe I think it is. 

To know more I suggest you go to Http://softwaredevelopmentisfun.blogspot.com/2008/07/pair-testing.html

When working in QA you will receive tickets submitted by clients, support, or various other people. It is your job to go through them using these 5 steps.

Sometimes when testing software you will come across the dreaded white whale. In my case this was a crash that only I have reproduced, but our clients were hitting it quiet often. Every time I hit the crash it seemed something different caused it, and was only reproducible 12% of the time but I had clients hitting the crash left and right. So “Call me Ishmael” I had to hunt this white whale down. I spent 3 weeks hunting using all kinds of tools and using resources just like Moby Dick did to hunt down the white whale, to no avail. Then one day when hunting a run of the mill crash that I knew how to reproduce I hit the whale. It turns out I was running all these tools to catch the run of the mill crash that it slowed down the software enough to allow me to hit the white whale. After I finally got all the info in it was a line change of code and the white whale was no longer a bother. 

As the picture states there are several white whales out there in the testing world. You will run into them and you will hunt them down. Just don’t get to frustrated when you can’t, because sometimes you will run across and figure it out without even realizing that is what you where doing. Remember to think outside the box, and use all the tricks you can. As testers get more tricky, so will the bugs.

What does it take to write a good bug? There is a lot of time where a bug comes in from a somewhere else and you have no idea what they are talking about or what was tried. How can you reproduce it if you are unsure about where the bug is? 

Here are some must haves for a bug.

• Short Description/Title – This is where people will look to see a summery of the bug, it is very important as people will look here to find the bug when searching.
• Description – Now this is the brass tax. This is the meat. Here you will enter all you can, and give a lot of detail. The more detail the better. But keep in mind that developers will only pay attention to the first paragraph or so. So remember if you have multiple issues make multiple tickets instead of just one giant ticket. Also give any workarounds or steps you tried so that the engineer will know.
• Expected Results – This is where you explain what you were expecting to happen vs what did.
• Steps to Reproduce – How did you recreate this so we can? This tells us the steps you took to get to the bug, and is very important.

The rest are going to be drop downs based on the software. Make sure you select the appropriate one. 

Attachments are a huge help. Even the worse bug can be trumped by a great video or screenshot. I have gotten bugs where I had no clue what they were talking about until the video played. Once you get good at putting in usability and functional bugs you can step using some awesome tools. We can go over that in a later blog.

Damn bugs was founded by Crowd Soured Testing as a online tracker for bugs. You start by creating a Organization and then you have projects. The projects can then have all types of bugs. This is mostly a web based one so there are web browser extensions to put in bugs for websites, which is really useful. This can also be used as a stand alone. There are different statuses for project management, different types to tell you if it is design or dev or any other kind of ticket. You can add other team members with different jobs. They are also really good about listening to feedback and getting back to you. There is sorting, searching, and color coding. Also the bug reporting works well and prompts good reporting to anyone who is not use to bug reporting. All in all, for where it is at, this is a great system, and I can’t wait to see what it has in store for the future. Also one of my suggestions I made were to add test plan integration. The response I got was they had bought Overlook and were working on it… yes many awesome things for this sites future.

Overlook was currently bought by Crowd Sourced Testing and is a test plan website that will be integrated with Damn Bugs. Overlook is about making a simple test plan. The test plans for this were also more designed around testing web based applications but again you can use it for other plans. First you will create a project within your account. You can than manage a team, and invite new testers and create new test plans for the project. From the first page you are also able to edit, see results, and start the test. When you create the test you are able to do it line by line with no formatting. You can pass, fail, and add notes to failures. When tied to a site you can run the test plan at the top while having the webpage below. It is very simple and could use a lot of growth. It has the same mechanism Damn Bugs has for feedback but currently that is not heavily watched. My guess is it will grow as Crowd Soured Testing takes a bigger look at it.

Trello helps managing projects, it is useful for several things that a tester can use. Trello you can make list, add cards to the list, and move them around like your very own work board. This is great for managing a backlog and assigning bugs. This shows a great workflow that works really well for agile teams. Our team uses it for managing projects, and for managing our back log. You can organize, prioritize, add labels, and filter by the labels. You can also build test plans where you can create checklist for each card. This site is very versatile and allows for many different uses. You can also create organizations and add people to them.