Showing posts with label Behavior Driven Development. Show all posts
Showing posts with label Behavior Driven Development. Show all posts

Monday, August 15, 2016

Software testing is changing in agile world but what all is changing?


Agile Testing
What is testing? Checking software to ensure its meeting customer requirement or more? Who is supposed to test? Tester only? What qualification needed to become tester? Automation testing or manual? What is the role of tester is agile? Is there a room for manual testers and testing in agile? Confused?

Many questions but no concrete answer. Testing is important and not just what testers do but much more than that. Team spent more than 60% time on testing. Surprised? Think again - unit testing, functional testing, regression, security, load, integration, customer and acceptance testing etc.

I have scheduled 2 days FREE workshop on Agile Testing in Delhi on August 27-28 to explore all above as well to learn more about specification by examples, bdd, tdd, DevOps, CI and many more. This workshop is free but not venue so you have to pay INR 3000 for venue and food. You are most welcome if wanted to pay more.


More information with registration link - http://agilemania.com/event/agile-testing-training-new-delhi/

Reach out to me if looking for Agile Workshop for Developers and Testers. 

Friday, May 20, 2016

Everyone is developer in development team and not just a coder, a tester etc. Are you kidding?

Scrum is very simple framework to develop complex software product in complex environment but hard to practice. But why? I am not going in details of why but wanted to highlight one problem about development team as per my understanding.

Development team means cross-functional and self-organizing team of developers. But who is developer? Isn’t it everyone who contribute to develop software? A coder, tester, dba, UI designer, content writer or business analyst? Now look at your team. Is it cross-functional? Yes you have because you have technician for all skills but are those technician developers? May not be. There are just a coder, a tester, a dba, a ui designer and waiting for their skill related task. They are not working as developers with goal to develop software but they are just doing their task as per their skills.

Some of the key things that will help you to understand about development team. Think about L&D organizing few training is going to announce it.

1st announcement “we are planning to have workshop for Scrum Developer so send your nomination”. You will find that only coder has subscribed for this workshop.

Another announcement “we are organizing Agile Testing workshop so send your nomination”. This time only tester will subscribe.

What reflect above? Team is still divided in coder and tester. Tester feels everything related to testing is their domain and similarly coders feel all coding work is part of their work.

But reality is tester has to write code in order to test production code and coder has to write test to perform unit and integration test of code.

Another way of looking at it.

During sprint planning team prepared sprint backlog. Below is sprint backlog and now what it reflects? There are tasks but those tasks are skills based and not component. Isn’t it bad way of creating task? No? Then look below situation.
Assume there are 2 people Alex (coder) and Martha (tester) working on these 3 stories.

Alex done with coding part of story 1 after 2 days and Martha has started testing so what Alex will do next?

Most likely Alex will start working on coding part of story 2. Is it good? Why can’t Alex picks up other work from same story? Or why Martha was waiting for Alex to complete coding in order to start testing? Why can’t she pair with Alex to test in parallel or at least started testing APIs?

Many people asked me what’s wrong if Alex start working on coding part of story 2. Let’s see below situation.

Alex completed coding of 1st story and started coding 2nd story. Martha still testing 1st story found a bug so what she has to do? She reached out to Alex and wanted to discuss about bug but Alex is busy and asked her to come later on.

What do you think Martha will do next? Most likely she will open a bug tracking tool and log newly found bug over there. Is it good? No but why Not? I will write about bug logging challenges sometime later on but let's focus on other aspect of it for now.

After a day Alex is done with coding of Story 2 and started looking into bugs those were logged by Martha. He identified route cause of a bug that requires to change some framework level code. But that will also impact 2nd Story code that he has just completed.

What Alex will do? It is good if he go change whatever needed in order to fix at route but it will generate rework and will delay delivery. Other option is shortcut to fix bug (patch work) that will not have much impact on Story 2 code.

Majority of the time coder choose 2nd option because coders are very emotional about their code but result of shortcut will be “Technical Debt”.


What can be done in order to avoid such scenario? Yes. 1st don’t break story like above but try to divide in component. Best is not to divide but still dividing then divide in component. Work in pairing. Team should focus on finishing one that already in progress rather than starting new story.

Friday, April 1, 2016

How to earn 70 SEUs for FREE to become CSP (Certified Scrum Professional) in shortest possible time

Here is details about free SEUs for CSP (Certified Scrum Professional)

Category ‘A’ – Category A has a maximum limit of 45 SEUs, you can earn these by attending Scrum Alliance events. These events can be Scrum Global Gathering, Regional Gathering, Scrum Alliance Sponsored event and User Group event.

Scrum Bangalore organize full day event in Bangalore every quarter and now have started in Gurgaon, Discuss Agile regularly organize meetup in all cities, PlayScrum also organize meetup in Pune, Chennai, Delhi and Bangalore.

