Please wait while we process your request.
Please wait while we process your request
Please wait while we retrieve the user's information
Your bio is currently empty. Now is a great time to fill in your profile.
This profile is private.
This profile is only shared with friends.
This profile is under review.
We were unable to request friendship with this user.
We were unable to request friendship with this user. Are you logged in?
Your friendship request has been sent to this user.
We were unable to terminate friendship with this user.
We were unable to terminate friendship with this user. Are you logged in?
You are no longer friends with this user.
We were unable to ignore this user.
We were unable to ignore this user. Are you logged in?
This user is now ignored.
We were unable to stop ignoring this user.
We were unable to stop ignoring this user. Are you logged in?
This user is no longer ignored.
We encountered a problem recommending this user.
You have recommended this user.
This blog post is hidden because you have chosen to ignore Marni Tolle. Show Details
This blog post is hidden because you have submitted an abuse report against it. Show Details
Something that is essential to my QA team's success in ensuring efficient and effective use of our time while verifying our high quality product is having us involved early and often in the entire development life cycle. While we could just be left at the end and handed work from development once complete, there are so many points along the path where our involvement helps to reduce wasted time in our actual testing phase of the product. The approach that we use in testing Pluck internally can also be applied to your process when integrating Pluck into your own environment.
When I say early, I mean from the beginning. QA teams are experts on the in's and out's of the product. From the first sprint planning meeting we have our team present to help discuss and become aware of the stories (Agile term for an item in the priorities list) from the backlog that are being taken by our development team counterparts. Much like when our customers have to integrate our product into their own, third party integration with tools such as Pinterest come up in our queue as well. Knowing this information early so we can do the proper research on the API and error messages related to the functionality we will need to utilize is essential to allowing us to stay in step with development and be ready for the work that will be passed into our own queue. Besides that ability to plan accordingly, giving QA the chance to voice their expertise early in the process can ensure that we often think about side effects or pitfalls that we might have encountered before.
After the developer has come up with their design, a QA team member is again present for the design review/brainstorm session. Often the developer has come up with different concerns that might not have been thought of in the original sprint planning meeting. Many might think that the QA team's input at this point is trivial and I won't disagree that sometime that is the case but there are numerous examples where we have made suggestions or brought up possible situations which if not taken into account before the actual development began would have resulted in many more man hours utilized in finding, debugging, and fixing said problem making the cost of involving in this stage much lower than dealing with the problem after it has been moved to the verification phase.
At first opportunity, the QA team then begins to come up with an outline of the test cases for the particular feature. This is not a deep dive with exact step outlines but more a brainstorm phase on our part with a summary outline of each test case we plan on running. Just as the developer looked to the team for feedback on their design, we also send our test plan out for approval to the engineering team. Again, getting this in the hands of the developer as early in their process as possible can help them think about situations that they might not have accounted for otherwise during the implementation. And of course, we don't discount the incredible input we get from our product management and development team as to what we might have missed or providing more color on what is to be expected in the results.
Obviously when development is complete we are the primary players. The sooner that our QA team, and yours, is able to pass back any work to the development team the better. Again the main concern here is keeping things efficient. It may take our QA team the same amount of time to test a feature but the sooner you begin, the less time a developer has had to separate their brain from the work and move on. The larger the delay in feedback to the developer, the longer it will take them to reacquaint themselves with what they implemented.
We're sorry, we were unable to record your recommendation at this time.
We're sorry. We are unable to delete this blog post at this time.
We're sorry. We are unable to block this blog post at this time.
We're sorry. We are unable to unblock this blog post at this time.
Please wait while we file your abuse report.
We're sorry. We were unable to report abuse at this time.
We limit the number of reactions an individual user can submit over a given period for quality reasons. You have currently reached that limit. Please try resubmitting your abuse report again later.
Comment is too long. Enter 500 characters or less.Send Cancel
Please wait while we send the email.
You may send this to 5 e-mail addresses. Please separate each address with a space.
vote upvotes up
vote downvotes down