One of the biggest mistakes in my career was to pick a different programming language for the test automation than the development team uses.
You won't get help from the development team when you have a programming issue
Developers will probably not run, nor maintain tests as they change the application, you will be maintaining and analysing test results (e....
If I was being interviewed and was asked this question, first of all I would start off by trying to quench my curiosity.
How much time do I have?
What type of a toaster is it?
How much power limit does it operate on as per the vendor?
Does the vendor provide any user manual or claims documentation?
How does it work? Is it timer based or manual toaster?
Yes and No
More often than not, an inverted pyramid (ice cream cone) is an anti-pattern, but there are circumstances where it is not. Your example of needing to rebuild an API in a different language is one such example.
Some other circumstances where you might want to invert the pyramid include:
You have an integration to a third party API. Your lowest ...
You can choose any language irrespective of which language is used in development. But it would be better if you go with same programming language which is used in the development, in your case it would be C#/.NET for below reasons:
You can leverage existing libraries used by your team.
Developers can help you out, As you said you will the only person doing ...
In addition to reading Working Effectively with Legacy Code, I have a few recommendations from experience:
Since there is little to no documentation, tour the software. Go through the software using it as if you were a user, noting what it does and what you can find about why it works the way it does.
Talk to long-time users. Since this is internal software,...
There is definitely a focus on test automation, not automated testing—simply because the latter is hard to do. I think this is related to the testing vs. checking debate (started by James Bach and Michael Bolton):
Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: ...
Indeed your observation is correct.
Every level of checking aims to give you confidence on what is being checked: Code unit, service contracts, systems, etc....
Two generic observations that we can have with the Test Pyramid is:
Precision increases when you "go down" the Pyramid: If a unit test fails, you probably know exactly where in the code ...
Good question. Here I am going to explain some steps from my experience.
1) We need good teamwork for that.
2) Here I just want to clarify that "Execute All Test Case/Suite" term. We need to prioritize test cases in four quadrants like below.
3) Do a good amount of Exploratory Testing instead of totally scripted approach.
4) Try to cover all business-...
Definetly learn C#. Why?
At Selenium tests level it's basically the same thing as Java 9. With a bit of syntactic sugars. It shouldn't take you more than 2 weeks to get up to speed with C#.
CI/CD and whole infrastructure is set up for dotnet. If you don't want to run this automated tests manually, you will have to either: configure whole infrastructure to ...
What are the most important components/parts of a well-written test plan document for a testing project. Consider you are testing a Financial web app.
As per IEEE 829 standards, the components of a Test Plan document should be :
Test Plan identifier
Items to be tested
Features excluded for testing
Chrome provides an inbuilt function for this:
Dev Console (F12)
Switch to the Sources tab
Do action in browser to get to the state you want to inspect
Chrome will pause the browser and the Elements tab will not update until you go back to Sources and Press F8 again. While it is paused you can switch back to the Elements tab and use the normal ...
Basically you never have enough time and resources to test everything, your test cases are already a subset of this infinite "everything".
What should you do then ? prioritize. A common heuristic is RCRCRC:
Recent: new features
Core: essential functionality of your product
Risk: risk is defined as the Probability of occurrence (how likely is it to ...
Given a simple application diagram how would you test it or what will
be your test plan or test strategy.
The only answer to a question like this is: "There is no such thing as 'go there and test'". Testing is performing a risk investigation activity. Any investigation has goals and questions to be answered.
So, what type of testing one usually do ...
The vast majority of automated testing isn't done to uncover new bugs. It's done to provide some assurance that updates don't change the expected behavior of the application. The most common question asked by automated tests is "Did these new changes break some existing functionality". This sort of testing won't root out non-obvious bugs, but will detect ...
Don't track and link stories to tests this way. It will lead to a massive mess.
Treat your automation itself as the product.
Use the Agile principle of working software (automation in this case) over comprehensive documentation such as detailed stories and links.
Reset. Separate your tests from your stories. Create a test suite.
Use test suites to ...
As the other answers have said, your first task is to organize the list. There are a number of reasons you want to do this:
The items may not be accurate - This is ridiculously common. What tends to happen is that the people who execute the test steps know enough about the system to adjust for flaws in the list and act accordingly.
The items may not be ...
I'd suggest starting with looking at the answers to these questions:
How to become a more Creative Software Tester?
How can a Software Tester use "Out of the Box" thinking approach to find more bugs?
There are a lot of useful suggestions there.
Some other things that can help:
Practice pattern recognition:
Take a large data dump or log ...
Below are the components of a test plan, which should be included.
1.1. Introduction - Provide an overview of this document in this section
1.2. Scope of testing - The scope of testing needs to be clearly defined. The plan should define items / features that are in scope or out of scope for the testing phase.
- 1.2.1. **Features To be tested** ...
Feedback also from my side what I learned from projects.
1. Prioritize the test cases
In my past projects we prioritized the test cases. We used HP ALM and there we had also couple of test cases and it was impossible to execute the all. So what we did is just to prioritize the test cases e.g. Critical, Very High, High, Medium, Low - same as you would do it ...
The first question to ask yourself is if this level of traceability is necessary. For some people, maybe the answer is yes. For others, perhaps not. If you don't need traceability between story and test, you can focus on better ways to measure test coverage and correctness.
The second question to ask is how you intend to implement automation. There are ...
should it represent a defect in the Application under test?
No, it might be working, but you cannot verify. You do need to monitor and follow it up somehow. Therefore ignoring/skipping the test-method and create a task in your workflow-system might make sense, but this could lead to a lot of waste handling and monitoring these issues. Do make sure you fix ...
As most things in life: It depends.
A bug can be seen as a failure in planning, where the proper verifications for that behavior were not placed. And since it happened in the past, it is likely to happen in the future - thus automated checking would prevent regressions in high risk areas.
On the other hand, when you decide to go through one path, you are ...
Be careful what you believe. Take all these answers with a grain of salt, including mine.
I look at one project and the unit test plugin on Visual Studio is showing me 38 unit tests, 5 complete module tests (we anticipate a lot more of these in the future), and 27 cross-module tests (these don't fit in João Farias diagram) where the test harness loads three ...
Debating whether something is or isn't an anti-pattern is like arguing over whether a politician is stupid, or whether one religion is better than another: there is rarely a single right answer. Instead, you should think about the trade-offs between different shapes of test pyramids and how they apply to your situation. I'll mention a few trade-offs.
It depends on the execution time of the automated test suite - if it's few minutes then it can be run after each new commit - when new changes are introduced to the code-base. If it takes longer then you can run it at the end of each sprint or even just before the new version of application in question goes to the verification / validation stage. It should ...
You have automation regression suite.
You are working in agile.
Cost of running regression daily is close to zero (you have build agents and CI/CD working).
You can add value to developers by finding regression bugs the same day they were created. You can decrease cost of fixing bugs. Yet you say there is no sense in running it daily/weekly.
There is. And ...
You can use tools like owasp zap to find all the API calls. It spiders through most of the endpoints in search of security vulnerabilities.
Read about different scans:
Such situations should be addressed both from technical and management perspective, few of the things that needs to addressed are :
1. Does the team consist of only single QA ?
If the team consist of just single QA who would be responsible for the entire automation, then choosing a programming language that is alien to current team will create a dependency....
I would say no. My current project has the QA testing using tests in Python while I code in Java. It is using black-box testing. You may also use JMeter for automated testing, which is coincidentally written in Java.
If you want to use TDD to created automated build tests, then you would have to know C# to be able to integrate the tests into the source ...
In such situations, the most important thing is to prioritize your tests. Risk-Based Testing is a good way to prioritize your tests. Look at the risks you foresee and base your tests based on the mitigation plan for the tests. For every risk analyze the impact and the likelihood of occurrence and assign a priority to the corresponding tests. Run the high ...