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
During the development cycle of a feature, the feature is constantly changing, even after the point where the it meets all requirements (UI improvements, etc...). If you have automated tests for that feature, these changes can break your automation and you will have to rework it. If the feature keeps changing though, it does not make sense to rework automation after every revision. At some point, however, you have to automate it so you can do regression testing. How can we find the optimal time to rework automation? How do we get the optimal amount? My team agreed that we over-reworked the automation of one of our features. One example of a mistake we made was to rework automation right before a conference where we showed the feature off to customers to get customer feedback. We should have known that customer feedback would result in more changes to the feature. Functional testing should have been enough in that case.
Does anyone have any tips or experiences to share?
The general tip would be to come to a consensus on what "done" means for the feature before you you start building it.
If during the build you come across some new tweaks that you'd like to add to improve the feature (or whatever) don't add them to the existing story - write a new one... and make sure that you prioritise it against the other things that you need to be doing.
This is also sometimes, but not always, a sign that you're working with increments of functionality that are too large. Try splitting and thinning the stories further until you can write down some quite concrete definitions of "done" for the feature. Consider automating those tests of "done" before you start building (but don't go overboard).
You might find the Specification By Example book of use.
According to my experience is that the feature you've been developing is not understood by the customers yet, fully.
Separate the feature into small parts like #adrianh suggested.
One more tip for the instable customers: Let them first see the pseudo prototype at first hand, even maybe in the planning meeting (code it directly to html or something easier something like a prototyping/diagramming tool). Let them play with it. This way, you will have an easier time with your features.
Related
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 3 years ago.
Improve this question
This might sound a very vague question, but I am hoping to get some insight from all of you who can throw some ideas so that I can move in the right direction. I have ReadyAPI license and want to develop an automation framework around it. I can of course add assertions and create tests and everything within the tool, but I am wondering if there is a way I can build keyword or data driven framework around it so that I can have reusability, ease of use, adding assertions on the fly, execution via excel, or even adding assertions via excel (not sure). I am not sure if that's going to make creation of tests even more complex. Please provide your valuable inputs!
If you already have Ready API! then you probably don't need anything else. The licence is not cheap, so you'd have to consider if you really want to spend more money buying something from Mindtree. And, looking at their list of dependencies, there's always the danger of getting bogged down in the tooling and making them work together rather than doing actual work.
Why not start small and simple by doing some data-driven test cases using Excel or even a database as your source? I've used Excel to drive test cases and to populate assertions and not encountered any problems. For any customised behaviours, there's always Groovy to help. Then, once you've maxed out the capabilities of Ready API! look at something else.
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 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 3 years ago.
Improve this question
I'm a React Native Developer from the past 7 months. And this is my first technology I'm working on. So, I recently got to know that there are certain coding rules which I wasn't following and was unaware of. I have two general programming questions.
So I just got to know from an inteview that one should create wrapper functions in their code, by which I can just call a single function which points to a module or a API.
Like wrapper functions, what else is a good practice in programming?
Since I never worked on Android/iOS before and directly jumped to React Native. I often find myself doing trial and erros when it comes to do styling in my application.
Or what is the right way to style an element without giving too much margin/padding, which I assume is wrong. Or what is the right way to style where the styling works the same in all devices. Can someone recommend me a right article or video or something for this styling issue?
This may well be the broadest question(s) on StackOverflow :-). Just a few suggestions for the first question.
1. Read :
Many books have been written, some down-to-earth (Clean Code, The Pragmatic Programmer, Code Complete, Refactoring, ...), some more theoretical (Structure and Interpretation of Computer Programs, ...).
2. Collaborate :
You can sollicit code reviews from colleagues, have pair-programming sessions with them, attend coding dojos or hackathons. All of these are ways to share and transfer knowledge among peers, are very helpful, and almost always fun, too.
3. Play :
Sites like codewars.com are great to let you experiment with huge numbers of coding challenges, risk-free, and with the bonus benefit of seeing the solutions of others (once you're done :-)).
Maybe it's worth posting the second question separately, with the appropriate title. Good luck!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
It sounds strange, but that's what I need. An effective way to document a Scrum project.
I agree that it's a waste of time to produce User Stories and a Requirements Documents.
But sometimes we need to have the vision of how the software currently works.
How do you do that? Do you know some best practices or case scenarios on this?
Thanks
The short answer is this: you can write anything you want or need to about any project, Scrum or otherwise. Scrum doesn't tell you how to document, but it doesn't tell you not to. The way you document is in itself irrelevant to Scrum.
That said, if you need to understand how the software currently works, a document will not help you. Documentation often lies. If you're trying to understand how the system works, a document will only tell you what people think or want to believe is the truth.
What you should consider, is to use executable specifications and Test Driven Development to prove that what you believe the software does is actually true. automated tests combine documentation, examples and regression tests all into one offer.
There are several kinds of documentation that can help you. It depends on your context which ones you need, and at what detail level. You could also use a tool such as MOOSE to create project specific visualizations of your software at all levels. Some simple documents are:
A story map
Gherkin style high-level features and scenarios
If you've tracked your product backlog items through completion, including acceptance criteria for each you should be able to point to the list of completed product backlog items as documentation. Everything you've programmed should be associated with a PBI, so the completed PBI's document your project.
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.