Working as a freelancer has me on the hunt for a fitting role more often than when I was on a payroll. This arrangement also allows me to talk to many people about their needs and wants in the software testing arena, especially when it comes to automation of these tests. Over the last year, it became evident that the business awareness of the benefits of automating your functional tests grew tremendously. Good for me, more work! To make sure we all talk about the same thing when we have a conversation about test automation, here are a few definitions and itemisations with regards to my wonderful profession.
It is put in the form of a FAQ, so I can shamelessly re-use it in my LinkedIn profile.
What is a test?
A test is a series of steps taken against the target (or surrounding) system to mimic real-world and designed situations including asserts to ensure one-selves that the system is behaving as desired.
What is an automated test?
Like above, with the addition that all steps and asserts are executed by the computer in a script without human interference or interaction.
What is test automation?
Like above, with the addition that all pre-test activities, test execution and reporting is executed by the computer without any human interference or interaction. This as a whole can be then added to continuous integration solution such as Jenkins.
But wait, then what is a tester? Or testing?
A tester does testing, he will have a series of (sometimes pre-defined) steps that he executes by hand to mimic real world usage and visually check the result to see if it matches his expectations. Testing is slow, error-prone and pointless unless done as a final step by business users on a fully integrated environment using real-world data.
So you can do some test scripting, right?
Test scripting is taking the above tests and writing a single-layer script to execute the otherwise manual test or some part of it. As the test was originally designed to allow for the human to catch deviations outside of the strict steps, and these unscripted observations are not in the script, this form of test automation is often seen as low-coverage and brittle. Upside is that the tester is now able to run more tests than before, downside is that it still requires manual interaction either for setup, starting the tests or checking reporting. Personally, I stay away from test scripting as has low coverage and is not fully automated.
So who will do the test automation? That is a tester, right?
Honestly, writing your tests in such a way that they are robust and can be executed many times without manual interaction or monitoring is rather different from classic testing. Your tests will be smaller, more numerous and atomic in nature(checking just one thing), they will re-use steps written before and have navigation checks (for example if you are on the correct page) and waits.
In my experience, most of the automation is done in a framework allowing for one or two very specific interfaces, such as a web application and a Rest endpoint. For extension of the capabilities and embedding of the framework into the CI/CD setup, the help of a software engineer is needed.
We also need a software engineer?
Depending on the complexity of your systems you need a Software Engineer in Test paired with one or more Test Automation experts. The SE will setup the test framework, enable and enhance the interfaces to the system under test, ensure all starting conditions are met using automation, automate reporting and embed the tests into the CI/CD setup. Everything considered, the SEiT will build an application (using frameworks) specifically for the testing of a complex system.
So there we have it, the scale from tester to engineer and of course it is not a hard either/or and more a gradual scale. The key take from this scale is that a tester and a software engineer in test are very different jobs with very different skills. Asking your engineer to do manual testing would be the same as going grocery shopping with an excavator. It is possible, but there are vehicles much better suited for the task as there are tasks much better suited for an excavator.
Saturday, September 9, 2017
Tuesday, April 4, 2017
Manual testing is stealing from the future.
Often when arguing with testers about what to automate and what to test with manual scripts, my point of view is very simple. You will automate ALL the things. The tests, the builds, the testing of the tests on the builds, code quality tooling, the deployment further down the chain, the testing on the chain and if all is green after this firework, the deployment to production and turning it on for people to see. This is not some strange future alien technology thing, it is real and companies that are willing to invest are already doing this, keeping them in front of the hordes of competitors.
The most common arguments against doing full automation, always come down to the same things.
You cannot automate everything.
Yes, you can, but it might not be easy and it is very possible that your current testing workforce is simply not capable of pulling this off. Running manual tests is very tempting when you have been doing it for years, test automation might be scary, threatening or complex for those stuck in their ways. To these, I would like to say: either adapt by learning new skills or get out of the way please, you are holding up progress.
Test automation takes time to get set up.
Exactly, investment in time is needed, all the more reason to start today! Every day you wait is a day lost in the face of a deadline that is always around the corner.
Automating things is expensive / slow / we don't have the people for it.
Seriously, this is the best you can do? When you fire 10 manual testers and hire 2 test automation engineers who are worth their salt, you will have money left over. It is fast in execution and after setup can be repeated every build without added cost. And if you have problems recruiting people who can do this job, either train your workforce or offer higher compensation. We are talking software QA here, you want to cut corners on that and deliver buggy software? That is fine, but do not expect sympathy from anyone who did not want to work for ultra-low wages.
Our project has two weeks of regression testing and bi-monthly releases, there is no time to do any automation.
Change asks for investments. Either you do less manual testing and move people to the automation team or you spend money to speed up regression testing in the future.
And that last point is where the title comes from, all manual testing you do are taking time and people away from a better future. For every manual test executed, it could also have been automated. Once automated, the next run is without cost to your testers, so they can automate another and another and work away on that huge pile of technical QA debt you build up over the years.
When writing tests in an automation framework, your people become more trained in doing so, asking them to put the automation effort aside and do a quick manual test, or long manual test period, will hinder them in acquiring the skills to write testcases faster.
If you want to do test automation, accept these points:
Test automation is the future and the future has arrived. Please don't steal from your own future.
The most common arguments against doing full automation, always come down to the same things.
You cannot automate everything.
Yes, you can, but it might not be easy and it is very possible that your current testing workforce is simply not capable of pulling this off. Running manual tests is very tempting when you have been doing it for years, test automation might be scary, threatening or complex for those stuck in their ways. To these, I would like to say: either adapt by learning new skills or get out of the way please, you are holding up progress.
Test automation takes time to get set up.
Exactly, investment in time is needed, all the more reason to start today! Every day you wait is a day lost in the face of a deadline that is always around the corner.
Automating things is expensive / slow / we don't have the people for it.
Seriously, this is the best you can do? When you fire 10 manual testers and hire 2 test automation engineers who are worth their salt, you will have money left over. It is fast in execution and after setup can be repeated every build without added cost. And if you have problems recruiting people who can do this job, either train your workforce or offer higher compensation. We are talking software QA here, you want to cut corners on that and deliver buggy software? That is fine, but do not expect sympathy from anyone who did not want to work for ultra-low wages.
Our project has two weeks of regression testing and bi-monthly releases, there is no time to do any automation.
Change asks for investments. Either you do less manual testing and move people to the automation team or you spend money to speed up regression testing in the future.
And that last point is where the title comes from, all manual testing you do are taking time and people away from a better future. For every manual test executed, it could also have been automated. Once automated, the next run is without cost to your testers, so they can automate another and another and work away on that huge pile of technical QA debt you build up over the years.
When writing tests in an automation framework, your people become more trained in doing so, asking them to put the automation effort aside and do a quick manual test, or long manual test period, will hinder them in acquiring the skills to write testcases faster.
If you want to do test automation, accept these points:
- A test automation engineer has higher pay than a manual tester, test automation is hard. Not every one is suited for it.
- Test automation takes some time to get started, when running it can run a zillion time without added effort.
- Automated testcases are pieces of software that fit into the project, when the project delivers code, some tests will change and require maintenance.
Test automation is the future and the future has arrived. Please don't steal from your own future.
Monday, February 20, 2017
Introducing FitNesse, the testing framework
Talking about test automation often is a discussion about tooling, what tool is best for what purpose. Normally I do not take part in this, in my view a tool is a tool is a tool.
Knowledge on what tools are available and what each has to offer is a necessity, you need that to be able to fill your personal toolbox, but more important is the ability to pick up a tool an know how to use it reasonably well in a matter of days. Each place you work at has it's own demands on environment, the tools already in place and the personal preference of the people who make up the organisation. All this means that knowing all tools a bit, know a few well and have the ability to ramp up your skills fast is far more important than picking a tool and sticking with it.
Yet, this post is about the specific tool FitNesse because I think it is underestimated in the market for a variety of reasons, not in the last place because it is relatively unknown in my local market and it is user friendly. It took me a while to understand how user-friendliness can be detrimental to the popularity of any tool/framework but I think I have it figured out. Because FitNesse allows you to set up your tests in a way that you can explain to business users what you did and what your data points are in a way that is editable to them, there is some obscurity in the step to the actual (java) testing code. This is a good thing, the java code is not causing static in gaining the business trust that the tests are performing. On the other hand, those who are writing the tests like to be more on top of the code and view the format FitNesse offers as a hindrance. This is a bad thing, as it displays a misunderstanding of the framework FitNesse offers.
So let's go into that a bit more. According to the wikipedia page, FitNesse is "a webserver, a wiki and an automated testing tool for software". The rest of the page is technically true but somewhat confusing, it took me a while to figure it out myself. This is another reason FitNesse is under represented, the documentation and publications could use some work.
So here is my explanation of FitNesse to other testers and developers: "It is a stand-alone, no server needed, testing framework that allows you to write both very transparent test scripts in a table based format and set up data driven testing using javacode, whatever your preference." The use of the term framework is to emphasize you can go whatever direction you want when writing your java tests while the framework will take care of data input and output validation, reporting and integration with CI/CD tooling.
And there you go, FitNesse is a tabular view on either testdata and outcome predictions and with the right plugins, a tabular view on your testscripts.
To make the distinction more clear:
- FitNesse provides you with a framework to give a tabular view on your input/output tables, while your java-based testscript is somewhat hidden
OR
- FitNesse (with the right plugins) provides you with a wiki-based platform to give you transparent test scripting as well as input/output tables.
These two implementations are not exclusive, you can even mix and match in the same testscript if you desire to do so, but realize that whatever you do, you create a presentable test set that is build upon a mature framework.
In the first case, your testscripts require more than basic java knowledge and a thorough understanding of test automation, where it's strengths and weaknesses lie. In the second case, java is less important, some programming concepts are still required but this goes for the entirety of the test automation role.
Monday, November 14, 2016
On Agile, SCRUM and agility
These are interesting times for me, the transition from a management position where a team would do all the work and my role was mostly to shield them from the politics and planning problems, to a role where my production is determined by the amount of tests automated and the strength of my code.
After joining a new team a while back, I could not help but notice the wide variety of methods, tools and general ways of working across the several team members tasked with testing. While trying to understand what was going on and how to connect to the team effort in the best way possible, this variation struck me as a Bad Thing. It prevented me from following the determined path and fitting in, it obstructed adherence to the standards and it didn't allow me to meet expectations by replicating what others did. All because there was not one way to do things.
So the manager in me did the thing managers do, which is to create structure where there is none. I lobbied with my colleagues for some standards in ways of working, for detailed documentation on methods and for a singular environment to the benefit of all, to get clarity, conformation and unity. Most agreed with me that for newer folks and transparency's sake, guidelines and standards would be a Good Thing. There was one guy who pointed out the principle from the Agile Manifesto that says: "People and Products over Tools and Processes." as some sort of warning not to go overboard.
Somehow I ran into a wonderful 2014 blog post by Dave Thomas Time to Kill Agile in which he argues that the word Agile has been hijacked by consultants who have something to sell that is not software development and that will be more about their Tools and Processes than anything you want to achieve in the first place. Then the weekend started and I promised my fellow team members to think over the best way forward to reach the goal of uniformity and standards.
On Saturday evening (I know, I know), I send out the following email:
After joining a new team a while back, I could not help but notice the wide variety of methods, tools and general ways of working across the several team members tasked with testing. While trying to understand what was going on and how to connect to the team effort in the best way possible, this variation struck me as a Bad Thing. It prevented me from following the determined path and fitting in, it obstructed adherence to the standards and it didn't allow me to meet expectations by replicating what others did. All because there was not one way to do things.
So the manager in me did the thing managers do, which is to create structure where there is none. I lobbied with my colleagues for some standards in ways of working, for detailed documentation on methods and for a singular environment to the benefit of all, to get clarity, conformation and unity. Most agreed with me that for newer folks and transparency's sake, guidelines and standards would be a Good Thing. There was one guy who pointed out the principle from the Agile Manifesto that says: "People and Products over Tools and Processes." as some sort of warning not to go overboard.
Somehow I ran into a wonderful 2014 blog post by Dave Thomas Time to Kill Agile in which he argues that the word Agile has been hijacked by consultants who have something to sell that is not software development and that will be more about their Tools and Processes than anything you want to achieve in the first place. Then the weekend started and I promised my fellow team members to think over the best way forward to reach the goal of uniformity and standards.
On Saturday evening (I know, I know), I send out the following email:
Hi All,A few thoughts to begin with:Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a PlanThe above are the practices from the Agile Manifesto and we need it to keep things in perspective. From my background, I have a tendency to write everything down into minutiae and setting an approach that leaves little room for creativity and personal preferences from those who have to work with it. In earlier roles this was a boon, now it is a burden. I wish to apologize if I go back to what I know, the transition to real agility surprises me from time to time.What the practices tell us is that basically every team member can work the way he likes the most, instead of tying things down and stifle creativity.The difficulty starts when one is no longer operating in a vacuum, some things will have to be agreed upon and synchronized across the various members of this team. So my proposal is that we as the testers find some sort of common ground, agree on that and write it down in whatever wiki/forum/repo is best.These are the topics I think we should agree upon:· How to deal with old tests and old code· What toolset is preferred (what fits the client as well as the team)· How to set up new tests· what is the definition of done· What quality standards should tests meet before we go to production· But mostly: how will we work togetherLooking forward to have this conversation with you, afterwards I will put up the things we are willing to put down.
Thinking about the why of this made me realize that the deep core of the wish for standardization came from my own desire to have a benchmark to which I am measured. I want to do a Good Job so what are you guys doing, if I do that well, will you like me? And somehow, by trying to add value I was busy removing value in the form of creativity and freedom from people. It can be traced back to a long history of workplaces where freedom and creativity is shunned and conformity and standards are celebrated, as well as my personal need for approval, to do a good job.
The take away is of course that any person who complains about a lack of standards and guidelines in whatever software development team they join, are in the core people who want to do a good job and are uncertain on how to move forward OR are genuine in their desire to kill off freethinkers. The first group is easily helped out, the second only need to see your back as you walk out the door to a better place.
The take away is of course that any person who complains about a lack of standards and guidelines in whatever software development team they join, are in the core people who want to do a good job and are uncertain on how to move forward OR are genuine in their desire to kill off freethinkers. The first group is easily helped out, the second only need to see your back as you walk out the door to a better place.
Saturday, September 3, 2016
Keep an eye on the tooling
Over the last few months I have been really busy at work with a Java/Selenium/JUnit/FitNesse based framework and I think this is awesome and fun to do. On the other hand, it is an established framework and most of the work has been building new testcases with the available building blocks at hand, using the tooling and techniques already there.
Nothing wrong with that, it enables one to hone skills in a very specific department and some people love being a specialist.
Just that I am curious and now that I understand these workings, I want to know what else is in the market so I made a list of tools to learn. In an earlier post there were a few of these but I want to be inclusive and be sure most is covered. Also this is a reminder to myself that all tooling is relevant and I believe that of the things listed, an automation tester should at least know the basics, the internal architecture and how to set it up in your environment.
For the above goal I build separate projects, all using the code base I have for the MantisBT automated test suite. Whenever it is working to an extend that is satisfying to me, I upload to github so check there for examples. Also, after uploading a new blog post will appear here detailing my sources and how I went about setting everything up so hopefully someone else can use it to their benefit.
The latest list is here, this excludes anything I am already familiar with. Also I try to only list open source tools as I really like the philosophy behind it.
Test Frameworks
Geb, an automation framework using Groovy for headless browser testing
Cucumber, a framework for Behavior Driven Development Test Automation (that is a lot of capitalization). Uses Gherkin as a scripting language.
JBehave comes with a description similar to Cucumber. Cucumber has a higher market relevance so I'll look into that first.
Mockito is a framework for Test Driven Development and mocking in Java.
Spock / JUnit / TestNg are testframeworks for unittesting Java (and other) development. Looking into the differences and specific use for each is part of the fun.
Protractor, an AngularJS test framework build using Selenium libraries. This is not likely relevant anytime soon but good to have listed here.
Continuous Integration Tooling
Jenkins. The leading open source build automation server. Nuff said.
Bamboo. Not open source tool build by Atlassian who are best known for JIRA. There is a small demand in the market for this, just like there is for the HP ALM scripting language UTF. I am listing them here to show I did not forget about them but will most likely skip them both.
Gradle, an open source build automation tool with a company behind it that offers consulting and services.
Docker, an application container engine
Chef, infrastructure automation tooling
Puppet, also infrastructure automation tooling but more of an enterprise feel
SaltStack platform or Salt is a Python-based open-source configuration management software and remote execution engine.
Languages / Protocols
YAML, A straightforward machine parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and Python.
JSON (JavaScript Object Notation) is a lightweight data-interchange format.
Groovy is an object-oriented programming language for the Java platform.
PERL is a family of high-level, general-purpose, interpreted, dynamic programming languages
JavaScript is a high-level, dynamic, untyped, and interpreted programming language.
PHP is a server-side scripting language designed for web development but also used as a general-purpose programming language.
Ruby is a dynamic, open source programming language with a focus on simplicity and productivity.
Python is a widely used high-level, general-purpose, interpreted, dynamic programming language.
Test Tooling (aka Misc)
HTMLUnitDriver This is currently the fastest and most lightweight implementation of WebDriver. As the name suggests, this is based on HtmlUnit.
JMeter Graphical server performance testing tool, for both static and dynamic resources
SQuirreL SQL as an alternative for TOAD in talking to your SQL server.
SonarQube is an open source quality management platform, dedicated to continuously analyze and measure source code quality
Nothing wrong with that, it enables one to hone skills in a very specific department and some people love being a specialist.
Just that I am curious and now that I understand these workings, I want to know what else is in the market so I made a list of tools to learn. In an earlier post there were a few of these but I want to be inclusive and be sure most is covered. Also this is a reminder to myself that all tooling is relevant and I believe that of the things listed, an automation tester should at least know the basics, the internal architecture and how to set it up in your environment.
For the above goal I build separate projects, all using the code base I have for the MantisBT automated test suite. Whenever it is working to an extend that is satisfying to me, I upload to github so check there for examples. Also, after uploading a new blog post will appear here detailing my sources and how I went about setting everything up so hopefully someone else can use it to their benefit.
The latest list is here, this excludes anything I am already familiar with. Also I try to only list open source tools as I really like the philosophy behind it.
Test Frameworks
Geb, an automation framework using Groovy for headless browser testing
Cucumber, a framework for Behavior Driven Development Test Automation (that is a lot of capitalization). Uses Gherkin as a scripting language.
JBehave comes with a description similar to Cucumber. Cucumber has a higher market relevance so I'll look into that first.
Mockito is a framework for Test Driven Development and mocking in Java.
Spock / JUnit / TestNg are testframeworks for unittesting Java (and other) development. Looking into the differences and specific use for each is part of the fun.
Protractor, an AngularJS test framework build using Selenium libraries. This is not likely relevant anytime soon but good to have listed here.
Continuous Integration Tooling
Jenkins. The leading open source build automation server. Nuff said.
Bamboo. Not open source tool build by Atlassian who are best known for JIRA. There is a small demand in the market for this, just like there is for the HP ALM scripting language UTF. I am listing them here to show I did not forget about them but will most likely skip them both.
Gradle, an open source build automation tool with a company behind it that offers consulting and services.
Docker, an application container engine
Chef, infrastructure automation tooling
Puppet, also infrastructure automation tooling but more of an enterprise feel
SaltStack platform or Salt is a Python-based open-source configuration management software and remote execution engine.
Languages / Protocols
YAML, A straightforward machine parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and Python.
JSON (JavaScript Object Notation) is a lightweight data-interchange format.
Groovy is an object-oriented programming language for the Java platform.
PERL is a family of high-level, general-purpose, interpreted, dynamic programming languages
JavaScript is a high-level, dynamic, untyped, and interpreted programming language.
PHP is a server-side scripting language designed for web development but also used as a general-purpose programming language.
Ruby is a dynamic, open source programming language with a focus on simplicity and productivity.
Python is a widely used high-level, general-purpose, interpreted, dynamic programming language.
Test Tooling (aka Misc)
HTMLUnitDriver This is currently the fastest and most lightweight implementation of WebDriver. As the name suggests, this is based on HtmlUnit.
JMeter Graphical server performance testing tool, for both static and dynamic resources
SQuirreL SQL as an alternative for TOAD in talking to your SQL server.
SonarQube is an open source quality management platform, dedicated to continuously analyze and measure source code quality
Monday, April 11, 2016
Challenge yourself, get some experience as a bonus.
Having done more than a bit in the way of setting up a development environment and teaching yourself some java and selenium webdriver, it is time to get your hands dirty on more Java.
As it turns out, Selenium Webdriver itself is not so very difficult, it is the Java surrounding it that makes it hard to work on, to work with. Sometimes you need to check if something already exists and if not, create it. You will need to work with variables, with loops, arrays and all other kinds of seemingly basic stuff that you somehow still need to know.
In my last post, I explained how to gain the basic knowledge on Java and teach yourself all this. But now what? Having been doing other things / stuff for a decade means I am nowhere good enough to consider myself a valuable part of a team of developers after three months of self-study on java. I need practice, it needs to be somewhat of a learning curve and it needs to be somewhat anonymous so nobody can laugh at my pathetic attempts on coding.
Lucky for us, there are a ton of websites to aid us and I want to dive a bit deeper into a few of them. In the java post I already mentioned a few and I'll repeat them here:
Kattis. This is a collection of coding challenges, going from not so complex to really frigging hard. You gain points which is fun as you can pass others. I am currently hovering around rank 1000 and my code is getting sloppier every time I try something. This is most often because I have no idea how to approach a problem which can be caused by having a lack of knowledge on Java. You can use other languages as well, the interface is very useful and they have a ton of problems you can solve. Go here if you want to race others for imaginary internet points.
Hackerrank is similar to Kattis in some ways, such as points and ranks but with a few very nice additions and some things lacking. The idea is similar, but it is split up in domains that allow you to earn points each instead of one problem to solve in the language of your choice. Nice if you want to focus on other things than just math problems and Kattis has many of those.
Project Euler is very obviously not designed but it is well written and has another 545 problems you can work on.
Topcoder seems nice but has a hard time actually offering beginner challenges. This is nice if you have more experience and want to know how good you are compared to others.
These are websites that allow you to upload your solution, some snippet of code, after which you are a bit better at writing short bits of code for a very specific purpose.
Looking at the goal of all this is to land a job doing something we like to do and doing it for money in such a way that we still like what we are doing. A job you enjoy will leave you energized at the end of the day which in turn will make you happier which in turn will make your family happier which will make this world a better place. Just try to enjoy your job, if not for yourself, do it for the puppies.
To get that job that we expect to enjoy we need to prove to a prospective employers that:
The best way to gain experience is write actual code for an actual project and there are several ways to go at that. Let's get the first one out of the way:
Because we are learning Java with test automation as the goal, it should not be to hard to start somewhere. In fact, I am building a testset for an open source project myself, you can find the repo here on Github. It needs work, feel free to contribute :-)
As it turns out, Selenium Webdriver itself is not so very difficult, it is the Java surrounding it that makes it hard to work on, to work with. Sometimes you need to check if something already exists and if not, create it. You will need to work with variables, with loops, arrays and all other kinds of seemingly basic stuff that you somehow still need to know.
In my last post, I explained how to gain the basic knowledge on Java and teach yourself all this. But now what? Having been doing other things / stuff for a decade means I am nowhere good enough to consider myself a valuable part of a team of developers after three months of self-study on java. I need practice, it needs to be somewhat of a learning curve and it needs to be somewhat anonymous so nobody can laugh at my pathetic attempts on coding.
Lucky for us, there are a ton of websites to aid us and I want to dive a bit deeper into a few of them. In the java post I already mentioned a few and I'll repeat them here:
Kattis. This is a collection of coding challenges, going from not so complex to really frigging hard. You gain points which is fun as you can pass others. I am currently hovering around rank 1000 and my code is getting sloppier every time I try something. This is most often because I have no idea how to approach a problem which can be caused by having a lack of knowledge on Java. You can use other languages as well, the interface is very useful and they have a ton of problems you can solve. Go here if you want to race others for imaginary internet points.
Hackerrank is similar to Kattis in some ways, such as points and ranks but with a few very nice additions and some things lacking. The idea is similar, but it is split up in domains that allow you to earn points each instead of one problem to solve in the language of your choice. Nice if you want to focus on other things than just math problems and Kattis has many of those.
Project Euler is very obviously not designed but it is well written and has another 545 problems you can work on.
Topcoder seems nice but has a hard time actually offering beginner challenges. This is nice if you have more experience and want to know how good you are compared to others.
These are websites that allow you to upload your solution, some snippet of code, after which you are a bit better at writing short bits of code for a very specific purpose.
Looking at the goal of all this is to land a job doing something we like to do and doing it for money in such a way that we still like what we are doing. A job you enjoy will leave you energized at the end of the day which in turn will make you happier which in turn will make your family happier which will make this world a better place. Just try to enjoy your job, if not for yourself, do it for the puppies.
To get that job that we expect to enjoy we need to prove to a prospective employers that:
- We know what we are talking about
- We can work as a developer in a team
- We have some real experience
The best way to gain experience is write actual code for an actual project and there are several ways to go at that. Let's get the first one out of the way:
- Land a job as a very junior developer at a company willing to hire a mid career guy with no experience. Yeah, not likely unless you are happy to work for free which is fine if you have a ton of savings and no family to support.
- Do all the challenges mentioned above and open up your repo on Github. This will help a bit but you still have to prove you can work in a dev team writing useful software.
- Contribute to open source projects. There are guides here and here and a website called CodeTriage here.
Because we are learning Java with test automation as the goal, it should not be to hard to start somewhere. In fact, I am building a testset for an open source project myself, you can find the repo here on Github. It needs work, feel free to contribute :-)
Friday, April 8, 2016
Selenium, finally some progress
After getting the hang of Java and being able to produce some workable code, I wanted to go ahead and automate some tests. After all, 6 weeks had passed in my new career adventure and not a single testcase had been automated. It was about time!
With some help of smart googling, I ran into this blog and training series helping me use Selenium, JUnit and IntelliJ, the all in one package I was looking for. Really useful as it will teach you how to use Maven within IntelliJ, what the JUnit framework can do for you and after this setup how to build some basic Selenium Scripts. He changed the layout since I used it and moving from one post to the next became weird, so let me build it out for you here.
Newbie friendly guilde to using Selenium in IntelliJ.
Part 1: Install Maven and do some basic setup.
Part 2: Install IntelliJ
Part 3: Get Testing
These are the basics and I don't want to steal this guys pageviews so go here for a full overview. Posts I can recommend are:
Firebug and Firepath, very useful with Selenium. These will allow you to find out what that element you are trying to locate actually is called and how to refer to it.
Using Assertions. It is nice you can click a button but is the result what you expect it to be?
His series on waits is useful knowledge as well. In fact, I would recommend you check out what classes and methods (you remember this from Java, right?) are being offered in the greater Selenium package. To do some straightforward reading on this you go here, it took me some searching as for some reason it is not that clear and open in the Seleniumhq.org documentation. Things are a bit scattered as technical documentation has a tendency to do but realize the following:
With Selenium Webdriver you can do whatever a user can do in a browser screen in terms of clicks, movements, scrolling, typing and whatever you can think of. Even better, this can be done in multiple browsers, across platform and with a wide variety of recordings such as screenshots, textfiles and reports.
The commands allow you to do all that, you just will have to figure out how to tell Selenium to do exactly what you want in the browser. This sounds like quite some effort to get the hang of and it is so I am using as many things I can find to make my life easier.
The one I like best is using the Selenium IDE to record and then export to Webdriver/Java/JUnit. Some people, maybe even most people, would consider this cheating but allow me to explain.
The Firefox addon SeleniumIDE which we installed a few posts back allows me to record in any webpage what I click, where I type and so on. There is a certain order to things and it can be found in the Options screen under the tab Location Builders, like this:
This lists what it will pick first, what second and so on. Basically, if it cannot find a locator of a certain type for the object you click, it will move one down and in the end the Xpath remains which will always work but is a real pain to maintain.
So what I do is the following.
Open website and open Selenium IDE addon.
Click record on the Selenium IDE window. Do not forget this, else you have to redo.
Record whatever you are doing.
Your window will now look like this:
There are some actions that I now want to extract from this to use in my Java/Selenium Webdriver/JUnit test scripting and here is how to do that:
Yes, we can actually export that to the exact setup we are using, so let's go and do just that, put it in a nice place where you can find it such as the desktop and do not treat it as anything as a super temporary file.
Now open Notepad++ and navigate to the super-temporary-file.java on your desktop. There will be a ton of code that you really don't care about in the grand scheme of your laziness so we ignore that and look up the selection bit, highlighted here:
Look at that, you copy/paste this to your java code in IntelliJ or Eclipse or whatever you are using and edit it how you want it to behave but it saves so much time in trying to figure out the most optimal way to pick an element. Also screw that the picture is to wide, we need all that booty to show a point!
Hoping I angered many purists and made a lot of lazy people happy, I will move to Git next time as Git is a good thing to have, know and use.
With some help of smart googling, I ran into this blog and training series helping me use Selenium, JUnit and IntelliJ, the all in one package I was looking for. Really useful as it will teach you how to use Maven within IntelliJ, what the JUnit framework can do for you and after this setup how to build some basic Selenium Scripts. He changed the layout since I used it and moving from one post to the next became weird, so let me build it out for you here.
Newbie friendly guilde to using Selenium in IntelliJ.
Part 1: Install Maven and do some basic setup.
Part 2: Install IntelliJ
Part 3: Get Testing
These are the basics and I don't want to steal this guys pageviews so go here for a full overview. Posts I can recommend are:
Firebug and Firepath, very useful with Selenium. These will allow you to find out what that element you are trying to locate actually is called and how to refer to it.
Using Assertions. It is nice you can click a button but is the result what you expect it to be?
His series on waits is useful knowledge as well. In fact, I would recommend you check out what classes and methods (you remember this from Java, right?) are being offered in the greater Selenium package. To do some straightforward reading on this you go here, it took me some searching as for some reason it is not that clear and open in the Seleniumhq.org documentation. Things are a bit scattered as technical documentation has a tendency to do but realize the following:
With Selenium Webdriver you can do whatever a user can do in a browser screen in terms of clicks, movements, scrolling, typing and whatever you can think of. Even better, this can be done in multiple browsers, across platform and with a wide variety of recordings such as screenshots, textfiles and reports.
The commands allow you to do all that, you just will have to figure out how to tell Selenium to do exactly what you want in the browser. This sounds like quite some effort to get the hang of and it is so I am using as many things I can find to make my life easier.
The one I like best is using the Selenium IDE to record and then export to Webdriver/Java/JUnit. Some people, maybe even most people, would consider this cheating but allow me to explain.
The Firefox addon SeleniumIDE which we installed a few posts back allows me to record in any webpage what I click, where I type and so on. There is a certain order to things and it can be found in the Options screen under the tab Location Builders, like this:
This lists what it will pick first, what second and so on. Basically, if it cannot find a locator of a certain type for the object you click, it will move one down and in the end the Xpath remains which will always work but is a real pain to maintain.
So what I do is the following.
Open website and open Selenium IDE addon.
Click record on the Selenium IDE window. Do not forget this, else you have to redo.
Record whatever you are doing.
Your window will now look like this:
There are some actions that I now want to extract from this to use in my Java/Selenium Webdriver/JUnit test scripting and here is how to do that:
Yes, we can actually export that to the exact setup we are using, so let's go and do just that, put it in a nice place where you can find it such as the desktop and do not treat it as anything as a super temporary file.
Now open Notepad++ and navigate to the super-temporary-file.java on your desktop. There will be a ton of code that you really don't care about in the grand scheme of your laziness so we ignore that and look up the selection bit, highlighted here:
Look at that, you copy/paste this to your java code in IntelliJ or Eclipse or whatever you are using and edit it how you want it to behave but it saves so much time in trying to figure out the most optimal way to pick an element. Also screw that the picture is to wide, we need all that booty to show a point!
Hoping I angered many purists and made a lot of lazy people happy, I will move to Git next time as Git is a good thing to have, know and use.
Subscribe to:
Posts (Atom)