27

Your boss doesn't want a flat "No" or to hear their request is impractical. They want to reduce the risk of releasing changes to the application. Make your boss choose your priorities, that is one of the roles of a manager. Add scenarios based on team knowledge and work with your boss to rank them by risk. Implement top priority scenarios Go back to ...


20

John Ruberto wrote an article some years ago on Stickyminds entitled, "Is 100% Unit Test Coverage Enough?". The article can be found here: https://www.stickyminds.com/article/100-percent-unit-test-coverage-not-enough In it he presents the argument that there are different kinds of coverage. One could cover 100% of requirements, but that doesn't include ...


10

It's always good to use numbers to make your point- There are N models and sub models of iPhones (for some applications you should also count the phone's network sub-type), each with M available iOS versions and sub versions (this is not entirely accurate, some models and iOS versions don't work together, but never mind that now) Older iOS versions needs ...


9

Agile Pilot: Automate a test in the simplest way possible Automate another test Repeat and evolve into a robust framework Your plan sounds traditional and will probably result in a lot of research and over-engineering. Start simple and let your tests form around your application and business. Tackle uncertainties as soon as possible. Don't make your plan ...


6

I think you need to practice. No matter how good someones GitHub account looks, or what they say they've done, listed on their resume, etc, interviewers are going to want to see some practical experience. Yes, not everyone is good with whiteboard exercises or coding in front of others, but it's pretty standard in most tech interviews. If you're ...


6

Mindmap all the high-level features of the application together with business owners. Go over the map with stakeholders (e.g users, developers, managers, and sponsors). Do a risk assessment with some key people, maybe also analyze brittle areas based on defect reports. Write automated happy-path tests for the highest risk features first. Create a test-...


5

Normal approach should we automate only functional flow not caring about the UI things like font of text, font type of text, color of text, background color, images, different panels on page etc. In short, DO NOT DO THIS. Automating text/fonts/images is a terrible idea because they can change. Does your marketing team (if you have one) have access to ...


5

The best way to articulate how much you know is to have some prove of your knowledge. If you can write frameworks, then upload some of your frameworks to GitHub or BitBucket. Using that way you can demonstrate not even the entire completed framework but some basic demo-code of how you solve such or another typical test automation problem. Another good way ...


4

I've spent a fair bit of time working on safety-related software. People die if the software fails, kind of safety. The first thing to note is that we had 100% test coverage of requirements. However that didn't have to be automated, sometimes because it wasn't practical, and sometimes because it wasn't physically possible. No safety-related standard ...


4

In addition to the other answers, one good way to practice the articulation of ideas is to join communities and discuss different points of view. Online, Ministry of Testing is a great place to start. They have a rich discussion board and a Disqu (I always get it wrong spelled). Your favorite frameworks and technologies should have something similar. ...


4

You should consider to keep them simple and use any data for analysis during the timebox to see where to explore next. The charter is just a mission to get you started, not a detailed work assignment and reporting tool. I like the format ckenst proposes in his writing exploratory charters: How to Write Exploratory Charters This is based on "A simple ...


4

Test Automation on itself should not be a field if you ask me, therefor it is mostly software developers (that value automated testing highly) who write books/articles that drive the field. Because very good software developers are also very good testers. Kent Beck: My personal favorite is Kent Beck and his book Test-Driven Development. Beck was one of ...


3

It depends what they consider 100%, but my basic answer would be 'no' especially if these are UI level tests. Tests at this level are slow and expensive to write and maintain. It looks like you know this already, but write tests that cover the broad paths through the application/its functionality.


3

In addition to some nice feedback you already got: think of and prepare (before you go to the interview) a few interesting problems you have solved and which you can share. That way you might be more confident in telling about it and don't need to have to improvise.


3

You could tackle that from two directions. You could take the bugs and ask the people who opened the bugs how to reproduce them. There is your testcase. You can probably start automating regression tests for these bugs immediately. Or you could just write the test cases yourself based on the documents and SUT you have. Maybe there is a business capability ...


3

DL;DR: It's possible, but you shouldn't. All the tools you've mentioned are essentially test runners, meaning they execute a DSL focused on test code in someway. JUnit and GoogleTest execute methods according to a code-based instruction*, have class/method-level mocking support, and do reporting. On the other hand, Cucumber and Robot are focused on ...


2

When i have given this answer to candidates in the past its because i feel they aren't demonstrating enough programming experience. Quite a lot of test automation is done with tools that don't really need programming skills but are more about assembling work flows using a gui. Such as appium and postman in particular. Try to talk about programming ...


2

I would suggest thoroughly preparing with mock interviews. Have someone like friend or family member as a interviewer to practice with.Make it as tough(even bit more) as real interview. And practice.... practice.... and more practice. IMHO, there is no substitute for practice.


2

In a similar case, we went with writing our own very light weight framework. Reasons are: We were not using many of the features of Soap UI, so just to make Restful calls, Soap UI is an overkill The paid version was costly for our need; extending the free version needed Groovy skills - Groovy was not a language our team was familiar with Soap UI projects ...


2

Unless you have a clear demand on automated processing I would tend to storing results in Google Sheets. Here are few points for the choice: You can easily manage the data from wherever you are since it is world-wide accessible service (and has the client applications implemented for all the famous platforms) Sheets provide some data analytics tool-set You ...


2

There are two aspects which might impact the way how you structure your tests within classes. Readability. You might want to use classes as logical boundaries so that the names of your classes would represent some area the tests inside those classes relate to. If you use the classes just because you have to implement your tests within classes and use them ...


2

Welcome to managing your manager. I agree with the sentiment that your boss doesn't want to hear a "No". That's not quite verbose enough. But, the answer is almost assuredly a "No". What you need is a way to communicate how and why to limit your test scope. Even if you tested all the permutations of every make-model, screen-size and OS, you will soon see ...


2

TestContext is being initialized automatically by TestNg. You can access it from your test methods which are listed below (for doing that you need to specify the method parameter in its signature): For some details you can refer to this post. And here is my example of using TestConext with running tests programmatically: public class Main { public ...


2

Well, I believe there is no proper answer here. There is also a lot of details missing here which could bring the light on certain aspects of the issue. However I can see couple of possible ways here: Another thing is that we need to have a clear problem statement. What does "maintain" mean and why would you need to "refactor" existing tests. However I ...


2

Page objects are a classic example of encapsulation - they hide the details of the UI structure and widgetry from other components (the tests). It's a good design principle to look for situations like this as you develop - ask yourself "how can I hide some details from the rest of the software?" https://martinfowler.com/bliki/PageObject.html I ...


2

Here's a number of design patterns you can use for testing REST services (with REST-assured, but not necessarily*): Service Object pattern. Just like Page Object encapsulates HTML page, Service Object encapsulates REST API. Hence, instead of dealing directly with forming HTTP requests and parsing HTTP responses, you can use business level methods like ...


2

As per this SO post the latest version of Pypupsub that is compatible with Python 2.X is 3.3.0. You have Pypubsub==4.0.0. Try to downgrade pypubsub version.


2

This all comes from the demand that exists in your particular project. A library is just a way how you distribute your code. Frameworks can be distributed as a single library or set of libraries as well. In my understanding a framework is the code that introduces inversion of control paradigm. So that you do not call a method a and then method b. You ...


2

This is a very complex and opinionated subject. 'Framework' is also a vague term that means many different things to different people. In the way you're splitting them out, I would say "Choose both". Where I work, we write libraries of common code (web testing code, app testing code, commonly useful code) and then use them in our frameworks (plural). In ...


2

IMO, for every major code change, you need to execute load test. You can decide either you can execute a load test as part of sprint closing/feature closing.


Only top voted, non community-wiki answers of a minimum length are eligible