Tag Info

Hot answers tagged

10

An answer - as Phil implied, is that you take every record and playback tool you can find, and burn them in a fiery pit of despair. I probably got myself a down vote for that, so I'll try to earn it back. Good Agile teams test constantly - not just at the end. If you include test design as part of feature design (and consider how the feature will be tested ...


8

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


8

I second (third?) the congratulations! While I'm nowhere near as experienced as Joe or Bruce, I can offer a few tips from experience: Communication is critical - you absolutely must have at least an instant messaging application to talk real-time with your team. That application should also be something your development team is using since you want your ...


7

It really depends on what you're trying to achieve with your automated tests. The answer should drive your approach. Are you trying to: reduce regressions? reduce the amount of repetitive manual checking your testers have to do? (This may be the same thing as reducing regressions.) please a manager with some magic numbers? Some ideas: Test first. Make ...


6

In my opinion, there aren't any extra skills need to test a stable system. What tends to happen once the system is stable and not under continuous development is that the proportion of time spent on exploratory testing drops compared to the proportion of time spent on regression and checking. I'm assuming here that by "stable" you mean that the requirements ...


5

I would start with what you have, the inputs and outputs, then start questioning. I like to go through a bunch of what if's, such as in your case "what if the database is unavailable?" or "what if the mail queue is full?" or something like that. If you can't come up with questions like that, then ask the developers "what didn't you test that you think I ...


5

There's a few extra factors here that can impact the way you handle this problem: Do you get results for each test as it completes or do you have to wait until all tests complete? Do you have multiple machines on which to run the tests (and is it possible to do this) or are you tied to a single system running your tests in sequence? Can you break your ...


5

It depends, and there are no industry standards. Seriously. Any metric can be gamed (and will be, if you use it for assessment). I'm not aware of any standard approaches, not least because the teams are - or should be - evaluating themselves regularly and looking for ways to improve their own processes (if they aren't then they're probably using ...


4

Well, firstly I hope you've been building up a decent test library as you've been going else there's a lot of work in re-building a regression test pack. Better still, I'd hope that while working with the Dev's you built up an automation framework (or at least 'bunches of scripts' that could be used in a future framework) per sprint. Not doing this ...


4

As ByteBuster indicated, user stories are a very high level description of a goal an actor or customer wants to achieve with the product, but doesn't detail exactly how that goal is going to be achieved. Developers often break user stories down into discrete development focused tasks that are necessary to achieve that goal. Developers should also be ...


3

Congratulations! Here's a list I used last time I took a new position: http://www.allthingsquality.com/2010/04/qa-leaders-checklist.html It's pretty hard to know what you should expect, since every situation is different. Instead of anticipating, try to determine how you will go about learning what you have actually gotten into.


3

As the other answers have said, you will probably not test the user stories directly. The method I've used in the past works like this: Each user story will have one or more acceptance tests. These tests typically cover a high level test scenario (such as "Given that I am logged in as a customer, then clicking the link 'My Orders' takes me to a page ...


3

Issue Reports (Bug Reports) are one of the main communication methods that QAers use. You are creating a statement to your stakeholders - "I have found what I think is a problem, and here's my clear explanation of what it is and how you can see it too. Please look into this". Understand the Audience for the Report It's important to know who is going to ...


3

I think Agile testers should assist their Product Owner with writing Acceptance Criteria in the user stories. If you write scenario's in Gherkin you can create manual test cases that match your four criteria of a test. Scenario: Some action (1. Name) Give I am logged in (2. Pre-condition) And I setup something else When I do some action (3. ...


3

Depends on the quality requirements of the project and the maturity of its user stories. If the test has to be done once by the same person who has written the test cases, then documenting the test case steps would not be essential or indespensable. On the other hand, a project requiring different phases of regression testing over a long period of time with ...


3

When you say that bug triage is impossible (or improbable), you need to determine the opportunity costs associated with that: In the case where no triage is performed, there is the probability that a single or multiple developers will attempt to fix the same bug. At minimum, there is wasted development time that could be focused on other areas. Worse, the ...


2

Bug triage is very important, especially when time is limited. Bugs have different levels of severity. Examples include very high: someone may die as a result; high: the company may lose business; medium: the customer will be upset; low: there is a minor spelling mistake. The actual outcomes and severities depend upon the organisation. Bug triage is about ...


2

I think you might have got yourself a bit confused here. You're not really testing the software's suitability, you're evaluating it - that is, you're looking at how well the process and workflow the software imposes meshes with the development framework. It's not so much a pass/fail thing as whether this tool is a good choice with this methodology. For ...


2

Have you considered using post actions to either pull the UATs from the tasks or push the UATs to the task? This is relatively easy to accomplish if you have some experience of configuring your own workflows. It allows you to generate the tasks required based on the Acceptance Criteria (i.e. each would create a new task) and copy the details of that into ...


2

There is a very relevant whitepaper here that you should read. It raises some excellent points. Whilst I don't want to be negative, or scare you, your situation will be VERY challenging as you have to contend with the following: Learning your new role and your lack of testing experience. Communication with and governance of the offshore team. Working in ...


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. ...


2

It sounds rather like you have the typical "agile-but..." implementation going. There are ways around it that avoid the overhead and issues that go along with GUI-based automation (which can be done without record/playback - the things I'm doing with Microsoft's CodedUI right now were probably never considered when they devised the tool). A few thoughts ...


2

The Assumption "Agile is iterative and many test-last tools are record and playback-style" is incorrect Tools are developed / adopted for managing repetitive tests, reusuable tests The feature developed might be in iterative phases, In such cases automation need to be developed for stable feature Automation has its own resource allocation, planning and ...


2

User Stories are the highest-level requirement artifacts in the software development lifecycle. Here are some examples of User Stories: As an application user attempting to save the document, I want to see a warning if the desired document name already exists; The warning should allow me to choose whether to overwrite an existing one; As an Web site ...


1

A lot of your question talks about the tools, Jira, source control, etc. I think you are letting the process that the tools facilitate is guiding your thinking too much. If you read Liz Keogh, she repeatedly talks about the conversation that you need to have in order to fully define and form your ideas about the feature that you are developing. I think ...


1

As a system of systems, black box really doesn't have a meaning (except what it means to you in your context). Let's take your last statement at face value, that the developers have unit, integration, and system testing well covered. I assume your question can be rephrased as "Give me some ideas for contributing to the team!" :) Ok, here goes: I assume ...


1

I write automation code with Robot Framework in an agile development environment. So long as you have an idea of the implementation of the code in test, you can write automation scripts before the code is deployed. This should be an exercise in logic and workflow. Once the code is live you can update your script with specific identifiers for each keyword. ...


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

As a former tester and now a QA Manager I have worked for over 15 years testing and managing the testing of very complex Geology and Geophysics interpretation software. My test team are all geoscientists first and testers second since you have to have an advanced degree to understand what the software is doing. I worked on a team using RUP, and we were ISO ...


1

With long term projects (2 to 3 years already completed) and if there are 100's of old test cases, we are doing the following for 'Master' Regression and Iteration Regression Master Regression - would be a big set of test folders with merged test cases under each functonality and the new functionality or changed functionality will update existing test ...



Only top voted, non community-wiki answers of a minimum length are eligible