Qa Consulting USA

I’ve been reading about and getting involved in conversations on the difference between a traditional lifecycle tester and an agile one. As the way projects with these type of people differ quite drastically in places, there are plenty of ways to describe what an agile tester is - I’m going to stick my neck out and mention one,  a developer of tests rather than production code . It’s a sweeping generalisation because there are a lot of software quality assurance tasks that an agile tester does before they touch an automation tool - they have to work with the team to define the acceptance criteria of the user stories, define and document the test environment to be used, perform exploratory testing on whatever code is available, review developed functionality etc. However once they’re ’settled into’ the sprint there are developers performing TDD and producing code in a Continuously Integrated Environment and testers producing test code to ensure business-level descriptions/req...

I still find it strange that companies unfamiliar with Agile automatically view it as being a methodology that pays no heed to process or ensuring quality of output. From my experience the quality is actually a lot better, the timescales set are achieved more readily and everyone involved has a much greater understanding of the product and its development status at any one time. At present I´m working on a project where I´ve had to split the test team into two due to several companies working to build a complex product together. One team is performing agile QA in a sprint team, the other is working ´the old way´. It´s very interesting to note that all the worry and uncertainty is coming from the team working with the traditional model due to the fact that timeframes having been guesstimated months ago about environments, data and functionality that no-one knew about then. As time marches on we appear to be spending more time in meetings discussing what we once thought was go...

There is a lot of documentation available on agile methodologies, both on and offline, detailing processes to introduce and how best to organise teams etc. This information is very useful for people/ software testing companies wishing to change the way they work, but a key principle needs to be there beforehand - discipline. Without the discipline of staff receiving new process ideas and actually acting on them, it’s a lost cause from day 1. Many very intelligent people have voiced some fantastic ways to use agile in certain circumstances, when to perform xyz, how to react to abc and when not do anything, but if the people involved do not ’stick to the programme’, failure beckons. With this in mind, how can a team be ‘energised’ into willingly accepting change and, probably most importantly, continuing to work with this change as the weeks pass by? From my perspective, it firstly requires people who are open to adopting new practices, who are willing to give something a try an...

I’m interested in defining the best metrics to use for checking whether the product quality is improving as time, and sprints, pass by. One obvious factor is the number of automated tests passing in the continuous integration builds related to the coverage of functions in the code. Or is it? Do the tests literally show the product quality? What if the finished article isn’t what the customer wanted? There are then a suite of tests making sure that the software does something it’s not meant to. Number of defects? Measured against what? The list of possibilities goes on, what I’d like to find out are tried and tested measurables. Does anyone have a list they use in every project? Update by Kenny 08/11/09 :- Ok, I’ll try and answer my own question here (the power of reflection!). There are two scenarios in projects which require different solutions in relation to metrics gathering. They are :- 1) A project run using mature agile methodologies from day 1 2) A project which ...

Well, it’s been quite a while since I posted anything and in that time I’ve since entered a new software producing environment. It’s working with agile again, which is great, but has a change to my existing experience in the area as there are multpile projects producing multiple products. At the moment numerous teams (containing the usual mix of product owner, scrum master, developers and user experience personnel) are working on their product. There is a Outsourced software testing services team who’s task is to provide resources to all - and yes, the usual story persists in that there aren’t enough of us to go round! So this raises the question, how to provide the best possible QA services when you can’t work on a project 100% of your time? I know, one of the key rules of agile is being broken here i.e. the project team can not be interrupted during sprints. In an ideal world we would simply add sufficient QA people to be able to maintain the continuous creation and maint...

Through the evolution of the practice of QA in agile teams, a high degree of quality can now be added to product development. Not only can thorough tests be designed, written and executed within a single iteration, the use of post-mortem analysis allows for team reflection and, as a result, process improvements. So how best to perform QA in say a two week iteration? One way is as follows :- * The user stories are chosen and the team members select which tasks to perform from this. * Developers are given the morning to sit and work out which unit tests and low-level functional tests they will write. The QA person then meets and discusses this with the developer, finding out (at the high level) what the expected functionality is. * The QA person has the opportunity to request that the developer adds more tests to the suite, change existing ones, etc - the idea is that a QA input has been provided before the developer writes a line of code. * Agreement is made and the developer s...