The first step is the hardest. Reading this article might actually be that first move you need to make. Taking the time to document how to do it, and where to start, is probably just as difficult. Even though I was pretty excited to learn, I was worried about properly understanding or learning fast enough on my own. But it’s actually not likely to fail. Once I took some time to search for the “minimum requirements” of automated testing, it seemed like an attainable goal.
Starting as a QA can be confusing. There are a lot of people out there who opted for this job. Testers are pretty easy to find for a company and I’m one of them. Just as I did before, you’ve probably already asked yourself “How could I make a difference? How can I prove myself? How on Earth could I stand out from all the others?” Well, the answer is bluntly simple: the Internet and your computer. The secret to being a great QA is actually well known and attainable: learn automated testing. Nowadays, an IT career is a lot more solid when supported by something like automated tests, and software companies are desperately hunting for testers that can write them.
Both you and I know the secret already. This is the story of how I went from “I have no idea about where to start with automated tests” to actually writing comprehensive, functional and really helpful ones.
When I first realised that the project I am working on in Innobyte needs something more than just traditional, manual testing, I gave serious thought to learning test automation. I started with the most popular ones: Ruby and Watir. It took me a while to setup. Until I ended up writing my first test, I realised I had spent a few nights tinkering with it. Being inexperienced with test automation at that time, I felt like I had to pick Ruby. So I continued learning. Little did I know that I was going to end up with a totally different framework.
Since we needed to test the project based on customer behaviour, we decided to analyse two good BDD (behaviour driven development) testing frameworks: Behat and Codeception. Behat seemed a bit complicated for my shoes, and it would have needed a lot of help from the developers to implement. Codeception seemed a lot friendlier and easier to understand. Therefore, after taking a detailed look at it and analysing it with the team, we decided to pick the latter. In retrospect, I think it was the best decision, even if Ruby had been one of the candidates.
I honestly think that Codeception is the answer when doing automatic testing. Why? Here are 10 of the many reasons, which I am mostly giving you from my own perspective and experience:
- It’s a simple setup;
- The tests are easy to write and understand;
- There’s almost no involvement from the developers;
- You have the opportunity to insert PHP in your tests, if you need it;
- It’s very customizable and it works well with Selenium WebDriver;
- It’s suitable for any web project;
- Developers can use it to write unit tests;
- It has tons of modules you can use to make the test process more efficient (special modules for Symfony2, database modules, Laravel4 module, Facebook testing modules, Webdriver etc. – Find all of the modules on www.codeception.com);
- The output is easily readable and the test results can be saved in many formats;
- It offers many options through its modules, like testing e-mail content and restoring the DB after each test.
Alright now, don’t panic, it’s not as difficult as it sounds. And it is actually as easy to do as it is to say. Here’s a sample of a line of code: $I->click(“Submit”); . It doesn’t look that bad, right? You shouldn’t have to know anything but the regular computer usage to be able to start writing automated tests. This framework offers just that.
And we’ll talk more about it!
If you want to know how simple it is to setup Codeception, stay tuned! The next article will be up next Tuesday and it is on Installing and configuring Codeception for Windows.
You can also subscribe to our weekly newsletter on Codeception here.
Hi there,
I wanted to say that this statement ” The secret to being a great QA is actually well known and attainable: learn automated testing” is not entirely true. The secret to being a great QA is actually all in the details and it is not mandatory to actually learn automation testing. Every company pushes for automation and require more and more knowledge of programming and scripting. There are plenty of testimonials out there that state clearly the fact that a manual tester (although i hate that term: manual) are not actually good at writing code, and unless the “automation” in that firm revolves around record and play it’s not the best idea to push a manual tester to learn automation. If it were such a good idea it would have been pushed from the beginning.
Here’s an example of such a testimonial:
http://visible-quality.blogspot.ro/2014/08/making-tester-learn-coding-when-not.html
A good read when it comes to automation is this as well:
http://gojko.net/2009/12/07/improving-testing-practices-at-google/
The biggest problems with automation are:
1. avoid repeating yourself – many automation testers don’t know exactly what that means
2. avoid spaghetti code/brittle code – without proper experience in automation this is unavoidable unless properly supervised by a developer
3. writing code according to standards and best practices – most of the testers that develop automation tests are self taught or learn by trial and error and forget about such things therefore leading to poor quality automation scripts.
4. write automation scripts on the platform’s programming language – there are numerous QA automation engineers out there that write java automation scripts for a php platform, or ruby scripts for a C# platform and so on. Best approach to this is always write the automation scripts on the platform’s language, not something else.
Codeception is a very good framework, for PHP although limited in some areas. The good thing about it is that it is maintained and developed constantly by the community and davert and also because it is supported by some big names.
Keep up the good work 🙂
Thank you for reading my article!
Automated testing is not mandatory knowledge, we can all agree on that. Then again, isn’t it highly sought after? Isn’t it a skill that most employers want a QA to have? This article is not about forcing people into learning or applying it. It’s about encouragement and about making it clear that it’s actually not so complicated to learn. It doesn’t require programming knowledge.
Indeed, you can end up writing brittle code, but you can’t write brittle code if you haven’t written anything. Polishing your code comes after you understand what automated testing is about.
Most testers don’t have a “role model” in QA – they can’t just NOT learn automated tests because of the fear of writing brittle code or because they feel unprepared. The whole point is to start writing something. After that, we can worry about brittleness and code quality.
This article reaches out to all testers that never got around to finding out what automated tests are all about and just need a starting point.
Hi.
Question for Alexandra, at innobyte in qa department does it use it condeception for automation testing, for the end to end acceptance tests? Cause integration or/and unit test is a developer job.
I believe, before automate testing or do code, it should bring together a tester, a developer, a business analyst also known as the three amigos and the product owner and produce business behaviour specification that are align with the business goals.
A note about Behat: is a tool for behaviour driven development at the user story level. The guy who created it, initially as a clone of cucumber for php, firstly thinking of it just as tool for doing acceptance end to end testing, but now, these days, it defines as behaviour driven tool, firstly to do domain driven design or in testing terms integrations tests of code that not exist yet, then using the other bdd tool phpspec at unit level to design the behaviour of the objects/classes that suports scenarios in features files to get green and pass. And only some scenarios that are critical are then tested as end to end.
This way after using bdd to do ddd, also achieving the testing pyramid: at the bottom of the pyramid being the unit tests, at the middle the integration tests, and in the top and the fewest of them all, end to end acceptance testing.
Best regards,
Silviu
http://twitter.com/silviuctinvoicu
Hello, Silviu!
As I have mentioned in the article, I agree to the fact that the developers should write the unit tests. We would not expect a QA to do the job instead. To answer your question, we, at Innobyte, have a balanced test system, combining both manual and automated testing to obtain the best time/effort ratio.
Automated testing is implemented, though acceptance testing & Codeception, for the porpouse of eliminating redundancy and leaving room to the well known QA creativity instead. The automated tests pick up whatever critical errors remain after th developers test their features locally. The more detailed, end-to-end testing is performed manually at this point. We are looking forward towards covering more and more areas though :).
The job of a QA is never solitary. The team must collaborate to release the finest product. Before starting any kind of test, you should first get to know the team, get to know the project and of course, learn what is best for it.
Have a nice day!
Pingback: Installing and configuring Codeception for Windows
Pingback: Automated tests for your software development projects
Hello Alexandra,
I’m glad to know I’m not the only one who was asking himself those questions. Thank you for writing several articles about Codeception !
Good work.
Victor.
Hi Alexandra,
Nice posting on codeception. I loved it.
I started learning codeception.
Could you help me with cutomising report.html in codeception acceptance testing.
And instead of acceptancesuite.yml file, Can I read this configuration from a excel file.?
Thanks,
Bhavya
Hello Bhavya!
I am glad that you enjoyed my article. I wish you the best of luck in this learning process!
Unfortunately, Codeception doesn’t allow modifications to the way in which the reports are generated. Here’s more information on the issue: http://github.com/Codeception/Codeception/issues/400
I don’t think you can import data from an excel file into the acceptance.suite.yml config. What kind of data would you like to import? There might be a better approach we could analyze.
Best regards,
Alexandra