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 ...
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: ...
I'm the author of one of the tools for Java (http://pitest.org).
I have found mutation testing useful in practice, working on large legacy corporate code bases and smaller test driven projects.
I've seen a lot of dismissals of the value of mutation testing such as Bj Rollison's answer. I generally don't disagree with the points he makes, however some ...
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-...
A simple test strategy can only guarantee a simple assessment of quality.
According to James Bach:
The purpose of a test strategy is to clarify the major tasks and challenges of the test project.
You can (and probably should) expand "tasks and challenges" to mean "goals, activities, deliverables, constraints, risks, and dependencies." Given that, your ...
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 ...
Mutation testing is generally interesting from an academic perspective. I have never seen or heard of anyone using mutation testing on software that is delivered to customers on a schedule. The time and expense involved in mutation testing is huge compared to the perceived value returned. In complex projects with several developers contributing to the ...
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 ...
Yes. I call them Contract Tests. One easy way to understand them:
Start with tests for a specific implementation of the interface. For example, consider ArrayList implements List. You write tests for ArrayList. One test could be this:
list = new ArrayList()
assert_equals 0, list.size()
Notice that ...
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
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
Unit testing only tests units in isolation. In these tests all dependencies to other units are mocked or stubbed out. So how do you know those units together do what they are supposed to do? Code tends to grow hierarchically in complexity, and with that growth comes more and more units working together, more and more groups of units (modules) ...
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** ...
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 ...
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 ...
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....