Basically, if you plan well then you can earn 20-30 SEUs in 3 months easily. I believe that’s good enough for this category.

Category ‘B’ – You can earn unlimited SEUs in this Category. But those will be paid. In any case, you need at least on Certification from this category to apply for CSP. Certified Scrum Master (CSM) gives you 16 SEUs, Certified Scrum Product Owner (CSPO) gives you 16 as well and Certified Scrum Developer (CSD) gives you 40. Ideally if you complete all these 3 roles based certifications then you get 56 from this category itself and don’t need anything else. I strongly suggest everyone to attend all 3 workshops before becoming CSP. Because you are planning for next level so it does matter that you know every roles and respective responsibilities in details.

But I said free SEUs for CSP so assuming you will only have 16 SEUs from this category either for CSM/CSPO or CSD.   

Category ‘C’ – You can claim 15 SEUs under Category C by attending any agile/scrum program such as PMI-ACP, Kanban, SAFe Agilist, Advance Scrum Master, SAFe Scrum Master, DevOps, Test Driven Development, Behavior Driven Development, and Specification by Examples. Again these will not come for free. So look for either DevOps meetup in your city or meetup on product management or lean management. You should be able to earn 15 in 3 months easily. If need help then write to me.

Category ‘D’ – Through voluntary work you can earn 15 category ‘D’ SEUs. Help ME in organizing next meetup in your company and you can claim 15 for same. If that’s not possible then check with local user group community in your city and extend your help in spreading agile/scrum knowledge by working with community leader and you can claim 15 in next 3 months.

Category ‘E’ – Read 3 books (my favorites) 1st – 5 dysfunctions of team, 2nd – The Phoenix Project and 3rd Scrum – A Pocket Guide and claim 15 SEUs for free in this category.

Category ‘F’ – Up to 15 SEUs may be earned through a variety of other collaborative learning activities engaged in with other Scrum practitioners. Best example attending webinar organized by us. Now every month we are facilitating 3 hours live online session on advance topic for free. Join our sessions for free to learn and earn SEUs.  

So here you are in 2 months:-

Category “A” – 14 (1 full day, 2 meetup)
Category “B” – 32/40 (Either CSM+CSPO or CSM+CSD)
Category “C”– 06 (2 meetup on DevOps/Docker/Lean)
Category “E” – 15 (Reading my 3 favorite books) 
Category “F” – 15 (Attend either Atlasssian hangout or join our online live session)

Total SEUs is 82-90 in next 2-3 months :)

Write to me on naveenhome@gmail.com in case you have any query.

Saturday, February 20, 2016

Yes, empirical process control helps but what is empirical process control?

I was talking to my friend last night about a meetup that she hosted yesterday. I asked what was expected outcome from there? Her reply was not clear to me so I was worried and tried to dig it deeper and found meaning of DONE is not clearly defined. Meaning process as well outcome is not transparent enough to see through what's going on. Is it OK to say that setting expectation from each and everything what we do is not good? I believe NO because if we don't set expectation and measure result then may not be motivated to do it again or improve it further.

Transparency is key for empirical process control and defining DONE helps in making outcome transparent. Since DONE is not defined so it will also become difficult to inspect outcome. If we cannot inspect then will not change plan and adapt it. 

If we are doing something then we should know why we are doing? What is expected outcome? Can I measure outcome? If not then is it worth doing? What is opportunity cost? Good to struggle with these questions rather than just executing something that can't be measured.

Last year we sponsored an event and we were expecting to have 300 people attending but there was only 50 people so we decided to stop sponsoring such events in future and figure out other way of promoting it. Spent same amount this year to host an event rather than sponsoring. Result is better than last year but still have to review as team to identify improvement areas or may be totally new things.

Yes it is very much important to set DONE criteria for what we do in order to improve ourselves. Things will not improve until we review and retrospect. Hoping it will improve automatically over the period sound very adventurous but talk to people those are on adventurous journey, they review outcome much frequent than others. 

Sunday, January 3, 2016

Can BDD help in slicing complex story?

What is Behavior Driven Development?

Behavior Driven Development (BDD) is well known practice for collaboration and many organizations practice it to bridge gap between in product management and software development team.

BDD help in describing requirement in the form of feature file and scenarios. Scenarios further get describe in format of Given, When and Then. The language that mainly used in writing feature file is called is Gherkin. Gherkin language can be used to write feature file in more than 40 languages. Some of the important keywords of Gherkin mentioned below that will help in describing features and scenarios:-


Feature, Scenario, Given, When, Then, And, But, Background, Scenario Outline and Examples

How to write Feature file?
You can write feature file in notepad as well so basically there is no need to know any particular tools and below is format.

Feature: Search Flight
As a flyer I want to search available flight between Bangalore and Chennai So that I can book to travel on given date.
#above story/description is optional
Scenario: Search all available flight based on date, origin and destination
Given flyer enter travel date as “12/12/2016” and origin as “Bangalore and Destination as “Chennai”
When Click on Search button
Then search page should show all available flight
And option to book flight

