Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How to make the test cases maintainable or generic in an agile environment , where there is frequent changes in the requirements.
This is a question that was asked to my friend in an interview.
Write tests at higher level of abstraction
Write intent revealing tests rather than tests that mimic the user clicks on UI
Use BDD frameworks like Spock, Cucumber etc.
Re-use: Identify the reusable features and re-use them. For e.g. Login feature steps can be written once and re-used across other features
Write more tests at service level than from the end-to-end
Use formal techniques to reduce the number of regression tests
Equivalence Class Partitioning
Combinatorial Testing
Boundary Values
Create a test strategy for the entire team
Move white-box testing to unit and integration tests
Clearly identify what will be automated by testers and what should be automated by developers. For e.g. most of the white box tests can be realized using unit tests. Testing Quadrants is what I use heavily.
And most importantly ditch tools from vendors like mercury and IBM.
My short answer to this is treat your test suite with the same respect you treat the rest of your code base.
Automated test are code - important code. Pay as much attention to keeping them well factored and clean as you do everything else and you can't go far wrong.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
How to decide which type of testing(Manual or automation) required for a project or application to test?
What are the parameters we have to consider to select which type of testing(Manual or automation) to test very new application?
It depends on :-
Size of the project- If the project is large and consist of so many functionalities then automation testing is suggested
How many times you want to test a particular feature- If the requirement is to test regularly then automation test is best
Font size and image- This can not be tested through any automation tool so to test this, one should need to do manual testing
To find bugs- If one needs to find a lot of bugs, Manual testing is suggested.
You shouldn't have to choose between automation testing and manual testing the way you're asking. The way you're asking it gives me the feeling that the product is already waiting to be tested. In this case you would need to resort to manual testing.
Ideally you would want to have both and even more of automation. Some of the questions that you need to ask are:
Is this a new project or an existing one? If it's a new project then it's easier to plan for automation from the start. You could start implementing automation tests from the start. If it's an existing project then you'll need time to set up automation + write scripts etc. Then you have to resort to manual testing initially.
Is there any existing team? If yes, then what are they doing. You need to continue the process instead of suddenly disrupting it for anyone.
How much resources (money+people) do you have? Do you have manual testing resources? Are they busy or do they have bandwidth? How many automation test resources do you have?
What kind of project is it? Who does it go to? Does it have human lives depending upon it? Does it need a legal certificate of some kind for being tested?
There's just too many questions based on how your question is currently stated. I hope that this answers your question when we consider it generally. But if you're looking for a particular answer then please consider adding more context.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
We are building a new application and we are considering what testing frameworks to use. There are two types of testing we want to do:
Test all the possible logical pathways the execution thread can take (so this is more a technical/developer level testing strategy). We can do this by creating a program to combinatorially generate all the required test data.
Test only the required business use cases for the application (so this is more orientated towards the QAs and BAs).
My thinking is that for (1) we use JUnit and for (2) we use Cucumber. I have no experience in Cucumber. My question is can (1) and (2) be achieved with one framework like Cucumber or is it best practice to separate them out as I describe above.
I'd tend to agree with your assessment that JUnit (or another unit testing framework) is best suited for category 1 while Cucumber is well suited for category 2. Cucumber is a framework for writing natural language (more or less) specifications (in the Gherkin language), and as such its strength really lies in writing executable application specifications.
For purely technical testing, in order to enforce maximum test coverage, you're really only making it more difficult for yourself by writing the tests in a business-level language (Gherkin/Cucumber). Writing the tests with e.g. JUnit will involve much less friction.
For a good understanding of Cucumber and its role in the development chain, in comparison to other (BDD) tools (e.g. RSpec), I'd suggest reading The RSpec Book. In particular, it recommends RSpec, which is more similar to xUnit frameworks, for testing isolated parts of your system, and Cucumber for testing your application as a whole. This book is especially valuable in that it is authored by the creators of said tools (RSpec/Cucumber), so you get to know how these tools are intended to be used.
An example Cucumber specification, the test itself is within the Scenario block:
Feature: Serve coffee
Coffee should not be served until paid for
Coffee should not be served until the button has been pressed
If there is no coffee left then money should be refunded
Scenario: Buy last coffee
Given there are 1 coffees left in the machine
And I have deposited 1$
When I press the coffee button
Then I should be served a coffee
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In our team the Developers are arguing they should not be writing the BDD tests since BDD tests are automation tests and QA team should be writing it.
Is that how everyone else out there does it? Or do you have Developers writing BDD tests?
By the way...we use SCRUM methodology on our team.
Regards
This depends on your team and which development methodology you using.
In SCRUM, developers should write tests and QA (which strictly speaking must not exist as part of the development team) may perform infrequent manual tests, that cannot be automated (such as usability tests, information perception, colour choice). In this sense, QA becomes a 3-rd party service, that does not participate in everyday development. A team may use occasionally this service to get specialised feedback.
From the scrum guide (with my emphasis)
Scrum recognizes no sub-teams in the Development Team, regardless of
particular domains that need to be addressed like testing or business
analysis; there are no exceptions to this rule; [...]
In (iterative) waterfall, QA and customers, can write BDD and acceptance tests. They can do this in plain English, leaving programmatic implementation of the tests to the developers.
The fact that the tests are automated doesn't mean that developers should delegate writing tests to QA.
BDD - behaviour driven development is method by which developer writes automated test cases. Anyone who is writing code can write this. Suppose any team is following TDD then BDD is not required as the case may be. BDD is basically for developers who is developing some software based on behavior by using some tools like specflow.
I hope this will help.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a large legacy .NET application that has evolved and grown over the years to include many components and moving parts. I want to develop a strategy for developing automated unit and integration tests for this application and to that end I think a graphical representation would be key.
What I am picturing is some sort of diagram I could use to guide the process of writing up the test cases, help achieve better coverage, and eventually refer back to once a specific test fails. Does anyone have any thoughts on what type of diagram could fulfill this goal? My guess is this would be a variant of the classic functional block diagram, but I have not found examples that specifically relate to the design of an automated testing strategy.
Could this be what you are looking for?
The UTP provides extensions to UML to
support the design, visualization,
specification, analysis, construction,
and documentation of the artifacts
involved in testing. It is
independent of implementation
languages and technologies, and can be
applied in a variety of domains of
development.
UML Testing Profile: http://utp.omg.org/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I see many developers disagree on which style of test to use while starting a new project. I'd like to know why you choose this particular style over the other.
BDD and TDD are not excluding each other. I think, BDD addresses more the software development as a whole, beginning from requirement analysis. TDD is purely related to implementation and is actually a personal work technique of a developer.
I usually use the outside-in principle. Whether you will call that TDD or BDD is of less importance to me.
What this means is that I start at the most significant part of the feature that I want to implement, and work from there. This is often the User Interface, but it doesn't have to be. Sometimes the most significant area is a service operation or a background process, and then I start there.
I use Test Doubles to define how the classes I define interact with its environment, and then implement more and more of the abstractions defined by these Test Doubles as I implement the feature.
So I guess you could say that I start out in a BDD mindset, and then move more and more towards TDD as I work my way down the call stack, so to speak.
TDD v BDD is really a state of mind. The way I see it is, in TDD a lot of emphasis is on what should this value be at this point, where as I see BDD, which will also test values of course and how we got them, as being more of, when this is in this state, what should this part of my application do.
I learned to do TDD in a BDD style. Its all really a matter of how you do your thinking.
Many people have made the mistake thinking that TDD was about testing. Thus BDD was created' to minimise confusion by emphasising behavior over testing.