Translate

Monday, August 29, 2016

What is the best tool to use for automation testing?

As I was thinking about the best tool used in automation testing I was thinking of my least favorite thing to do as a manual tester. I think by figuring out what thing is the best use for automation we then can figure out what the best tool is.
My least favorite thing to do is a regression. It's repetitive and, frankly, a little boring. Whenever I had to do a regression, I would always think that there has got to be a better way of doing this...and there was.
Through Automation you could eliminate this task and now have more time available for your manual testers to do more fun things. This also allows for a quicker release from a staging environment to production. I mean, really, all you have to do is press a button and wait a few hours and you’re good. If you have the capability you can even set it to run automatically so you don’t even need to press a button. How easy can it get. I digress.
Back to the best automation tool. If this is your least favorite thing to do then I would recommend Selenium webdriver. I think it is the easiest, most versatile tool available to automate testing.
The webdriver has the capability of setting up testing across all the major browsers. It has easy to use commands. You can use it with almost any language. As far as tools go there is no better out there for this kind of task then Selenium Webdriver.

To learn more about Selenium check out these sites:
http://ideqa.blogspot.com/2016/07/my-first-selenium-ide-project.html  

If you have a specific tool you like to use leave it below in the comments and why you like to use that tool.

Monday, August 22, 2016

The Toaster And Testing

When I went to my interview for a manual testing position I was asked how would you test a toaster? This was by far the strangest thing I had ever heard. I thought about it for a little then I went through a process of what I would do to test the toaster.
When you ask someone to test a toaster, a car, or a video game the idea and process is the same, even though the the products are completely different. How you are able to work through this process decides whether you are a okay tester or a great tester.
I know what you are thinking, what does this have to do with automation testing. Well, when testing is in your title you are a tester. The process that you must go through even if you are a automation tester is roughly the same, obviously unless your company does it differently I always talk in the ideal.
So let us look at a toaster. Think about it for a second, how would you test a toaster? Let me give you some answers to questions you should have. How many buttons does it have? It has one button for cancel and it has a slider for low, medium, and high, in terms of length of time. It also has your typical pull down lever for the bread and it starts the timer.
So if we look at this we have to test the lowest, the middle and the highest to make sure those are working. We have to test the cancel and make the lever works. We also should make sure this works with common breads(white, wheat, bagel,…) as well as uncommon(pumpernickel, rye, other artisan breads,...). Alright so now we have a half baked plan. We need a legit plan.
To make the plan we need to think about the most efficient way of doing this. If it were me I would look at the timer first with white bread and the first time I pull down the lever for each timer level I would cancel. That would give me a good baseline. I would then start on the uncommon types and try to twist the timer lever in between low and medium and also medium and high. I would try and press cancel when the lever is not down. I would also try running the toaster without any bread in it or 1 piece in one slot and none in the other. There is also running the toaster with nothing in it, to see what happens. This is by no means everything, but it is a good chunk of what should be tested.

I am trying to show that for the tester there should be this process that goes on before testing, or at least in their mind while testing. Whether or not you consider yourself a tester, if you have tester or QA in your title you should be going through a similar process of testing things.

Monday, August 15, 2016

A Programmer's mind + a Tester’s mind = Automation Tester

What does it take to be a good automation tester? Is it the good diagnostic skills of a QA specialist or the brilliant step by step thinking mind of a programmer?
As I was thinking about this I was reminded of something I told someone else. “If you know what everyone is supposed to do you can do your job better.” I know it is lame to quote yourself and I was talking about soccer, so not really testing or even software. However, I really think I might have been onto something.
Let us dive into a testers mind. Constant self evaluations, constant thoughts of “no programmer is perfect”, and constant thoughts of “how do I effectively exploit this program so that it reveals to me it’s soft spots.”
These are the driving thoughts of a tester. They do not care what others think because if they did they would not be a good tester. They do not mind walking up to a programmer, no matter who it is, and telling them, in a tactful way, that you broke the program and you need to fix it. They are the ones that are responsible when there are bugs in the program that weren’t caught and they know it. They make sure no matter what that they do their absolute best to minimize the possibilities of major crashes.
Now let us take a look at the mind of a programmer. Logic. Really everything a programmer does is driven by the logical ‘next step’ in the sequence. Whether they are deciding what to do for dinner or how to plan party. Their decisions are driven by this logic.
This logic is why programmers are good at their job. They have the ability to think through a problem by breaking it down into step by step instructions on how to solve it. This is their ability. This is their ‘super power.’
Now their is the automation tester that must be the ‘no programmer is perfect’ thinker and must have the ‘step by step’ super power. How is this done? This is done by always thinking “there has to be a better way of doing this.” It is done by being the best of both worlds.

Really automation testers should be the smartest, or at least some of the smartest, at the company. If you can have effective automation testers your life will be easier and so will the life of everyone at the company.

Tuesday, August 9, 2016

How QA Can Help Engineers

