Hot answers tagged agile-testing
8
I've been the first tester on a team before and seen how they've tested their software before (usually doing a very good job of it as well). For as small as you are, I think that you're on the right track for the most part.
Creating automated tests as you go is great. You may find some benefit to some TDD approaches which ask you to create the tests ...
6
Welcome to SQA, FJFG. As Bruce McLeod once wrote, "There are no 'best practices', there are only good practices in context." A good practice for you will depend upon your context. I will suggest some contextual considerations. You may be aware of others.
Your primary job, or at least your initial job, is to own and convey business requirements. Those ...
5
Not saying that it's cheap, but, tools like OneNote tend to fill this void very well. We use a notebook for each application. For projects, we use Tabs/Sections for Modules/areas, and for operational type changes, we use a new section for each Release. Each session takes up 1 page. These get stored on either a sharepoint or in a shared folder that we all ...
4
If you want to go fast, you need to assume that once something is tested and working in a cycle, it will continue to work in that cycle. If you cannot make that assumption, you either need to spend more time testing (by yourself or with the help of others) or your developers need to deliver higher-quality code. No one but you and your developers can decide ...
4
This is the exact problem that bedevils the environment where I work, and have yet to find a strategy that works well and consistently.
Some of the strategies and techniques that help are:
The testing specialist works with the coding specialists on the unit tests. Even if the testing specialist isn't a coder, knowing the coverage of the unit tests and ...
4
I assume that you have a suite of unit tests the developers are running which is essentially your first line regression suite.
The purpose of a functional regression test suite is to help ensure that code churn didn't destabilize existing functionality, especially across dependencies. In general, the functional regression test suite should be ran every ...
4
I see design of requirements (user stories) and test cases (acceptance criteria, scenario's) as a collaborative effort of business analysts, developers and testers.
BA typically kicks of with the initial user story and acceptance criteria.
Further elaboration (conversation, architecture meeting, story analysis,...) may
- split the user story
- make ...
4
"The answer to any sufficiently complex question is, It Depends"
In this case, I think it depends on where you work. Where I work (msft), I don't manage people, but I am at a fairly high "level" within the organization. I choose not to manage people because it allows me to do more of the work that I enjoy doing. I've never been a consultant, but I'm told my ...
4
Use whatever you are comfortable with. I'd suggest starting with something basic for recording notes like Notepad++. The important thing is to be able to keep detailed notes about your session, to setup a session charter, etc. Once you've got some practice with it, you can see what works and what doesn't.
I've used Rapid Reporter and Session Tester as ...
3
I currently work on a small team, where I develop test automation in essentially the same way that you describe. To develop effective test automation at the higher levels, you have to be able/willing/trained to quickly perform the scenarios manually before they are automated. Inevitably, defects will be uncovered during these manual runs. As a result, the ...
3
A test plan is worth creating if there is something that needs documented testing. It may be frustrating to see a test plan with only a few steps, but if you realize the purpose of the necessity of documentation, it doesn't matter how small the test plan is.
You should include whatever it is that needs testing. Whether it's an anticipated UI response to ...
3
Regression testing should ideally happen on every single code commit (and if you've got a good build pipeline, this means doing testing on every single build). This ensures that if a bug has been introduced in the latest commit, that it found as quickly as possible. If you only have to go back one commit to fix a problem, that's super easy to fix and ...
3
It sounds like you are slotting time for regression testing. A continuous automated testing approach would reduce your testing cycle. I'd look at designing your automation suite around this idea and run it nightly for GUI and service testing (or more if you are ambitious) while running unit tests on all builds. A nightly automated regression suite would ...
3
According to my view, "Scrum is the best agile approach. In scrum, each sprint produces an increment, which is a potentially releasable product. Here, each increment must satisfy all acceptance criteria and pass the different categories of tests. Regression tests are a tiresome activity, especially in an agile process, which is characterized by nonstop ...
2
On a true agile project the line between development and testing can become very, very blurry. A team that is properly implementing behavior driven development (BDD) will be automating acceptance tests as part of each feature.
There are pros and cons with this approach as each feature is not done until the automation is written, however the tests are ...
2
My company has been using Agile for a while so I can provide some answers.
First of all we do only black-box testing, we don't have the access to the code. Therefore each story has some technical sub-tasks defined and these tasks are handled only by developers. We don't test them.
As for the rest - we share all the tasks/stories (whatever you call it). ...
2
tl;dr
Read different blogs and people's perspectives while you build a set of practices that are best for you. Note that once you change a job, only a few of those practices might come with you. Don't get stuck with a few methodologies and practices marketed as the "best practices".
Long version:
"Best practice" questions will have numerous ...
2
The conversation about certification is a totally another topic, and I would leave it out of here. Certifications won't play a major or an important role in your career path.
Options are many, but mainly I would divide into management track and technology track. I have worked with CEO who was formerly a QA Engineer, attained his MBA and advanced to ...
2
I agree with Suchit, certifications and career advancement are very different.
The majority of Testing Managers I've worked for or with have had very little testing experience but were promoted for one reason or another. Some companies may prefer to hire professional managers (MBAs) for certain jobs while other companies would rather promote someone with ...
2
I think you want to find software engineers who are already interested in testing. Your job is to sell them on the company, the product, and the technology.
I have met several extremely talented software engineers who preferred testing to product development. Those individuals were invaluable. On the other hand, I have also known engineers who joined the ...
2
Personally, I would not sell it with the name you have. It implies you are making them only do testing, and if they are a software engineer you've already got your hands full trying to get them to want to do any testing of their own development, let alone a job that is completely about testing.
Instead, I would attempt to pitch this position as an ...
2
What you need here is to maintain linkage between your AC, your user stories, and the features - there are a number of test management tools to do this, which you can integrate with your issue tracking system (or not - provided you make sure your internal process includes flagging each item in the test management system with the relevant item in your issue ...
2
I'm a person who made the switch and I've worked on a team for two years which is primarily made up of SDETS. I was interested in it because I wanted to explore something new and I liked writing tests.
Hiring SDETS is very hard because you need engineering, quality and test expertise and they're seldom found in the same person. We find qualified test ...
2
As Suchit said, it depends a lot on the nature of the update. I've seen a one-line code change trigger a full regression because that one line happened to be in one of the core calculation engines.
My suggestion for any development process, whether agile or not, is to have multiple suites of automated regression tests running on at minimum a daily basis. ...
1
It really depends on what the small update is. It might be a small change but it affects a lot of parts of the system e.g. Updating something in the db.
The testing shouldn't be tied to whether it is a small update or a big one, however defined. It should be tied to how much you think is the effect of the given update. A small but critical update may ...
1
One more documentation tool for session-based test management for your consideration: qTrace
qTrace includes the option to capture and display timestamp associated with every screen and action along with user's action. Besides, the duration of the record is also captured. Also, the timestamp feature is available in free edition.
1
The answer will depend on your current employer, what industry they're in, how hard you are willing to work, how flexible you are, and where you live. While testing can be an interesting and rewarding job, there is only so far you can go as a tester. However, you can use what you learn as a tester to move into another kind of job in the same industry, e.g. ...
1
Welcome to SQA, Teague. Your test plan is part of a feedback loop. You convey something about the project to whoever is testing. They test the project, find some problems, and fail to find others. You incorporate what you observed into how you write your next test plan. It is all about paying attention and being open to changing what you do according to ...
1
It seems you already know the answer. We don't have automation and I can't manually test every build but when I test at the end I find problems too late (you should test them all the time).
You need to develop automation!
Notice I didn't say specifically test automation. Automation is really the key to delivering quickly. Adding pieces to your ...
1
I use Microsoft Test Manager and find that I center my test plans around releases. It might be helpful to have a separate Regression Test Plan with suites set up by product area that can be updated as code updates and so new test cases can be added as new features are implemented in existing product areas (or new product areas are added). There is some ...
Only top voted, non community-wiki answers of a minimum length are eligible
