Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am about to go for an interview for a software testing summer job. What questions should I ask the professor about this + I have never done software testing before, any good reference material you can recommend will be appreciated.
thanks
You should be prepared to discuss a variety of testing terms, such as:
"black box" testing, "white box" testing, etc.
unit tests
functional tests
smoke tests
BVTs (Build Verification Tests)
the differences between stress testing and load testing
performance testing
globalization testing
interoperability testing
manual testing vs. automated testing (when?, why?)
api testing
security testing
regression testing
code coverage testing
(etc...)
You likely don't need experience in all of them, but you should express an awareness.
A general knowledge of the following is helpful (refer to IEEE 829 for a start):
- test plans - what should be in a good plan?
- test cases - what should be in a good test case?
- test design specifications
- incident reporting (including bug tracking)
- software specifications - what does one look for?
You should start thinking about how you would test different things. What are the base cases? Are there any boundary cases? What could be wrong with any given product or item? Think creatively...
For a few starting references on testing, I suggest looking at the following:
Cem Kamer's book on software testing
Wikipedia for some more starting points
IEEE 829 (related articles should be sufficient to get you thinking, as the full spec is good for insomniacs)
If you've never done software testing before, it would be a good idea to learn some things quickly.
I'd recommend checking out the Black Box Software Testing course, available free (without an instructor) at http://www.testingeducation.org/BBST, or in an instructor-led version that is free to members of the Association for Software Testing (http://www.associationforsoftwaretesting.org). This is a university-level course, hours and hours of video, supplementary materials, quizzes, self-tests, and pointers to other information.
James Bach and I co-author and teach a course called Rapid Software Testing (http://www.developsense.com/courses.html). The course notes for that are available for free at James' Web site, http://www.satisfice.com/rst.pdf.
I've written a lot of articles on testing for Better Software magazine. They're available free at http://www.developsense.com/publications.html.
In addition, there's a blog post for you: http://www.developsense.com/2009/02/how-can-trainee-improve-his-her-skills.html
There are several testing communities online where you can ask questions and get mentorship. http://www.softwaretestingclub.com and http://www.testrepublic.com are two of them.
Best of luck.
---Michael B.
Besides the questions you will be asked, don't forget the interview is actually a conversation. And you look much better if you ask questions yourself. So, let me say few things I'd ask if I were you :)
For me, when it comes to working as a tester, most important is communication. How well you can communicate with team members, managers, team that develops the software you test.
Do they use some kind of bug tracking system, if so, what system is it? Is it the same system the development team uses?
Does this tool cover most of communication needs, or there gonna be a lot of calls / email exchanging resulting in a total mess in discussions about issues?
Is there any automated tool used for testing? This gets you quite close to what are your responsibilities on this position, so will probably be covered in the interview anyway.
Do you get 2 monitors ;) ? (Really, getting a second display was like a huge improvement for me in tester job). Do you get the tools that make your work faster and more effective?
Terms, definitions and tools are important thing... but analytical skills, logic, communication and other skills may be more important.
Maybe It won't be a summer job, but a career.
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 6 years ago.
Improve this question
What are all the advantages of BDD(Behaviour Driven development) framework and cucumber?
I want to know what are all the advantages of BDD.
I totally agree the communication is one of the biggest advantage however the benefits are for all the parties involved and the advantages for those are different.
So briefly:
For All:
living documentation
collaboration, early discovery of unknowns
enforce building domain vocabulary and semi formal language (DSL) to
express system behaviour consistently within the organization
For devs:
like TDD, it helps to think in chunks, create nice and testable code.
write code for what is needed only (build the right thing)
better coordination between different dev teams developing similar
features with different technologies
For QA:
ready acceptance criteria
ready building blocks for all kind of tests
test what is exactly need (test the right thing)
For PO:
think and reason features in detail thus produce better specs
better visual and coordination with other Managers and Product owners
better visual and understanding on Devs and QAs output/report due to the same source/format of
specs
in my opinion, the biggest advantage of BDD is the increase of communication when you introduce it in the way it was meant.
An excellent article about this is from Richard Bradshaw - have a look at
Using BDD Tools To Write Automated Checks != BDD
The idea is that the three amigos (QA, Dev, and Business) collaborate to create the feature files. That leads as mentioned to a lot of communication before a story goes into production.
Another advantage (but surely not the main one) is that the test cases are human readable - and if you have to create reports for non-technical folks, you have it a bit easier.
But on the way of implementation, which I've often see, where the Testers have to create the features and implement the Tests by themselves is a huge overhead and is also an antipattern in BDD.
I hope that helped a bit!
Agreeing with Thywen, these are things BDD brings you:
Better communication
Examples are easy to understand, discuss and criticize
Easier to find things you didn't know you didn't know.
Building the right thing
Automated acceptance tests
The examples are executable
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am going to look for a job as a software tester (a SDET maybe), especially for website test. I have some vague impression of this area and got a couple of specific questions as below:
Among so many documents, such as functional spec, design spec, which should I pay more attention to? How to view them in a tester's view?
Any good suggestions about writing test spec?
Any attention should be paid to website test?
These are just some questions I got now, I'll update with more shortly.
I'd like to hear your voice very much. Many thanks.
Credentials: I'm an SDET with 5 years of experience, 2 of those years testing web applications.
1- I'd say testerab has a pretty good answer. There is no single document that you can invariably rely upon across companies or even teams within a single company. Pay attention to whichever document has information.
I'd augment that answer with this advice: Don't be surprised if the documentation is insufficient. Strike up strong relationships with people who help define the product (the dev, the business owner, the program manager, etc.). You will nearly always be relying on them for some of your specifications, since it is difficult to cover everything on paper (and, as you gain expertise as a tester, you will learn to see things that others don't notice). Try to write down any "verbal specs" as you hear them, and ideally get any requests for specification clarification in writing or email. Gathering them all in a public document is wise, and may help to uncover if two people have very different ideas about what the spec "ought" to be.
2- Testerab has a good answer to this question, also, here: How Do You Keep Automated Tests in Synch With Test Plans
"1) Who reads it? 2) Who should probably read it, but currently you suspect they don't bother? (Do you know why they don't bother?) 3) What information do they need to get from it? Does it give them that info? 4) How do you currently present that information? Does that work for your readers/non-readers? 5) What sort of feedback do you need to get from the readers of your test plan? 6) Do you have any regulatory requirements that you need to satisfy with your test planning? "
Test plans, like product specs, will vary greatly depending on the needs of your group. If you are in an Agile group you may spend very little time on your test plan, doing little more than outlining the areas you need to cover - or you might not even have a test plan at all, but just a conversation with the team about what will be sufficient testing for everyone to feel confident about making decisions about the product. Other companies will have very specific guidelines you will need to follow.
Cem Kaner's classic book "Testing Computer Software" is slightly outdated, but still a good place to start and discusses test planning. I'd recommend you buy a copy quite strongly, unless someone can recommend something as authoritative that is more current. Last I heard, this was still the software testing book.
3- I'm having a little trouble understanding this question, but will do my best. Do you mean, what specifically will you need to know to test websites? First, what do you mean by websites? Do you mean web applications? If so, you will probably need to understand server / client architecture, web services, databases and basic SQL, at least rudimentary security testing, integration testing, functional testing, and will benefit from an understanding or specialization in performance testing, load testing, more security testing, and familiarity with web GUI testing with Selenium or Watir.
Some helpful things for us to know to help you get started:
How much experience do you have, both as a developer and as a tester? If you are just getting started in your career, what is your educational background?
How much experience do you have working with web applications, and in what roles (dev, test, PM, etc.)?
And, you might want to try asking some of these questions over at http://www.softwaretestingclub.com - this is a site for software testers to build community. You will get a lot of good advice and support there, so long as you are active in the community, and many of the most influential software test writers hang out there. If you do stop by there, feel free to look me up!
Hope this helps!
Edit: Added some info to answer q. #2 and to mention Cem Kaner's book.
I'm a developer with 2 years .NET experience and 1.5 years previous testing experience and an ISTQB/ISEB Foundation qualification.
To answer your questions:
1: A test manager will (typically) have a test plan and awareness of the specification documents to be tested against. Using what a developer is using is a good start. If the development methodology is agile this will probably be "user story".
A good way to look at the documents is to go through and look at where individual elements of functionality are specified and create steps to exercise them (see some of the functional techniques below).
2: What do you mean by "test spec"?
You will need to prioritise the areas of the application that need testing and understand the coverage needed. A "Test case spec". (or test script) will fit into higher level documents (like Test Plans, and Test Strategies) can be efficiently and effectively written using some Black box (Functional) techniques including:
Equivalence Partitioning,
Boundary Value Analysis,
Decision Tables,
State Transition analysis,
Use Case analysis (which could be based on a user story)
to come up with scripts that contain test cases. These techniques can be looked up online.
White box (Structural) testing involves an awareness of the code and includes:
Statement Coverage,
Decision coverage
If you're are looking at a website, this may involve JavaScript; QUnit is a testing framework for automating JavaScript testing and would be useful to research. NUnit is a commonly used test framework for .NET applications (including web applications) - NUnit was ported from its Java equivanlent JUnit and has been expanded (most probably owing to the popularity of .NET).
3: I don't understand what you mean by this? A web application will need to be tested in many different ways, and contains server and client functionality that will be tested using different techniques and the testing needs will need to be analysed. It will depend on the project.
As mentioned in other answers there are also other types of testing:
Unit - modular testing of functions at the lowest possible levels
Integration - testing functionality between different functional areas
Regression - testing to ensure that previously working functionality hasn't been broken by changes
System testing (Functional) - ensuring that the code/system under test is working as specified
System testing (Non-functional) - ensuring that aspects of the system that may not be specified are appropriate e.g. performance, load, stress, interoperability, maintainability, reliability, portability, usability
Acceptance (something called User Acceptance Testing or UAT) - ensuring that the system under test is fit for use
As mentioned in other answers, you will be retesting existing defects and inclusion of these to your test scripts is a good idea.
Hopefully this answer has given you a lot of food for thought and a good base for research. Testing qualifications or a role as a Junior Tester in an established team to build your understanding and experience could prove to be very useful.
"Among so many documents, such as functional spec, design spec, which should I pay more attention to? How to view them in a tester's view?"
Being able to extract useful information from many different sources of documentation is a critical skill for a tester, so you're right to identify that as an area you need to look at. The documents you need to look at will vary from project to project, and from company to company, so there isn't one good answer about what document you need to look at - but having good specification analysis skills will mean you'll be able to cope with whatever you're given.
For that, I'd strongly recommend this BBST course on specification based testing - it will show you how to analyse specifications, applying the Satisfice Heuristic Test Strategy model. That should also help you with your second question about writing a test spec.
http://www.testingeducation.org/BBST/BBSTSpecificationTesting.html
I'd recommend the BBST courses in general - the course materials are all available freely online, at the website above.
If you're really serious about testing, you should also consider taking the online course from the Association of Software Testing. The Foundations course is free to members, and you'll get the opportunity to practice your skills online, gain really valuable feedback on how you present yourself and your ideas, and you'll also meet a lot of outstanding testers, both as fellow pupils and as instructors. It's hard work - but if you're willing to put the effort in you will really get a tremendous amount out of it. Being able to discuss the basics with other people will really help you to get a deeper understanding.
my 50c
If you don't have test specs, or any kind of specs, you can transform your bug reports into test plan.
For each bug report that occurs, create one test item. That way - you'll have list of tests that you can follow when doing regression testing.
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
My team has grown fairly quickly from 1 to 5 over the last year or so and are very interested in changing our development style from Waterfall to a more iterative approach like Scrum. We work for a University and specialize in CRUD web apps for internal customers who are always changing requirements along the way.
So, my question is...How do we best implement Scrum techniques?
Supplemental concerns: Is it recommended to quit Waterfall "cold turkey" in order to facilitate the transition or do you feel a progressive approach is more effective? In other words, pick and choose some scrum techniques to implement now and add others further down the road?
Make sure your dev practices can support agile. You should have automated tests, daily integration builds, one-change-one check-in, customer accessible test environment, etc.
Get your customer on board. Scrum is a business-centric PM framework. It is in their interest to use agile techniques because it gets them the greatest value for their money. But they have to want it.
Get your team, PO, and management professional training in Scrum.
Make sure you, your team, and customers share the agile values (Agile Manifesto style). You would be amazed how many people value documentation over working software.
If you have 1-5, then go cold turkey. Scrum is a simple framework.
IMHO a step by step approach is wiser. You should first start doing retrospectives at the end of each iteration / sprint (if you use iterations - if not, that should be step 0 :-)
On the retrospective, you look through what is going well, not so well, and what can / should be improved. Then pick the most pressing issue and think about how it can be improved - primarily using Scrum, but you may have a look at other (agile or not) solutions too if you feel the need to. The aim is to work out your own process, which may be strict Scrum, or a hybrid - whatever works best for you, in your specific situation.
Personally, I would go a bit more Jeet Kun Do when it comes to project management strategies. With my team, I've created a piece of software where they answer the scrum questions (with some personal sauce), so instead of 15 minutes of debating, everybody knows what to do. And it beats having someone taking notes.
Even though SCRUM/Agile project management is populair, the waterfall approach has it benefits too. I would give a try-out first and keep the goodies and get rid of the baddies.
Make sure your team is truly cross-functional. Get all team members be commited 100% to the project on hand.
Note - succes of scrum teams often depends on strong scrum master - hence try to get a experienced scrum master or a coach to help your team during the transition period.
Try not to mix waterfall and agile - suggest go cold turkey to scrum.
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 work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess
The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.
What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:
Essential de facto literature that we should read first?
Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
Practical "do this and this" guidelines?
Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.
Highly recommended reading includes : The Agile Manifesto and The Pragmatic Programmer. Subsequently, you'll probably want to get familiar with Scrum software development, or Test-Driven Development. At the very least you should have:
Source Control repository
Bug tracking system
Standard set of tools
for communication (A wiki tends to be
popular for documentation, these
days),
IDE
Testing framework
A lot of things will depend on the skills of your team and the application domain that you're seeking to go into. Get yourselves familiar with some methodologies, then practice them. Have 15 minute standing meetings at the start of the day. Develop code incrementally with a write a failing test, make it pass, repeat mindset. Etc etc.
I would suggest to try Scrum for start. As lightweight project management framework it should suite your small team needs.
To do that less painful I would also suggest temporary hiring someone familiar with scrum (certified scrum master maybe), after 3-4 months you should be able to keep it running by yourself. Really investing in few months of experienced team member should pay off. And I don't mean analytic, consultant or whatever you call person that comes, analyzes, makes presentation, takes money and goes while you stay with a problem. I mean Team member that will work with you but also introduce scrum to you via daily practice.
You could also just read some books instead, or send one or two team members to a training, but I think that having someone to incorporate Scrum into your daily work and start learning by examples is the best.
Good description detailed description (based on daily work) would be Scrum and XP from the Trenches (alternative source).
Subscribing rigidly to someone else's view of the development process isn't going to work for everyone. Start with the real basics
Get the basics of the development process right - see The Joel Test.
Track everything. Use a system like JIRA, FogBugz or so on to track all issues, features and bugs that are ever reported. Track how long you spend on each task; the information you have the better prepared you'll be.
Triage - Work with stakeholders to make sure what you are doing is actually important, rather than just what you think is important. In my experience, developers and customers often have wildly differing views!
I'm a huge fan of the recent Lean literature by the forerunners of the movement, Mary and Tom Poppendieck:
Lean Toolkit
Implementing Lean Software Development: From Concept to Cash
Leading Lean Software Development
These are very practical books that look at the whole business value chain from a software team's viewpoint, instead of being head-down in software land and ignoring business goals.
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 6 years ago.
Improve this question
Is there any website specifically for sharing and accessing actual software development processes implemented in software organizations?
There are lots of resources that give advices and descriptions for implementing these processes. They are very useful. But I think having actual example process definitions would be very useful as well. Specifically, I am now looking for an example process definition in CMMI. I overviewed several books but none of them presents any specific example implementation.
I think the authors are probably concerned that the readers might just copy these process definitions without understanding specific customization decisions in them. They are very rightful in this concern. But anyway, I think this is an important need for general software community. Understanding and interpreting an example document properly should be the responsibility of the reader.
If you don't know any good resource that shares specific implementations of the processes, what do you think about this need? Don't you think that we, software engineers and developers, should share our process definitions as we share our code?
There is a good wikipedia article with a lot of resources. Also searching for "UCM Workflows" on IBM Rational web would lead to good examples, I'd rather not deep link into their page. The question is how far into detail you want to go into the process. Most resources available will only give you a rough overview of basic development processes.
What you mean by examples is probably going into the details of specific implementation of such development process. For larger and established software development companies their development process will most likely not be readily reusable, because it will involve many custom made tools and configurations and the process itself could be in some cases considered proprietary, giving the company a competitive edge over others. Going into details about the process could also pose a security risk, because it would reveal a lot about the company infrastructure. So I don't think you would find much in form of examples from successful software development companies and what you find is either too general or written by theory-crafters.
This is a field of special interest for me for almost a decade now and I only ever found bits and pieces published about specific processes used by major software corporations. I would certainly welcome a forum to share experience with other professionals in this field.
Try looking at EPFC - Eclipse Process Composing Framework, there are some example processes, tools and best practices to develop them.
There are merits in providing some sample templates which would assist someone getting started. The limitation is that it could force the user to adopt the templates without thinking about the application.
Most methodologies adopt a 'guideline' approach with some tailoring. For example, the RUP system, promoted by Rational (now IBM) traditionally suffered from the assumption that it was only applicable to large scale projects. This prompted discussion on how RUP can be applied to a one person project. Of course it takes work and effort and if you are a small project team sometimes tailoring the methodology could overshadow the project; i.e are you trying to build a methodology or a product ?
As for samples some examples are:
Agile Unified Process - gives good examples of both process, artifacts and also commentary on the process and it's application,
Open Unified Process - again samples, artifacts and easily navigated system.
I do not know of such a "process repository". I only see general description like this one.
Note: While the CMMI implementations I have come across are quite tailored for a specific enterprise/environment, I found them truly effective when evaluated/challenged.
In that regard, the study Six Sigma and CMMI interesting, not so much as a practical example of CMM, but rather as a way to put CMM in perspective.
The OPEN Process Framework Repository Organization's web site contains an online repository with over 1,100 method components.
It doesn't contain final methods because, according to method engineering precepts, you must compose your methods from these components depending on your product, project and organisational needs.