TestinGil - Gil Zilberfeld -Agile SW Testing Consultancy, International Keynote Speaker

Testing APIs is complex. Because APIs are complex. We can send them different combinations of payloads, headers, cookies, and expect different behaviors. And that's before you even start thinking about what's under the hood. Developers are better suited to testing APIs, because they can take advantage of the coding environment. They know what the code handles, and if needed, they can access the database, or mock a service call. My "API Automation Testing" for developers covers, not just the tools and techniques, but also how to create a mindset of testing complex systems. It covers testability issues, and thinking about different options of testing APIs. It covers tools, techniques and patterns that help conquer the complexity. Developer tests are a crucial part of making the delivery pipeline run faster. API testing is a big part of modern apps, and developers need to master the different practices that help facilitate fast, quality delivery. Check out the workshop. https://lnkd.in/e6qQFdpg #APITesting #Testing #Automation

We do refactoring everyday. Or do we? Refactoring is changing code's form, without changing its functionality. But how do we know, we REALLY didn't change the functionality? What if we don't have tests? Or we have tests, but not enough? Or maybe not the right tests? My webinar covers these questions, even before touching on the "how" part. But, of course, there's coding and refactoring (real? half-real? I'll let you be the judge!). Check out the webinar recording. https://lnkd.in/e74yu_jF #refactoring #legacycode #testing #testability #python #cleancode

Meetings. Who doesn't love them? We might think of meetings as a waste of time. And some of them are. If we start to think about them as risk mitigation tools, we might see their value. Everything we do in software, including meetings, has a cost, and some value. Thinking in economic value, can change our priorities. Here's a blog about it. https://lnkd.in/ecnvpkpi #software #softwareeconomics #development #testing

Testing a complex system is hard. Coming up with ideas for testing is harder. We need a super-tool to help us. SFDIPOT for the rescue. SFDIPOT is a testing strategy heuristic. Instead of feeling stumped by the big system, and mostly compromising on the functionality, SFDIPOT offers different ways to come up with testing ideas for the system. And it's not just its functionality - but also its structure, who's using it and how it runs. Here's the first video in the SFDIPOT series, introducing it, and also explaining what heuristic is. Check it out. https://lnkd.in/drx9NzMh #testing #automation #testautomation #apis #planning #testplanning #SFDIPOT

Quarter of a century in, and we're still hung up on code coverage as the main indicator of quality. Why? My guess is that code coverage measurements are the easiest to implement. A couple of hours at most, and you've got code coverage metrics in your pipeline. All other methods require a lot more work. Most people take the easy way out, without even understanding the damage they cause. Because code coverage sucks. Read the blog. https://lnkd.in/ejvPg5mV #codecoverage #metrics #quality #testing

A few years back, if you'd ask me about unit testing the front-end, I'd say: It's possible, but why would you? You'll find your errors pretty quickly just by looking at the screen. Plus, UI changes all the time, you'll need to rewrite all the tests, all the time. Of course, I was wrong. Still right about my excuses, but run over by complexity. There's too much to catch by just "looking at stuff". We need automation. But using full web automation seems like an overkill. Complexity comes in different flavors. One of the flavors is using frameworks like React. React makes it easy to write reusable FE components, and very complex at that, so we want to test them, but without the entire server running. And where complexity beckons, I answer. My new workshop "Testing React Components" covers everything to jump-start your component testing . It starts with understanding what we test exactly, the quirks of React and how to deal with them in testing scenarios, making test plans, dealing with external dependencies and designing the components for testability. And of course, how to run them in CI. If you're intrigued, good! Check out the full syllabus and give me a ping! https://lnkd.in/eX3qYatZ #Testing #Automation #WebAutomation #React #UnitTesting #ComponentTesting #FrontEnd

Apart from the "Testing React Components workshop", people asked me if there's an equivalent in Angular. Well, as you know complexity doesn't spare any framework. So yeah, there's a workshop for that. The same tricks and schticks are present in Angular, but a little different. First of all, Angular comes with its own Test Bed. So you can choose your testing flavor. And you depend on the inherent dependency injection. But other than that, you still need to know how to test, isolate and refactor for testability. And the workshop of course, covers that. And the more unique to Angular quirks. Check out the full syllabus and let me know how I can help! https://lnkd.in/ec4SZNVr #Testing #Automation #WebAutomation #Angular #UnitTesting #ComponentTesting #FrontEnd

How much time and effort goes into test automation maintenance? Lots of people go blindly (sometimes everyday, sometimes a few times a day) and just fix up tests. Or bury themselves in logs, so they can find out if their tests actually tell them the truth. Or that the truth is out there, but not where they were looking. Automation test suites should be helping us. How come we end up working for them? I think it's because we don't just stop and ask the question: Is it worth it? So I did, and tried to answer it. I came up with more questions (of course). Check out the blog post. https://lnkd.in/ensutBJi #testing #apitesting #automation #webautomation

Quarter of a century in, and we're still hung up on code coverage as the main indicator of quality. Why? My guess is that code coverage measurements are the easiest to implement. A couple of hours at most, and you've got code coverage metrics in your pipeline. All other methods require a lot more work. Most people take the easy way out, without even understanding the damage they cause. Because code coverage sucks. Read the blog. https://lnkd.in/ejvPg5mV #codecoverage #metrics #quality #testing

Doing a release plan, or any larger-than-a-sprint release, involves building a test plan. And when there's a lot of content in this release, it looks like a mighty big job. Luckily, starting with setting the boundaries, flagging the issues, and agreeing on what's important can save us a lot of time in the big planning meeting. That's Top-Level Test Planning. And this time, it's an example on how to tackle a big release, with a whole lot of features. Watch the video. https://lnkd.in/gqMzKDAr #Testing #TestPlanning #Automation