TJ Maher, a tester, Techbeacon contributor, and Ministry of Testing Boston Organizer created his blog for manual testers looking to make the switch to automation. Browse his table of contents to easily navigate or check out posts from various categories ranging from “beginner” to “Appium” to “code examples” and more!
I remember being so impressed when I first heard about Test Automation University, the latest project by Angie Jones. A free online university, sponsored by Applitools, where subject matter experts in the software testing field created tutorials? Yes, please! Finding up-to-date information on automated testing can be an exercise in frustration.
Imagine my surprise when a few weeks after TAU was launched, Angie Jones got in touch with me back in February: Did I want to create a course for Test Automation University?
I decided my topic would be on Capybara, the Selenium WebDriver wrapper I used to put together the UI Automation framework at work last year. It took a lot of time, effort, and sleepless nights, but after a month of effort, I was able to beat the deadline.
Whenever I join a new team, my first task is fostering and nurturing a good working relationship with the developers. Why? If there is good chemistry between testers and developers, the quality of work increases as the quality of communication increases.
The relationship between tester and developer shouldn’t be one of artist and art critic. Rather, it should be one between writer and copy-editor, each contributing to the quality of the product.
Developing a good working relationship with developers can be tricky. Here are five tips for nurturing and developing relationships with your developer teammates.
Tip #1: Don’t Let Bad Past Experiences Get In The Way Of The PresentIt can be tough being a software tester. Testers can be blamed for:
… finding too many bugs … for reporting too many bugs … for making the team look bad … for making the product look bad
Speaking for myself, I’ve seen managers foster an “us vs them” mentality between devs and testers, claiming that this heated rivalry is a good thing, keeping both camps on their toes.
I’ve had test managers insist that testers should only communicate with the developers through bug reports, and that I only have two jobs: Find bugs, and don’t bother the developers.
And I’ve had development managers dismiss me as “only a tester”.
Even though most of these experiences happened early on in my career, when I am having a bad days or when I am under severe stress, these bad experiences of mine can bubble up while I am interacting with developers. The longer your career goes on in this field, the more the baggage can accrue.
In spite of all of that, it is important that these past bad experiences do not interfere when working with present or future developers.
How can a tester cope?
Vent with a friend -- outside of work -- if you need to. Unpack your baggage. Trade war stories.
Is a job just too difficult to deal with? Finding a new workplace may help.
Find a way to deal with these past comments that may haunt you. Do whatever it takes so that the next time you start working with your development team, you can do so with a clear mind.
Tip #2: Participate in the Initial Planning Sessions When the initial work on the project is being scoped out, don’t be a bystander or a spectator when a new feature of the product is being planned. Allow your voice and your experience as a tester to be heard.
As the new features are first being introduced to your team, work side-by-side with the developers, brainstorming and reviewing each feature story by story.
Work together to see if the requirements are readable, understandable, clear, and concise. As the developers go back and forth trying to hash out if there is enough information there to build the new feature, work with the developers and business analysts totry to figure out if there are enough metrics listed to test.
Examples Of Metrics That Could Be Used:
… Is this feature testable? … How do you know the feature passes? What does a failure look like? … What is a critical requirement? What is simply “nice to have”? … What inputs are acceptable? … What is not acceptable?
If the feature has a UI segment, are their sample screenshots of how the product is supposed to look and behave? Screenshots, mock-up, and wire mocks are extremely helpful in creating conversations around functionality, usability, and testability while discussing requirements.
If your team is using Agile, work out how complex a story may be, comparing one story to another, assigning various points to the story. Trying to assign story points spurs a healthy and constructive debate, with testers right there in the thick of it, listening, taking everything in, and contributing the conversation.
Will a feature take a lot of time to test? If testers don’t speak up and say that they need to budget more time into developing and testing this feature, they are going to find themselves either blowing deadlines or working a lot of nights and weekends in their immediate future.
If you are using Agile, remember that you are trying to run at a healthy sprint. It is not supposed to be a death march.
Developing a good working relationship is more that just grabbing lunch with the developer you are working with to build and test the feature(though that works). Getting to know the developer as not just a co-worker but also as a person creates a better environment for communication and collaboration.
Tip #3: Dive Deep With Developers Before Your Testing Starts The developer and the tester are two sides to the same coin. The developer is focused on drafting and building the product. My main focus as a tester is how a customer will operate the product.
The developer focus is on creating the product according to the ever changing specs.
A tester’s focus is to do risk analysis as the product is being changed and updated.
Developers aren’t opponents. We are teammates. We’re partners.
If there is a new feature being developed and you are unsure how the new feature will work, reach out to the developers. Work with them to figure out things such as...
… How data travels from the UI to the API to the database … Checking if new fields need to be created in the database. … Checking if data need to be processed before it gets used by the API … Is the code being held together with paper clips, rubber bands and duct tape? … Is there a risk that things related to this feature might break as things are being built or code is being cleaned up and refactored?
These concerns need to be addressed by both developer and tester. Work with the developers, business analysts, and user experience. Be the sounding board.
Tip #4: Enjoy Each Other’s Testing Perspectives
Developers and testers have different perspectives when it comes to viewing the software product under construction.
Developers see the product from the bottom up, sometimes seeing the user interface a thin plastic veneer covering the machinery of the product.
Testers tend to see the product from the top down, starting with how the customer uses the product.
This difference in perspective extends to the subject of testing.
Developers may think of testing at a code level, with a focus on unit and integration tests.
Testers may focus more on functional tests, examining the product as a whole.
By sharing each other’s unique perspective you help each other get better in your own profession.
When testers and the entire development team work together, they become more interdisciplinary. Ask the business analyst about how the requirements were constructed. Ask the user experience people how they determined what the product should look like. Ask the developer to give a code walkthrough while the feature is being built.
See if you can set up pair testing with the developer. You would get to know more of how the product is built and the developer will get more exposure to how to test this creation you are both shaping.
Tip #5: Under Times Of Stress: Try To Be Kind It is very easy to get stressed out in the software industry. Deadlines are always looming. Things move so fast. There is always a new tool or technology to learn every few years. Requirements can changes quicker than you can keep up. Things can fall apart. It is easy to get overwhelmed. These stressful times are why we have done all this work, for these stressful moments.
Even if testers work side-by-side with the rest of the development team in planning how to develop and test a feature, communication can still short circuit. The bug you found might not be a bug at all:
The requirements may have changed, and a conversation or midnight email happened between product owner and developer that you are not privy to.
The developer might have realized last minute that the product does not have the structure to support all of the new requirements. Things were scaled back.
A bug was already found, and the designer, developer, and product owner had a meeting and decided that they could live with the bug, and they just haven’t had time to communicate that to you yet.
It may not be a bug at all. It could be a not-yet-documented feature.
When you find bugs in the code... try to be kind. Don’t act as if the bug represents a failing of their work ethic. In the software industry, we are doing so much with so little time, it is easy for things to get missed. Establishing a good rapport with each member of the team, doing a deep dive on technical aspects of the feature, soliciting feedback in testplan creation, and pair testing with the team can all help establish good collaboration amongst the team.
The most important part to remember? Under times of stress: Try to be kind.
Friendly LocatorsAnother new feature I was impressed by? Simon mentioned that they are planning on coming up with what they are calling "Friendly Locators": When searching for elements, you will be able to use keywords such as Near, above, below, left of, right of.
Docker FunctionalitySelenium Grid is going to be modernized, so it can be scalable and be run using Docker. Yes, you can do that now, Simon mentioned, using Zalenium or Selenoid, but this will be built in.
Simon Broadcasted the Webinar From his Car
Congratulations on being a new dad! It's hard getting the balance right :) What no-one saw was @pinmav quietly doing her own work in the other seat of the car. I'd not be able to do half the things I do without her. She's amazing! pic.twitter.com/hI7QYxCY8Y
Importing API data into Postman by capturing information seen in Google Developer Tools -> Network by the "Copy as cURL" command. Importing the cURL commands into Postman by "Paste as Raw Text".
Practicing API testing with Mark Winteringham's Restful-Booker API Playground which has some bugs built into it you can try to find.
Setting up Get, Post, Put and Patch requests using the Restful Booking API Docs, setting up a token to get authorization.
Amber walks you through setting up the NodeJS Restful-Booker app locally so we have more opportunities to set up tests in Postman. Amber has a companion project stored in GitHub, with content such as the RestfulBooker Postman Collection all set up.
What I loved most of all? Amber showcases her POISED mnemonic to describe API Testing: Parameters, Output, Interop, Security, Errors and Data.
Parameters: What happens if you replace, say, a first name field with an empty field, nulls, spaces? Does the API catch errors as you think they should? Do they match the spec? If you leave off a required field, does it throw the expected error? What happens if you insert strings for booleans or numbers? See how the system reacts, and see if it throws 500 errors
Output: What kind of HTTP Status Codes, Error Messages, or Logging is thrown? Do you get the proper 200 OK status when something happens? Or do you get weird codes such as 201? If you choose to get reports, setting Headings to "Accept" from "application/xml" or "application/json", does that feature work for both types? Do your logs have extra information if there are 500 errors?
Interop: Test the Interoperability between services, that systems can get the information that they need. What happens if YYYY-MM-DD is changed from the United States MM-DD-YYYY and the European DD-MM-YYYY? When getting data such as users, are we given an understandable first and last name, or do we get a user id where we now need to search another table?
Security: If you are supposed to have an authorization or a cookie header in order to log into the API, does that work? Turn Authorization type to "No Auth" and see what happens. For Cross Site Scripting (XSS) attack simulation, submit into a text field "<script>alert(\"gotcha"\")</script>" and see if you can get the API to execute code. Check for validation, such as having angle brackets not allowed.
Errors: Testing Errors and Exception Handling, if you submit bad credentials (a 401 Unauthorized Response), does it give an error message of "Bad credentials" but a "200 OK" error code? Try to match up the error conditions with the codes. And try to avoid the cryptic "500 Internal Server Error". There should be exception messages or debug logs describing what happened so developers can troubleshoot. If you post to an API and received an error message, is a new record erroneously created?
Data: Did a record return a user id? Track down all ids represent the records that are supposed to be displayed. Don't assume that everything is correct just because you get a 200 OK. With Currency, does it list whether it is USD or GBP? What happens if you have 100, 1000, or 10000 users in the database? How about a million? How many milliseconds does it take for the data to return?
Amber also walks the user through automating all these tests in Postman, how Postman handles data driven testing, and set the tests up with Continuous Integration with Newman.
There is a lot of content here! Make sure to spend time practicing the techniques listed, checking to see if you can find other errors in the Restful-Booker API Playground.
Setting a Foundation For Test Automation Success - YouTube
The video course contains over 45 minutes of material covering topics such as:
What is your goal for starting a test automation initiative and what is it that you want to accomplish?
Who do you envision participating in your test automation initiative and in what capacity?
How do you plan for the execution of this strategy?
How to get people on board and help them understand their place in the automation strategy
How to scale your automation
Registration is free for this course, the current fifteen courses available, and the five courses listed as "Coming Soon". Also coming soon, ... a course I designed for Applitools Test Automation University: Introduction to Capybara.
I've been good. My nine-month old son is utterly adorable. My wife and I just love getting on the floor and playing with him. He's now crawling around so fast, we can barely keep up with him! He's also standing, pulling himself up on anything he can get a hold off. Kitchen cabinets. Walls. Shelving units. His Dad's hair. His Dad's ear. And somehow he is sprouting a third and fourth tooth!
Work has been amazing! I cannot believe how supportive everyone has been for this new father! Since we last spoke, I am on a new development team, focused more on the back-end, testing Threat Stack's many microservices that run the SecOps product.
Last year, I was creating a UI Automation framework from scratch, using Capybara + Ruby as a wrapper for Selenium WebDriver, and ThoughtWorks Gauge as a test framework.
To deepen my knowledge of Capybara and Gauge, I created a few demo projects:
There is so much going on in the software testing community with the Ministry of Testing, Applitools' Test Automation University, and Mabl and Lisa Crispin's webinar series, Modeling Your Test Automation Strategy! Ministry of Testing Ask Me Anything: Testability with Ash Winter - February 12, 2019.
Questions you can ask:
"How do I know when something is hard or easy to test?
"What are the principles of testability and what do they mean to my daily work?
"Is testability all about systems or are there social and team dynamics at play?How can I convince my team that investing in testability is worth it?
Masterclass: Strategies to make your automated checks reliable and robust with Peter Bartlett
"Learn how to write automated checks in a way that is fast, reliable, maintainable and becomes a crucial part of your continuous delivery pipeline.
"The advantages of automated checks are well known, they save testers working through mundane, manual test cases over and over again to check for regressions. Unfortunately, their disadvantages are also well known, being prone to unreliable results and a high cost of maintainability. Peter will show you how to overcome the pains associated with writing and running automated checks and turn them into an integral part of your continuous delivery pipeline".