My first talk in a test event

Last Wednesday (Feb 20th), I presented at 33th Test Birthday Event in Sao Paulo! It was very cool! A great experience for me...

There's a long story behind, that I should tell you:

I was looking for a first event to start talking, to be more active on this! And then, few weeks ago, a friend of mine (Camilo Ribeiro - QA Consultant and blogger at Bug Bang Blog) told me about this event (33th Test Birthday) and I got interested in go and present something. As I didn't have enough time to prepare my own presentation, he suggested me to use the slides that some ThoughtWorkers presented in another event - Como Mariana se tornou uma Agile Tester.

So I sent this one as a proposal, and Camilo submitted a presentation about Lessons learned with Performance Tests.

Last week we received the list with the talks approved, and I was not included on that... Never mind (I thought!), I'll have more opportunities and even more time to prepare my own presentation and to prepare myself to present! 

http://www.iterasys.com.br/aniversariodoteste

But things changed on the last Monday night, when Camilo sent me an email telling that one of the most expected talk of the event had been cancelled and the organizer was asking to include me instead . I got surprised with the huge responsibility that I was assuming by saying ok for that, because I was not preparing myself, and my lack of experience with Waterfall model (and Agile as well!) would made my life hard to compare both models clearly and detailed, following the content of the slides, or talk some bullshit and would not be able to explain! hehehe

Then, I asked Camilo to pair with me, to help me with the waterfall part of the presentation, so that I would be more comfortable to present. Another fear was about our synchronization with the slides, considering that we didn't have time to present together in advance. We were supposed to have an online audience and we had to be synchronized for a clearly understanding.

Anyway, despite all these challenges and fears, we presented for 50 people (online and face audience). It was cool because, even we hadn't tried to present together in advance, we could synchronize the presentation very well, complementing the thoughts of each one when necessary. After the presentation, people came up with some questions related to how to use Agile in distributed teams (teams splited in more than one country, challenges with timezone etc) and also how to make developers more concerned with testing and quality. In both questions we could share our experience at ThoughtWorks, working in projects with distributed teams (San Francisco - Porto Alegre, India - Sao Paulo - Porto Alegre and Sao Paulo - Porto Alegre).

People got interested about ThoughtWorks and gave us a nice feedback about the format of the presentation (according to them, very different from what they're used to see in other events).

Very proud of my first experience in a big event and looking forward to present in Agile Brazil this year!

Quality Analysts and their roles into an Agile environment

Thanks to the software testing, many drastic changes have occurred on the software development – more and more the development team is getting value from testing, i.e., they are adopting test as a habit, always worried about create test cases in order to verify if what as desired was delivered.

Additionally, the concept of quality analysis in traditional software development is not only related to the write tests just in order to ensure the quality of the product. It’s more comprehensive than this. In Agile, the concept involves the effective software analysis also related to verify if what has already been developed is in total conformity with which has been specified, and, consequently, in according to the customer’s desire.

While I was searching for some references to write this post, I find a very interesting presentation made by Syed Rayhan from Code 71, about the role of a quality assurance in a Scrum project. During the introduction, he brought some questions about the effective role of a QA. I sent him an email asking for some comments about these questions, and I’ve included his answers throughout my post below.

·  Is QA part of the development team?

·  Can we fit QA in the same iteration as development?

·  Who does QA?

·  Does QA costs more in Agile as product seems to change from sprint to sprint?

·  Do we need “test plan”?  

·  Who defines testcases?

·  Are story acceptance tests enough?

·  When do we know testing is done? 

·  Do we need to track bugs?

QA plays a dynamic role into an Agile environment – he must be active since the start of the project until the software release, working together with the developers and product owner(s) to define test cases and acceptance criteria. Although Agile testers are developers, they have a specialized set of skills.

Even though, developers can write tests (not only unit one), but QA could have the mindset to write some of the other required tests.

However, in order to increase the success rate of the project with Agile, developers and testers must be part of the development team and need to be fitted in the same iteration, it is good for testers have test automation as their core focus and not only manual testing.

A team organized like this way means more quality to the software, because it will be tested in small pieces, and the team can receive a faster feedback about what is going wrong. The picture below shows the difference between a traditional the software development model and how it could be in Agile.

                 Traditional Software Development

Agile Software Development

And NO, QA doesn’t cost more in Agile! It may seem that teams spend more time retesting, but it is a necessary evil. The earlier we can catch a bug, the better. We end up spending less time in the long run. In fact, with the right amount of test automation, we would spend less time in testing for the same level in the long run. QA will help the team to verify earlier if what's being developed is exactly what the customer needs/wants, as well as help to track bugs and other vulnerabilities on the software. It means less rework at the final of the project; less chances of exceed the budget and the time.  

The QA role within an Agile environment seems to be contradictory, because of the tools and process used are their working tools, as well as all the documentation. But when we talk about documentation in Agile, we are referring to a lightweight documentation, e.g., acceptance tests would help the team to document what's supposed to be developed, and it's the way to have a living documentation. But these acceptance tests aren’t enough to the process: a QA must have his test cases and tests scripts as part of the documentation, in order to help the team or another QA to perform a test that has already been done, without spending time in rewriting that. 

Furthermore, it’s also important the bug tracking. Usually teams track bugs after a feature is delivered. During the development of the feature, it depends on the team. Informal interaction between the QA and the developers might be easier. 

I extracted a figure from the Syed’s presentation, showing the responsibilities of each role of the team in perform the different types of tests:

The quality assurance plays a critical role to the success of the project; however, it is not the key to ensure the quality. The quality is responsibility of each one of the team, since the requirements gathering till the success of the tests performed by another members of the team (devs, support engineers, performance engineers etc.).

QA works together with the developer, the business analyst and also together with the customer, gathering requirements and writing the acceptance tests, always aware of what’s been developed and ensuring the release of quality software generally every two weeks.

The picture below shows clearly the role of a QA in a project:

The main responsibility of a QA is to make sure that the right software works right. 



Since the team is self-organized, QA is not a designated person’s responsibility – it’s a team’s responsibility, and they should collaborate together for the success of the project.

Thus, it’s important that the requirements are very well specified without noises in its writing which may cause misunderstandings. If it occurs, this noise should be mitigated as soon as possible together with all the others members of the team – BAs, developers etc. – this is the main purpose of Agile. 

The testers know that the less time there is to test, the less they will be able to test. And the less testing they can accomplish, the less the organization will know about the software before it’s released. Less information means more risk.