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!

Six months as a ThoughtWorker

That’s a long time with no posts here! I must say that I had been amazed during the last six months, after I joined TW.

As I wrote in my last post, I couldn’t ask for better opportunity  - I was totally right! I like this feeling of “no regrets” that I have everyday when I reach the office. I’ll start talking about what happened after I wrote my last post. In that time I was working in a project in the national institute for space research. I got a scholarship for Jan. 2011 to Dec. 2012, the duration of the project I was working on. During my time there I applied to some master’s degree classes (Artificial Intelligence and Applied Computing) and I my job in that project was develop a framework in Java, using web services. I learned A LOT during the 18 months I worked there. 

 Although I was enjoying that, I was really looking for new challenges and opportunities to grow. 

I found this opportunity at ThoughtWorks, I applied for a QA role, and I got really really happy when I received my job offer. It was on start of March. However, I was submitting a paper for a conference  and I had a deadline to deliver part of the framework in the next months… for this reason, I asked for some time till get my new job. So, finally June came and the time to become a ThoughtWorker as well! Then I left the project before the end of that.

The thing is, joining ThoughtWorks was not only associated with leave my family in Sao Jose dos Campos, fly to another city (Porto Alegre) and start a new life over there… Accept the offer meant being hired in a day and fly on the next day to India for a 6-week immersion program called ThoughtWorks University (TWU)… It sounded a bit scaring in the beginning (mainly for my family – “whatta hell is this company that wants to send you for too far in your second day as an employee???”) _ but this opportunity made me wait desperately for June. I don’t have words to express how much happiness and anxiety I was feeling that time. 

I joined TW on June 4^th, and started my journey to India on June 5^th… I’m writing  another post about my experience at TWU.

My first day in the company was really funny – people invited the new hires to walk around the office, to meet the co-workers and know about the projects. It was weird – so many new faces observing us… They seemed to be planning something… maybe… wish us welcome, by launching hundreds of nerf darts in our heads? Yeah, exactly that! \o/ Definitely, it was the best way to welcome us, and it made me figure out how amazing is my co-workers 

 We had a day with a bunch of new hires orientation and we took the time to finish what was pending to our trip.

Six weeks later, I was back to Brazil. The company gave me some days off to organize my stuff to move to Porto Alegre. Actually my stuff were already organized, I took these days to stay at home recovering from jetlag and enjoying the time with my family and also to eat barbecue and my mum’s meal which I was missing so much!

So I moved, found a new place pretty (small) close to the office! I got assigned to one of the projects from the office and started my job as a QA. 

During the first weeks it was a bit hard for me… I was far from my family, Porto Alegre’s winter is pretty different from the  one I was used to, spend the weekends cleaning my place instead take my time to study and rest was not so cool, cook for myself, pay my bills, do the dishes, the laundries (mainly that time when I haven’t bought a laundry machine yet)… everything was new and hard! =)

But after a month I got used to everything. People are used to be excited about their new job just during the first days or weeks, after that everything becomes a routine and starts to let you bored… In my case was completely different – everyday in the office I face a new challenge, I meet new people (new hires and expats), I have the feeling that I had in my very first day! And that’s what makes me so happy and passionate about my job. The environment in the office is awesome, my understanding about Agile has improved a lot after joining the company - we really do Agile - it's not only about daily standups, work in pairs, send code to the CI server..it's about the way we work, the team is very collaborative, we're always sharing knowledge and another stuff that make us agile.

People in the office are really friendly, it’s possible to hear people laughing and some hipster songs playing during the day… people send spams by email inviting to a beer, to foosball and video games competitions. We work hard, but we can also have fun during and after work time!

Among the role we play into the project we get assigned to, we also have the opportunity to get involved with another activities, such as social impact programs (SIPs) that sustains TW’s third pillar – Social Justice.

In general these SIPs are projects that aim to help people and make the world a better place. Some recent projects from ThoughtWorks Porto Alegre were to help citizens to interact with the candidates on the last elections, and another one to help a village from Porto Alegre with their recycle program… that’s much more than deliver software – the coolest part of these projects certainly is to figure out  how this software can change lives, make people grow and get new opportunities to make their lives better.

