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
Related
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 5 years ago.
Improve this question
Having worked for a couple of years in software development, I grew wondering how to effectively communicate at work as of nitty gritty details of UX, functionality changes, error reporting system, and so on.
I have worked for two small companies here in South Korea and found out communication is done only orally from the start to the end, and never had any habit of software documentation.
I think it’s very odd because meticulous planning and effective software management cannot be done with spoken communication only.
(Although, I think in some sense, it may be justified if a company is not big enough to handle the extra workload.)
So, recently, I am genuinely interested in written communication for software, trying to rekindle a little bit knowledge of software engineering that I learned at college.
I’m trying to teach myself how to visualise my work and practice documentation on my own in practical level.
So, my question would be
Do you know any free graphic tools that can help me draw diagrams or UML, or etc?
Also, It will be appreciated if you could talk about how you document your app for future refactoring and better management.
Thank you.
Also, It will be appreciated if you could talk about how you document your app for future refactoring and better management.
I think you need to read about Agile software development.
Manifesto for Agile Software Development
Make attention on the next point:
Working software over comprehensive documentation
In your situation this can be explained as software writed in "clean" and understandable way with suits of unit and acceptance tests will be more effective then writing static documentation and UML diagrams.
I found UML diagrams are good for designing components in the beginning(but usually had used white boards). Then all diagrams was thrown away after all needed unit, acceptance tests was created.
Regular code reviews are good dynamic tool for sharing best practices, code styles or other information about developing software. So while you sharing knowledge about your software between members regularly, information will stay up-to-date inside team.
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 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 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.
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 5 years ago.
Improve this question
Perhaps if I make the my documentation better I could spend less time supporting developers and more time developing myself:
I develop a critical platform used by 10 other developers and 50 end users. The developers are of mixed ability ranging from domain-experts to relative beginners. Since I'm one of the people who know how the core platform works support requests from other developers usually go via me.
Our documentation is the usual sort of descriptive stuff any mature project will have: We have a large wiki containing details of all the usual operating procedures plus extensive API documentation.
Unfortunately it does not cater well for "how do I fix " type questions:
Would it be possible to make some interactive fault diagnostic documentation that puts users through a standardized fault-finding routine. The documentation would ask users a series of questions, and depending on the user's input would tell them what to do... it would be a very simple expert system, or possibly a documentation state-machine.
The idea would be to help newbies think more methodically about diagnosing faults in this complex system.
My question:
Are there any free tools intended to implement this kind of user-experience? I'd rather not hand-roll this. There must be some kind of framework for interactive help & documentation.
Has anybody implemented this kind of system before?
If you just wanted to have a flowchart/stat-machine thing where the user moves from the start point to a set of possible solutions by answering questions, then you could probably implement this as a set of wiki pages, where the possible responses to questions on one page are links to other pages.
This solution relies on being able to represent the answers to questions as links, which isn't going to work if the information is more form-like. For example, suppose one question is "What brand of graphics card do you have?" where the answer is one of 300 possible options. In this case it's going to be tiresome to create the links :)
If the developers are asking too many questions then I would suggest making them research the question themselves and come up with an answer, then double-check with you instead of encouraging them to ask you every time. It's much easier to ask somebody else than to find the answer yourself, but they're never going to learn if they don't look for themselves.
If the users are asking a lot of questions then you may need some user interface improvements. Try putting hints in the application itself at the top or bottom of the screen maybe.
For both groups of users a wiki can help.
a FAQ in your wiki
if an error happens too often, try preventing it or output a more useful error message (like "if this happens, the likely cause is that...)