When to write feature file?
If you are practicing Scrum then better to have it during product backlog refinement session else make it mandatory for requirement gathering.

What is complex story/requirement?
Take above example of flight search, this looks very simple but can it be deliver in 2 weeks of sprint? May not possible if you have to complete all work that has been mentioned in Definition of Done (DoD)? So how to slice it to have shippable product at the end of sprint?

Use BDD scenario like below to slice it. Now change scenario to search flights only for one airlines at time because connecting multiple sources may not be possible in one sprint and modify it like below.

Scenario: Search only Indigo flight based on date, origin and destination
Given flyer enter travel date as “12/12/2016” and origin as “Bangalore and Destination as “Chennai”
When Click on Search button
Then search page should show all available flight
And option to book flight
Scenario: Search only Spicejet flight based on date, origin and destination
Given flyer enter travel date as “12/12/2016” and origin as “Bangalore and Destination as “Chennai”
When Click on Search button
Then search page should show all available flight
And option to book flight
Scenario: Search only Jet Airways flight based on date, origin and destination
Given flyer enter travel date as “12/12/2016” and origin as “Bangalore and Destination as “Chennai”
When Click on Search button
Then search page should show all available flight
And option to book flight

Now team can decide to build only those scenario that can be delivered within one sprint and rest scenarios in upcoming sprints.

Above scenarios can also be further sliced like below if needed.

Scenario: One way flight of Indigo
Scenario: Return flight of Indigo
Scenario: Multiple location search for Indigo etc.

Hope it is useful and if you have further query then reach out to me on naveen.singh@leanpitch.com

Leanpitch provides the best scrum and agile training. We are leading provider of Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Certified Scrum Developer (CSD), Kanban , Test Driven Development (TDD), Behavior Driven Development (BDD) in Bangalore, Chennai, Mumbai, Pune, Delhi and Hyderabad. Visit our website to know more about Leanpitch Offering.


Saturday, February 7, 2015

Agile engineering is not just important but essential for higher ROI

Agile has become popular within software industries not only in product development organizations but also within software service organizations. There are many factors that driving this change including time to market, continuous change in requirement, increase productivity and better accountability etc. 
Agile get defined by Agile Manifesto and Agile Manifesto consists four values and twelve principles. It is easy to remember four values but not always easy to implement all principles because it's required engineering practices in place to implement. This is one the reason for higher demand for agile engineering coaches to provide supports to adopt these technical practices like TDD, BDD, ATDD, CI/CD, DevOps and Agile Architecture & Design etc. Nowadays all leading scrum certification authorities is promoting these practices through their certifications program like CSD (certified Scrum Developer) and PSD (Professional Scrum Developer).


Below is mapping of engineering practices against some of the agile principles to visualize how these become important.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Delivering product frequently with new features looks easy during initial stage and also when team is small but issues start appearing after few deliveries or when new team get added to work on same product. These issues are mainly related to integration of code and ensuring newly added code has no impact on already released features. Opting for continuous integration practice and using tools like Jenkins, CruiseControl, Hudson, TFS etc can resolve these issues.
Business people and developers must work together daily throughout the project. Working together mean whole team available to each other and help each other whenever needed. But it would be good if business people write acceptance test cases in way that enable developers to write code. Automating acceptance criteria using any BDD/ATDD tools like cucumber, SpecFlow, Nbehave, Behat or Fitnesse will give confidence to business people because implementation of new stories can be verified immediately. 
Continuous attention to technical excellence and good design enhances agility. Agile architecture and design is a need of hour. Having big design up front (DBUF) is not good practice and team moving towards emergent design. Ideally the team that code the system also design the system and focus should be on build a design that can possibly work. If development team is also designing the software then team focus is not only meeting the requirement but also on how to enhance design. Following SOLID design principles and coding through TDD will help in technical excellence.
Simplicity–the art of maximizing the amount of work not done–is essential. Agile architecture and design also talks about YAGNI (You aren’t gonna need it) and KISS (Keep it simple, stupid) principles but having BDUF is violation of these principles. Purpose is simple, Code as much as needed to meet the requirement and nothing more. Test First approach helps in writing less code and only that much needed to pass test.
The best architectures, requirements, and designs emerge from self-organizing teams. The teams that code the system also design the system because team is empowered to define, develop and deliver software. Build the simplest architecture that can possibly work. If non-functional requirement and prototype of system is not sufficient to take design decision then better to code to understand potential impact of the design. TDD and Refactoring helps is producing better design because design get tested during coding.
Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.
We deliver training on Test Driven Development (#TDD), Behavior Driven Development (#BDD), Cucumber, #Selenium, #JiraAgile, S#crum, #Jenkins, #ScrumMaster, #ScrumDeveloper, #ProductOwner, agile estimation and planning, writing user stories etc.