When I first started QA I had this bug that I found that crashed the website I was testing. When I wrote the bug report on it, all I wrote was minimal steps of reproduction. Later an engineer came up to me to help me write a bug report as well as further diagnose this issue. Let me share with you the steps he shared with me.
First, write the bug report as if the person has never seen the program you are working with. In the example that I gave, it was such a minimal description of the steps to reproduce the bugs that later on, when asked about it, I had difficulty following my own steps. Another thing that helped me with this is that I started going through old bugs and trying to reproduce those with the steps give. For a lot of those bugs I could not follow the reproduction steps and the person who had reported it was no longer at the company. I had to close the bug as not reproducible, but in reality I had no idea and everyone I had asked had no idea.
Second he told me that pictures are your friends. If you can master the art of screenshots and .gifs your engineers will praise you. In this same example something that I did do was record my screen. This, in the end, is the reason I was able to rewrite the steps to reproduce again in such a way that other people were able to reproduce the issue and eventually resolve the bug. I have never reported a bug without at least one screenshot. When I do automation I always have it take a screenshot upon failure, so that I can at least see what the error is causing the program to do.
The final thing he told me was that make sure what environment it is in and what browser. The web based application I was testing needed to be tested in IE11, Edge, Safari, Firefox, and Chrome. There were times when I would find a bug that was specific to the browser. The same happened with OS, seemed to be more bugs around MacOS than Linux or Windows.
The bottom line or the takeaway from this is that you need to realize that everything you leave out of your bug report is another minute wasted. The reason why this would be a minute wasted is that the programmer would have to spend more time diagnosing the problem, or spending time talking to you. If they are talking to you they are not working on the problem therefore it would be money and time wasted.

Monday, August 8, 2016

Mobile Automation


For IOS and Android, the most common one is Appium. This can be used for both and is really handy because you can write the scripts in almost any programming language.
Like Selenium webdriver, Appium in and of itself is a ‘webdriver’ of sorts. So at the beginning of your test you create your appium driver.
This specific code for appium is java but you could adapt it to other languages.
Once you have it added to the test class. You can actually setup the things needed to run a automation test for IOS
So in this code snippet you can see that this is configuring to run on a iphone 6 in ios 9.3. For Android it's almost the same you just use a Android for both the deviceName and the platforVersion. In Android you have the cool option of installing the apk each time you run through a test. Whereas in IOS you don’t have the luxury.

Once you have the basics down you now can right a test.
This is a sample test from an Appium based Android test.

For more examples / help refer to these site.


Friday, August 5, 2016

Selenium Webdriver Basics

Selenium webdriver is a code based extremely versatile open source automation framework. It can be written in wide variety of languages and can be written for multiple browsers. If you have coding skills and a web based program, you want Selenium to do your automation testing.
One of the major things you need to know is how add the webdriver to your automation.  This website is a a great tutorial on junit in  eclipse. http://www.software-testing-tutorials-automation.com/2014/02/how-to-create-and-run-junit-test-suit.html. Something this site shows is the driver for Firefox. You can actually add any webdriver. So Chrome, IE, and Safari.

One thing a lot of programmers will do is to use Selenium IDE to make test cases and then export them as JUnit or some other language that they have written their Selenium tests in. You can do this by using making a Selenium IDE test then use the internal options of Selenium IDE to export the file as the language in which you like.


Please leave comments and questions below.

Thursday, August 4, 2016

Manual Testing, The Art That Cannot Be Lost

Manual testing that is very important in a company that is often time overlooked. As both a manual tester and someone who loves automation testing, I think it gives me a certain perspective on both. Manual testing is tiresome, costly and takes a very certain personality to be good at. Automation testing is costly, tiresome and let's face it you will miss things in automation. So from my description of both you see that each has it’s cons.

To start let us talk about cost. Each is costly, but each is costly in different ways. Manual testing is costly because for every development team of four there should be at least one manual tester. That means hiring more people, which is expensive. Automation testing cuts the cost of manpower by almost 400% you only need one automation tester for every 16 developers, but they is also a certain level of skill required for automation testing that requires you to pay the testers more. Both are costly just in there own way.

Then you look at tiresome. If you have ever stared at a screen all day, it is kind of boring. As well as you lose interest in what you are doing meaning your productivity goes down. That is downside to manual testing is that it is tiresome to go through the same product over and over again looking for different things. On the flip side to be an automation tester is tiresome because all they do all day is find things that haven’t been automated and write a test scenario for that particular case. So both are tiresome in different ways.

So in manual testing, it takes a very specific personality to be good at because you are the bearer of bad news and you will hardly ever get recognized for what you do. To programmers you seem like the bringer of death because all you tell them is that there is a major bug here and this part does not look right, or things don’t function like they are supposed to. This can be a hard way to live for a lot of people, hence why I say you need a very specific personality.