I’ve been a member of our women in IT group – that’s also part of TW’s third pillar, and that’s our space to discuss actions to make the company a better place for women and to attract more women to IT.  I flew to Baltimore – USA on October, to attend on Grace Hopper Celebration for Women in Computing – the world’s largest event for women in computing. There was another opportunity TW gave me to spend a week at the event, attending to some talks, generally about women’s right, leadership and technical themes. I’ll post a post about GHC soon.

I’m also having a great time working on the project I’m currently assigned – and I hope I can finish what I’m writing about my job as a QA soon! (Yeah, I’ve splitted this post in another three that’s not ready yet! This is just the first part! Hahaha)

I’m having a great time as a ThoughtWorker, working with amazing people and having such amazing opportunities.

I’ll share my experiences here more often, write reviews for the books I’m reading and technical stuff that I’m learning.

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.

About my latest achievements

Well, after a long time with my blog out-of-date, I have some good news: I'm joining ThoughtWorks Brazil!

I passed for a long but enjoyable and challenging hiring process, with many interviews that evaluated not only my technical skills, but also my personal profile, such as my personality, aptitude, attitude and integrity. It was the first time I felt really assessed during a process to join a company (although I haven't have many experiences with hiring process – TW will be my first job!).

For those who don’t know, ThoughtWorks is a global IT consultancy that is really well known in the software development community. It’s being one of global leaders in enterprise Agile development services and seems to work really hard to attract and keep just the brightest, passionate and talented people working there! They take pride on their hiring process and now I understand why. ThoughtWorks inspires companies and professionals around the world by delivering high quality projects and contributing to open source projects.

 I have recently accepted their offer and I’m going to start with the company in June, with an awesome opportunity of going to India to be a trainer in an “immersion” process called ThoughtWorks University. It’ll be six weeks learning, facing challenges, and meeting awesome people from different nationalities and culture! I’m really excited to be joining a company with an amazing culture and working with so many brilliant minds!

I had a great time here at INPE, where I had the chance to learning a lot during this year of experience, but now it’s time to give a step ahead and face this opportunity to move from Sao Paulo to Porto Alegre to gain maturity and have the responsibility of live alone, and the most important: to start my professional career in a company like ThoughtWorks - I could not ask for a better learning experience!

I intend to post here my experiences while I’m in Bangalore and when I have a time for it!

So, that’s it! Wish me luck! =)

Business Analysts and their roles into an Agile environment

The business analyst plays a defining role in creating a single vision for the product out of a diverse set of needs and wishes from multiple stakeholders, by enabling a diverse group of customers to speak with a single voice.

They must constantly ensure that the project is able to deliver the maximum value for customers and adapting to the business needs, and the features requested by the users align with the product’s business goals, especially as the business goals change during the time.

The business analyst has a central role in ensuring that the product screenplay clearly defines the product’s strategic alignment to the business need. The analyst holds shared responsibility in defining the strategic criteria for completion of the project.

The techniques of business analysis don’t change dramatically in the agile environment, but the timing and how they are used do. Artifacts as personas and data models, for example, continue to be employed, but are kept as lightweight as possible. Low fidelity artifacts, such as diagrams, maps, and lists, provide more value to an agile project than long, textual requirement specifications. Low fidelity artifacts are used to build the software for a specific iteration and only need to be understandable to the team during the iteration. On the other hand, Long-lived artifacts should be used beyond the scope of the development. They should be used to communicate what the software does and why it does it.

Agile offers the opportunity for business analysis to benefit from the frequent feedback provided by the business, by reviewing the results of successive iterations with the business stakeholders, having the opportunity to refine the product’s specifications and ensure they are aligned with the business, and identify and reduce risk he project as soon as possible.

In waterfall projects, requirements are developed in their entirely prior to the development phase. As risk elements are uncovered and business needs evolve, certain requirements may change or be eliminated, which results in a waste of work. By providing just-in-time requirements, there is less rework of requirements because only the requirements required for the current release are define in detail and developed.

There are a variety of ways a business analyst can be engaged on an Agile project:

