If you are an automation tester, you will need to write a lot of code to cover the required test scenarios and test cases. Your code base will grow and grow, but some of the code will not be really needed and thorough code reviews should be done, to avoid unnecessary code.
Starting an automation effort for a project that has no automation whatsoever is always a fun and challenging experience. But you need to clearly understand what the goal and specifics of your project are, to achieve success in the automation effort. Before jumping into writing the first automated tests, you need to gather some information, perform some analysis, and build a Proof of Concept, to make sure you picked automation tools that really work on your product. Continue reading Create a Proof of Concept before going full throttle with your automation→
Writing automated tests means writing code. It means going through processes that regular code goes through. Like code review, and refactoring. I see a lot of hesitation when it comes to refactoring one’s own code, possibly because we feel that if our code needs correction, we did a crappy job writing it the first time. But that is not the case, and refactoring should be seen as a good thing. It is meant for changing something from good to even better. Continue reading Refactoring is allowed→
Code review, although very important and frequent in the software development world, is not as frequent in the automation testing world. Normally, it would be part of the whole process: someone writes code, reviews it, makes it available to the rest of the team, they review it, and if changes are needed they will be made, and the improved code will now be available back to the team. This helps in having better code and having awareness inside the team on what is being implemented.
When automated test are running, they are either running on your own machine (when you write them or run them to check something), or in your CI.
When you run the test on your machine, if there are failures, it might be easy for you to look at what is running (if you have some visual tests, that interact with either browsers or apps on your machine). You can just rerun a failed test and visually inspect for failure reasons. But, if tests are running on a CI machine, visual inspection is either very difficult or even impossible. You might not have access to connect to that machine, or to see how tests are being run. Continue reading Test design: write tests with proper console output to easily identify failure reasons→
Coding standards are something both automating testers and developers should adhere to. Pretty obvious right? Maybe not that obvious might be some of the rules you should follow when writing the code for your tests. Checkstyle is here to help in standardizing your code, so that you can get an early feedback regarding code improvements (earlier than the code review step anyway). It allows you to define a set of basic coding rules that must be followed in your project, and it gives you the opportunity to make your builds fail if someone breaks those rules. This post addresses using checkstyle from a Maven project, by means of the dedicated Maven plugin that you need to declare in your project. Continue reading Using Maven checkstyle in your project to help adhere to coding standards→
How many times does this happen: you start a new iteration/sprint; you give estimates; you realize that the testing work will not be complete in the sprint for certain features?
While analyzing the work that needs to be done in a sprint you tend to think in a sequential manner: developers write the code –> only once the code is complete will the testing begin –> the developers are done with their work within the sprint, the testers are not. Strategies, workarounds and intense thought processing are used to determine how to somehow fit the testing work in the sprint, to not allow it to flow over into the next sprint. Is there an alternative? Yes.