A person is not perfect. Therefore, a person will not write perfect code, they will miss something when testing, and they will miss something in automation testing. On that note I think when you miss something when automating testing it is a bigger deal. When you are writing a automation test all the manual testers now stop testing that because it is supposed to be tested. Well, because you are human, you will miss something in the automation therefore everyone will miss it. Whereas if you miss something in manual testing it will most likely get caught at most the next time around. I know that this is an opinion, but I feel that it is a pretty backed of conclusion.

In the End, there are costs, not just monetary, on either side of the equation. The absolute best thing is to have a combination of both. If you do that you greatly reduce the risk of missing something. When it is all said and done you want the best experience for your customers, and to do that you should implement exploratory/first look testing by manual testers which are then converted into automated tests. That way you get the most coverage of your product/website.

Wednesday, August 3, 2016

Overview of the Last 14 Days

In a matter of two weeks I have laid out the foundation to writing good Selenium IDE test cases and in turn test suites. To reiterate my first post on this, this is not all inclusive, but the principles here will hopefully help solve the majority of issues you run into. Three takeaways from all 13 posts that, if you remember nothing else, are that of Workarounds, Commands, and JavaScript.

First are workarounds. This is super important because, I think, it allows you as a person to become a better tester and programmer. If something doesn’t work the first time around you have to create a new way of doing it, which requires a relatively deeper understanding of the problem. As you do this regularly you will become more naturally able to think of multiple ways around a problem. This is important in testing because of the need of multiple scenarios to test and if you can think of multiple ways to get to a problem then you now have a another thing to test. This is by far the most important takeaway.

Second takeaway is that of commands. If you don’t know the commands you cannot work to the best of your ability. To me this is universal in anything dealing with technology, the better you know something the better you are at using it. Strive to know all your programming/ testing tools to the best of your ability and you will go far. Just to reiterate if you don’t know the commands you cannot truly understand if Selenium IDE is for you or not.

The third and last takeaway is that of JavaScript. I venture to say that anything you want to test you can test in Selenium IDE. Some would argue against me saying there are limitations. My counter argument is that with the JavaScript ability of Selenium IDE it allows to access to everything. It basically makes up for anything not built in to IDE already. Because of this, it is my third takeaway from everything I have written about IDE.

In short it is through knowledge of commands, JavaScript, and the tool itself that allows you to create necessary test cases for your browser testing.

For more information of Selenium IDE please check out Selenium’s website http://www.seleniumhq.org/projects/ide/ which will hopefully answer any questions you do have. Also, check out this other article I helped with https://www.lucidchart.com/techblog/2016/09/13/selenium-ide-the-good-the-bad-and-the-ugly/
Feel free, also, to leave questions and comments below and I will answer them.

Tuesday, August 2, 2016

Selenium IDE's Lack of Cross Browser Compatibility: Chrome Extension

One of the downsides to using Selenium IDE is that it a Firefox extension only. However, there are tools that have been created for other browsers.
Chromium is an extension to Chrome that is supposed to work very similarly to that of Selenium IDE. There are distinct differences to be aware of. First let me explain a little how it works.
First you need to download it as an extension to chrome. So, go to this link https://chrome.google.com/webstore/detail/chromium-browser-automati/jmbmjnojfkcohdpkpjmeeijckfbebbon?hl=en
This link should take you to Chromium in the google web store.


Download the extension. You will now see this


in the upper right of google chrome. This is how you will access Chromium to make and do your tests. When Chromium is open you will have a display box that looks like this


This has all of the necessary option for you to start recording your tests. If you have a complicated website then you might have some difficulty with recording on chromium, just like on Selenium IDE.  Unfortunately, unlike Selenium IDE it is much more difficult to manually enter the commands and the targets. It is possible but much less intuitive. In General it is not nearly as well done as Selenium IDE. The only advantage is it is a Chrome extension which is what the majority of websites are built for nowadays.
My conclusion on Chromium is that unless you are a die hard, throw up when hearing about other browsers Chrome fan, don’t use it. I think that it is just not well done.

If you have an comments or questions please leave them below.

Monday, August 1, 2016

Javascript in Selenium IDE

I have had a couple of questions about various javascript that would be useful in testing with Selenium IDE, others have just had question on how to execute the various javascript commands in IDE. So, here are a few that I have questions about the most, hopefully this helps.
First, is the alert button for a inner html of a specific element such as a paragraph or a link.
The first thing you have to do is store the inner html in a variable. For this you actually don’t need javascript but there is a command built in call storeText, imagine that. The target for this is the html element that has the text you wish to store, common is an input box. Next the value is the variable name to which you wish to save it.
Next is the Javascript, now off the bat you would think to use the runScript command with alert{${variableName}} in the target but the problem with this is that it just runs the javascript since the variable is not stored in javascript you have to use the command getEval which will run both the javascript code and evaluate the variable.
The only other piece of javascript I am going to talk about here is dealing with API’s. If you don’t know what these are you don’t need to worry about this. If you do know what this is and want to use these commands, a lot of this depends on the API functions that are built in your website.
So quick example is dealing with the canvas html object and this website has an API that allows you to find blocks on the canvas element.



If you have any questions or comments please leave them below.