• In some projects a dedicated business analyst role is unnecessary. This is not to say that business analyst is not conducted during the course of the project, only that any member, or members, of the overall development team, may do it.
• In more complex environments the analyst might be the facilitator, bringing divergent business stakeholders together and helping them speak with a single voice so the project team are not confused by contradictory and conflicting perspectives.
• The analyst might act as the product owner/customer representative where they are empowered by the business to make decisions on product features and priority.
• The analyst could act as a surrogate product owner, in situations where the business product owner not available.
• The analyst might act as the second in command to a business product owner with limited availability.
• An analyst could take the role of business coach in an environment where the business product owner in competent and committed, but has limited IT project experience and the rest of the development team are lacking in domain knowledge.

One of the key elements for a business analyst working in an agile environment is the ability to use feedback to drive change. The BA must constantly review requirements with the business stakeholders and ensure that any shifts in business needs are accurately reflected in future iterations of the product. In an agile environment, the success of the business analyst depends on his interpersonal skills as communication, facilitation, coaching and negotiation.

Acting like the “bridge” between the development team and the customer, the business analysts should constantly think as a customer, primarily on the time of:

• Acceptance and evaluation criteria definition
• Business rule analysis
• Functional decomposition
• Interface analysis
• Non-functional requirements analysis
• Problem tracking
• Prototyping
• Requirements workshops
• Scenarios and use cases
• Scope modeling
• Survey/questionnaire
• SWOT analysis
• User stories 

Agile business analysis is related to increase the delivering of business value to the customers of the project/product to be developed. To be productive on an agile team, business analysts are active participants, if not the actual facilitators of planning, analyzing, testing, and demonstrating activities.

Business analysts play a key role in facilitating a shared understanding of the business need for the project with all the stakeholders. It is the role of the business analyst to ensure there is a share, agreed vision of the product across the entire team. This requires the analyst an extremely high level of skill in communication, facilitation, and negotiation. In addition, they should have the ability to listen and understand feedback from all stakeholders and use this feedback to drive the changes required to the requirements and priorities of the project. In the agile environment, understanding and synthesizing perspectives alongside the ability to hold successful conversations replace the need for formal, detailed, long-term artifacts such as requirements documents.

In a brief, Agile Business Analysis is about ensuring the right information is available to the development team in the right level of detail at the right time so they can build the right product.

To read more about Business Analysis, I recommend the BABOK® Guide as a great source! Enjoy!

The Art of Gathering Requirements

On the Waterfall model, software requirements are gathered together with the customer on the beginning of the project, and become pages and more pages of documentation. However, customer’s needs and wishes changes during the project, thus, lots of those requirements gathered, in most of situations, have already been developed, are lost.

Instead the Waterfall model, on Agile, requirements, wrote down as user stories, are gathered all over the project. In addition, Agile methodology values the face to face communication. When it doesn’t happen, the requirements were gathered ambiguously and wrongly. A good example of this is illustrated bellow.

User stories are short descriptions of functionalities that the customer wishes in its software. Generally, they are write in small index cards, in order to write just the necessary on that in a low level detailed, because the stories tend to change over the project. Some stories, called constraints, act as checkpoints/test criteria on the project.

User stories can be gathered through some ways:

• User interview
• Questionnaries
• Observation
• Story Writing Workshop

Story Writing Workshop

A story gathering workshop can be composed by the follow steps:

• Get everything on the table
• Identify the customer
• Define the Project
• Create the inception deck
• Analyze the NOT list – a document, part of the inception deck, which is defined together with the customer, in order to specify what’s in and what’s out of scope on the Project, as well as those customer’s expectations that haven’t been decided yet. It’s important to keep the team focused on the real desire of the customer.
• Brainstorm
• Define roles and personas
• Create mockup screens
• Create flows and other design elements
• Write the user stories
• Brainstorm everything else
• Create User Acceptance Tests (UAT)
• Create the production support documentation

After these steps, everything should be writing down in cards and then they must be prioritized and treated as deliverables for the project. As we are talking about Agile, all these deliverables will be splitted into iterations and, working together with the best practices of Agile methodologies, will ensure the quality of the product and the client satisfaction.