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/
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 2 years ago.
Improve this question
Are there any added advantages to using Cypress instead of TestCafe? while comparing usages with developer friendliness, are there any added advantages using Cypress.io
This is difficult to answer, especially when you don't provide us with any insight into your context. These are not identical products, they might be suitable for slightly different use cases.
I can tell you my personal opinion of the two, but that might not apply to your situatio(s), so I just recommend reading documentation:
https://docs.cypress.io/guides/overview/why-cypress.html
https://devexpress.github.io/testcafe/
and trying the products on some real projects.
Some areas to consider:
what you want to automate
who needs to maintain the tests - how well people know JavaScript, Cypress, in my opinion, requires more knowledge in this area which seems to bring a lot of trouble to many people
reading carefully trade-offs and best practices in Cypress - if you don't already follow many of these practices, you might find it really hard to completely switch to Cypress
documentation support - this is exceptional in Cypress, really good docs online, with tons of examples, you rarely see this with other technologies
both products have some additional paid features, have a look on what you need to use
integrations with other services - CI, browserstack and the like
etc.
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
Deep-learning is applied to play game in some projects, so it should make sense to apply it for UI test automation. Any comments on this idea?
In large software, it is really hard and time taking to test out all possible scenarios via traditional approach. So, building a machine learning model to do this is a neat idea. The end goal for such a system would be to crash to make the software unresponsive.
There is research being done on this idea. You should take a look at this research paper which explores Reinforcement Learning as an approach to automated GUI robustness testing. Reinforcement Learning is also one of the approaches used in teaching computers to play games.
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
After hours of searching on google on the above mentioned topic. I am unable to contrast the difference between model based testing and model driven testing. Tons of definitions are there,. But there is no clear definition with real world example.
Can anyone please help me understand the difference between these two with the help of real world example.
I'm afraid there is no clear-cut difference between the two. First, because everybody uses a different terminology (there is no "standard" definition for these terms). Secondly, because IMO, both terms refer to the same concept (using models as part of the process of writing the tests for your system) and only differ regarding the importance of the role of models in the testing process.
To me, model-driven implies a stronger role of the models (i.e. models are used to derive the tests) than model-based (where models are used but maybe as an additional input in the test generation process).
At least, this is how I explain other "model-based" vs "model-driven" concepts as I tried to explain in more detail here: http://modeling-languages.com/clarifying-concepts-mbe-vs-mde-vs-mdd-vs-mda/
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.
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 5 years ago.
Improve this question
If you had to create a list of steps that a non-technical business layperson would understand for implementing workflows in something like Mule ESB -- what would it look like? The scenario would be to describe how the ESB is used to perform integration between two disparate systems and the steps you would need to perform to get the job done.
An Enterprise Service Bus is a technical middleware for system integration. It is doubtful whether mixing the business aspects into the picture makes sense. For business people to look at a picture and 'get it', the technical aspects would either be abstracted away and or require a tacit understanding of the technology. Better to keep them separate.
On the business logic level you should use BPML for workflow modelling:
http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation
The technical aspects of a service bus are captured through Enterprise Architecture Integration patterns:
http://www.eaipatterns.com/toc.html
The EAI view is already abstract, but expecting business people to understand this is like handing them UML diagrams and assuming they're literate by nature (alas, they are not).