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.
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 4 years ago.
Improve this question
Why do we use OOPs concepts?
What are the advantages/disadvantages of OOP?
Where do we use OOP?
How do we tell if a program can be written in OOP paradigm? How is it organized?
Note : I'm not related to technical field... So please consider this in your answers.
In short: to reduce the cognitive load required to write, maintain and understand the software.
Software systems are inherently complex, so developers need some tools to break things down to the modules and individual components that could be analyzed and understood without enormous efforts — and OOP is just that kind of tool.
Thats quite a big question. And I try to give you a feeling why we do develop principals like oop ,soa,....
Most of the principal target to make software less complex. Imagine a file with 1.000.000 functions. it would become difficult to find the you want to change. Especially if there are not veryx wqell name like "Update" so you could have a thousand "update" methods.
Often things are less complex if you don't see the complete information pool so you can focus and things you may need. Thats also why there ideas like the information hiding principle .
Another thing is that when you have standards you have to think about. For example in Real life you know that you can sit on a chair (thats a standard) you don't ahve to think about it. Thats why standards make like easier. Some aspects of OOP establish standards (e.g. use of classes) therefore there is little less complexity.
Having class which are grouping the functions may be the first step towards oop. Now when you search a function you would most propably know what you want to udpat "a custoemr" so you know this function may be in the customer class and you have to only look over these methods.
And most of the time thats what principals are made for. making software more read and understandable
OOP is much much more and not the only paradigm .But there is so much more and OOP has so much principals and interprations. It would be too much to explaind and discuss it here. I would also recommend you to have a look at the CleanCoders Movement which provide this in a more general way.
CleanCoders Webcasts
Does ORganization matter
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 always hear that we need to encapsulate whenever we write object-oriented code. If I'm the only developer on a project, do I still need to use encapsulation?
One way to put an answer: Encapsulation, conceptually, exists for writing better, safer, less error-prone code. It doesn't exist, primarily, to facilitate teams working together on code (that might be a side effect, but that's not the purpose).
So the goods that encapsulation seeks to foster scale from one coder to many coders, and they are goods that do not really have to do with the number of coders, although those goods may find stronger expression the larger the project and teams are.
Encapsulation is there for a reason.
Someone has to maintain and manage your code after you are done, right? What if the project gets bigger and you get team members?
So, the answer is "yes", it is always best to use encapsulation whenever possible.
The fact you are asking this question makes me wonder you actually did not get the actual value of encapsulation as a means to reduce and thus deal with complexity.
My theoretical computer science professor used to tell me that in the end, if you think at the whole binary representation of a program, any program is just a number. Very big indeed but, only a number. And that is true, any other construct we use but 0 and 1 (i.e. C++, Java, Python, functional programming, object oriented programming, aspect oriented programming, etc..) is just because of the fact we need more abstract means to get the one number we need.
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
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.
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
I am going to coach a student for her career as a software tester or a software test manager. Do you have any suggestions, for which interview questions she should be prepared?
Thank you very much in advance.
I'd ask - "how would you test 'this'?", where 'this' is something relevant to your work - or something you at least know a lot about. For example, you could ask "how would you test a web browser?". You'd want to see if that had a nice battery of functional test ideas, as well as an idea of the big picture or (as stated above), non-functional areas such as performance, reliability, security, etc.
I'd also ask them questions about communication - e.g. "Give me an example of how you resolved a conflict with a co-worker". Testers are often the "bearers of bad news", so interpersonal skills, as well as the ability to communicate well with their peers is critical. You can also look for examples of using data to make decisions, or influence without authority are valuable.
Finally, ask "how do you learn?" - testing is a learning activity, so the ability - and demonstrated experience in quick learning is the sign of someone who will be successful.
Be ready for the "do you have questions for me" that comes during most interviews.
Have some questions ready. For example, are they an agile or waterfall shop? Do they use automation? What type of testing do they include usually (regression, security, performance, exploratory, etc). And ask specific questions about what they are developing now.
Most good testers I know are curious and love to learn new things, so if I were interviewing someone and they had no curiosity to what our product is and how we develop it I would not be looking for a 2nd interview.
What should you include in a bug report?
1) how would you analyze business use cases and develop test plans around those use cases?
2) how would you implement those test cases?
3) how would you handle regression testing across releases as the application gets bigger
4) how would you track issues.
thats a standard set of questions for QA/Testers. If the candidate has programming skills, I would ask them about experience with automated testing and things like Selenium.
What is a regression test?
Define and explain the differences between:
Functional testing techniques
Non functional testing techniques (which apply for security for example)
And between:
White box testing
Black box testing
Grey box testing
In which kind of cases should they be implemented? Give examples.
Suppose you are hiring a software tester. Which question would you ask him?
Joel at the end in this article has mentioned some qualities for a tester. May be this can help.
Joel on testing
Monitoring Techniques
Complexity Metrics
Types of Software Analysis
Explaining a challenging bug
Testing questions about the Software Development Life Cycle (SDLC), basic test concepts, and some simple “challenge” questions to include writing a SQL statement and writing an actual test case.
Phil Kirkham's post from a while back also has some useful tips