Estimation challenges, gotcha’s and expectations from developer

Published an article on LinkedIn - "Estimation challenges, gotcha’s and expectations from developer"

https://www.linkedin.com/pulse/estimation-challenges-gotchas-expectations-from-developer-gawali

Published - Observations from code reviews and why they are important

Published an article on LinkedIn "Observations from #code #reviews and why they are important".

Need for clarity in the backlog/user stories and defects

Often times we come across poorly written backlogs and defects. This not only leads to confusion but also creates rework in the sense that spending time to understand what is happening to the system and what are the expectations from developer or tester.
As someone said, clarity is divine. Without clarity there is chaos and confusion; ultimately this leads to delays is the software delivery. Maintaining clarity helps involved stakeholders in following manner –

1. To identify work involved 
2. To come up with list of tasks, before actually working on the backlog or defect.
3. To come with any proposals that can be shared with stakeholders for approvals (if required)
4. To know risky areas upfront as far as possible
5. To know dependencies/bottlenecks before working on the tasks

Why should we provide details in the backlogs (or user stories)?

1. Clarity on the use case to the developer
2. To determine priority by the product owner and/or marketing
3. After some time gap there is possibility of even submitter not remembering about how to reproduce the defect
4. When we provide details, we come to know whether backlog is too big, if it is, then backlog needs to be broken to fit into one single sprint (just in case anything is missed in backlog grooming)

What should be provided in the backlogs (or user stories)?

1. Crystal clear acceptance criteria is must. In absence of it, developer and tester cannot know what is the measuring criteria to mark the backlog as done
2. To write test cases clarity on acceptance criteria comes handy
3. Some of the generic tasks like code review, document update, test case writing must be added by default. In version one this is possible by creating Template Backlogs.
4. As far as possible list of tasks to be done should be added to avoid rework on tasks identification.
5. A wireframe/screenshot of UI (if applicable)
6. Establish dependencies between backlogs
7. Map to parent Epic as far as possible, this associates a chain of requirements

Why should we provide details in the defects?

1. To let severity determination by the product owner and/or marketing to prioritize the defect. Detailed information on the defect helps in the decision process.
2. To let developer reproduce defect on his own
3. To make developer, tester and other stakeholders on the same page

What should be provided in the defects (or user stories)?

1. Exact use case with steps
2. Observations after performing the steps
3. What is the expected behavior from your perspective
4. Initial severity, based on the pre-existing shared guidelines
5. Initial priority, from your perspective (this can be discussed and then updated too)
6. Build and release number of the software, service pack number and other useful info on which issue is seen
7. Backlogs broken by the defect
8. OS details
9. Clear distinction between “Unit Testing Defect, Integration Testing Defect, Acceptance Testing Defect and Regression Defect” &/or other such types
10. A screenshot of the issue (if applicable)
11. Any input data/files necessary to reproduce the defect

Common for both backlogs and defects

1. When discussion happens on the backlog/defect it should be captured and attached to it in the system. In future this helps to understand the requirements etc. for new comers and can be used as requirement documentation.
2. Map to parent Epic as far as possible, this associates a chain of requirements that can be easily viewed
3. Provide/attach any external links where discussion happened or that may help to understand the requirement

Debugging WIX MSI installer issues

On one particular PC after software installation, whenever user tried to launch the application, software installation configuration dialog was popping up continuously. And this was observed on very few PC’s.

After intense googling I found one thread that discussed about self-repair mechanism of WIX installer and it proved useful.

WIX installer generally logs “Windows Events” which can be referred to find out root cause of issues.

Another way is to inspect log generated by MSI. See below example

msiexec /i "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"

This screenshot should help for Windows event log based debugging –

 

MSI log in Windows Event Viewer

Here are some quick references for WIX/MSI installer:

Advanced Installer User Guide: Generate MSI logs as per need

Real-World Example: WiX/MSI Application Installer

Windows Installer Guide (on MSDN)

Property Reference (on MSDN)

Good thread on: How to add a WiX custom action that happens only on specific activity (such as “Uninstall”)

Test automation frameworks

Open source test #Automation #frameworks testers need to know.
#Testing #OpenSource

https://www.joecolantonio.com/2016/05/10/6-open-source-test-automation-frameworks-need-know/

Use Debug Diag tool to debug and analyze problems

Microsoft’s “Debug Diag” tool is very helpful diagnostic tool that every developer should be aware of who works on Microsoft technologies -

Below are the benefits of “Debug Diag” tool

1. App crash investigations
2. Memory leak finding for .NET & COM components (i.e.e managed & unmanaged)
3. Performance analysis of application

Provides two tools –

1. Debug Collections – which capture data (dump file & text logs)
2. Debug Analyzers – provides summary of analysis in the form of an HTML page. (Produces an MHT file that opens up in IE)

Additional information on “Debug Diag” tool from Microsoft that can be used for memory leak findings –

1. Download link for ‘Debug Diag’ tool from Microsoft’s website.
• Need to download “DebugDiagx64.msi” for 64 bit OS
2. Link for blog on - How to create rules to capture “Memory Leak”
• This article is written for old version, but concept is the same
3. Link for blog on – Debugging Native memory leaks with Debug Diag
4. Link for blog that describes – Additional options & analysis reports

30+ podcasts to listen from

Listen to #podcasts when not doing important #work and  boost your #productivity by #10X, #Compilation by Pluralsight

https://www.pluralsight.com/blog/career/smarter-secrets-podcasts